Those of us who are long term API evangelist and change-makers, have entered organisation with a task to inject APIs into service and platform development. Bringing just APIs to architecture is not going to do the job. If you think otherwise you are most likely thinking APIs too technically. It’s a big transition in some companies to enter truely APIs driven world since it will change the thinking and daily operations in sales, product development, marketing and even human resources and management. This post touches the boring sounding “Politics” slice in the 360 DX model.

I placed first dot in the piechart between internal DX and sales mostly because the most difficult part is to get your technical and business layer aligned in the transformation.

I must admit this area of the piechart feels a bit fluffy. To be honest a hint of BS might be in the air, but lets see. The internal DX will change for sure if APIs driven thinking is taken into use since it will change the architecture. Monolithic thinking must be put aside. You start to move towards connected services which as a whole enable your business. Connections are build with APIs. You also that to think about making partner APIs so that you can make business critical cooperation with other companies. Then finally you enter the are that your business layer starts to think APIs as products.

Start from within

To participate in the external API economy, businesses need to drive an internal API economy first. Innovation at the edges doesn’t work unless a business can unlock its core, which is often made up of big, monolithic infrastructure. By opening up APIs internally, businesses can free themselves from the limitations of their legacy systems, changing the way they deliver digital products and services to customers, partners and employees.

Anyway, thinking has to change, not just tech. The management “has to get” the APIs or the change is going to be hard. Your organisation is going to use APIs internally and that is the normal path towards API driven business and service development. Develop the internal APIs just like those might be published to 3rd party users inthe future. Have just one process for the API development regardless of is it internal or public API. Require the same standards. That will increase the speed of taking advantage of your APIs in-house.

It might feel a bit cumbersome in the beginning and some might nagg that it’s too much work to document APIs as if those would be used by someone else. Not only the possiblity of publishing internal APIs, you should consider that your developers might also come and go. Some quit and you hire new developers. Your subcontractors come and go. They all need easy to use and well documented APIs.

Unless the APIs are used internally as well, you will never understand the value of great developer experience.

Start small and make small experiments to see what works and what not. Your current staff most likely does not have the necessary skills what it takes to master API products. Training is evident.

Asset, Pass it on and Intuitive.

According to Paul Dumas API mindset can be trained in organisations at least with three ways. Asset, Pass it on and Intuitive.

As asset. In your domain, what can be made accessible that is of value? For example, can you provide access to data that tells a client “What is the average time between users landing on our site to submitting an order?”, or “What percentage of our items are damaged in transit from the warehouse to the retail outlet?”, or “Where is this specific term referenced in all our digital content?”, or “Based on current buying velocity of a specific product, when will that product be out-of-stock?”.

You are productising that data, converting raw data to valueable information. Don’t just pass it through, make something valueable out of it. The term used in this context is data monetization. According to Najjar and Kettinger (2013) “Data monetization is when the intangible value of data is converted into real value, usually by selling it. Data may also be monetized by converting it into other tangible benefits (e.g., supplier funded advertising and discounts), or by avoiding costs (e.g., IT costs).”

Data monetization requires a strategic choice on which of several pathways to follow. It is important to assess the technical (data infrastructure) and analytical (human) capabilities of the company to determine which strategic pathway a company should choose for monetizing its data. The analytical capability is the mathematical and business analytical knowledge and skills of the employees in the company or in supplier firms. A company that has the data and the know-how (i.e., people and BI&A) to use the data properly will have an advantage in the era of big data.

In brief you need both tech and skills :) No wonder data analytics people are hot now.

With help of the data analytics skills you can invent new products from the data. Your PowerBI system will not just magically do the job for you.

Pass It On. In your domain, what could you delegate to an API service? For example, if it takes several steps to collect the information you need about products, should you relinquish that function to an API service for all your programs to use? Can you delegate part of “code review” to an API that can interrogate a source file for expected standards and structures in the code?

To us at Platform of Trust this kind of thinking is more in the form in which we use existing service to fulfill some need in our process. Code analysis is one of those. Every commit is passed to code review in SonarQube.

In fact our whole platform is build with this principle in mind. Our additional services like Developer portal, website, self-service tools and so on all take advantage of platform APIs. The capabilities behind APIs are sometimes powered by internal components, but more often it’s a combination of both internal and purchased API driven service. The services do not need to worry about the complexity behind the API, those own services like the developer portal take advantage of the shared API. One might say that our core is insulated from rest of the world with APIs. That core in turn is collection of dedicated services. Simple example is Customer information. None of the portals we have need to know that at the end of the chain there’s Hubspot. For them there’s just Customer API with needed endpoints and methods.

Intuitive. In your domain, when you think about the APIs you can offer or would like to consume, think about how to make them intuitive from your client’s or provider’s perspective. Think about the language and terms used, the schema of the data, and so forth. When a developer decides to use an API, the more intuitive the API is, the easier, faster, and more successful its implementation will be.

This pretty formatting for saying that get the developer experience on track, make it a specific value for all in the company. This will attract the developers to use available APIs instead of building the solution again for the 15th time.

If the DX of your internal APIS suck, your own developers use the resources to rebuild the same again.

.

That does not sound very efficient and smart. It sounds like wasting time and money…and stupid. But you are forcing your own developers to badlands if you don’t require high quality DX also from the internal APIs.

Some more to read from 100 Days DX