Written by Ian Vanstone
Before we kick off for another massive week at IntegrationWorks after Easter and after our highly successful API Economy tech-breakfast sessions in Australia, we’ve taken some feedback from people who are wanting to learn more about the API Economy but who are not sure where to start or what the overall process looks like. So, given our experience and expertise in all things API and integration, our Chief Technology Officer Ian Vanstone thought he’d break it down into a step-by-step article, where all you do is have to follow the steps and ask us questions.
Now firstly, API strategy, execution and journey is far far more complicated than what we talk about below, but its always good to get a look at the larger picture before deep-diving into the specifics.
If you’re reading this article with interest, then we assume that you have heard about the API economy and you want in. You’ve done a bit of research, put together your business plan for executive support, drafted a commercial plan and have marketing and legal on board. A few hurdles have been jumped and now you’re ready to launch into the technology and development process. But there are a few unanswered questions you may have ahead of you.
Initially, its fair to assume that you have:
+ Data
And what you’re going to do is add an API to expose the data to external developers:
Developers ⇒ Rest API ⇒ Data
Who in turn will create apps:
Apps ⇒ Developers ⇒ Rest API ⇒ Data
Which will be used by end-users to grow your business:
Users ⇒ Apps ⇒ Developers ⇒ Rest API ⇒ Data
So this has tracked along all okay up until this point, until there is a glitch in the legacy or historical data system that doesn’t allow exposure of API’s. Originally your legacy system wasn’t built to be exposed to the outside world, so you need to deconstruct that architectural layer with some sort of integration tool, language or product that allows for transparency and transaction. This tool could be an ESB product (ie. a MuleSoft ESB), raw code (ie. Java based integration programming) or a more specialist product or framework (ie. IBM Strongloop)
At this stage your application model should look like this:
Users ⇒ Apps ⇒ Developers ⇒ Rest API ⇒ Rest API tool ⇒ Data
Great. So this works well in theory, but generally the API (as it grows and develops) will need a lot more access to the data and the data needs to be transformed. For a large enterprise with multiple data servers its best to drop in an EAI/ESB product to do some of the agile integration heavy lifting.
So then you have something like this:
Users ⇒ Apps ⇒ Developers ⇒ EAI/ESB tool ⇒ Rest API ⇒ Rest API tool ⇒ Data
Now the we have the data in the correct format to serve the API. It is all starting to look like a smart internal system, albeit with a number of nuts and bolts to make it work. Our next consideration focuses on the external border. We don’t really trust external developers to utilise our API in the correct way and we certainly don’t trust others outside the enterprise that are probing the enterprise border for networks and APIs to attack. So we add a gateway to secure and protect the API traffic.
A good cookie-cutter version looks like this:
Users ⇒ Apps ⇒ Developers ⇒ Secure Gateway ⇒ EAI/ESB tool ⇒ Rest API ⇒ Rest API tool ⇒ Data
Ie. IBM DataPower Gateway
Fantastic, the enterprise is now secure and functioning at a base level. But. We can see by the network activity that the uptake of the API has not been great and we haven’t really advertised the API as a product for developers to integrate into, which affects loads and potential revenues. So we add a Developer portal that contains developer-friendly documentation and artifacts (e.g. Open API docs) and sandbox/testing features.
Now our API model is looking somewhat like this:
Users ⇒ Apps ⇒ Developers ⇒ Developer Portal ⇒ Secure Gateway ⇒ EAI/ESB tool ⇒ Rest API ⇒ Rest API tool ⇒ Dat
This is awesome, we can now see more transactions flowing. But we’re not actually sure who is driving the traffic or what pieces of data are being used. Luckily there are a few API Management platforms that provide us with some nice analytics and graphics on what apps developers are using and the data sets being accessed. So we know what’s most valuable, can spot trends, and better engage the top developers.
With this comes huge success, to the point where the API has built up such a following that the backend data system is starting to creak and slow the apps and internal systems and creating more cost to run.
The backend was never intended to cope with these numbers of transactions.
So we add in a caching layer to reduce the load and lower latency.
Users ⇒ Apps ⇒ Developers ⇒ Developer Portal ⇒ Secure Gateway ⇒ Cache ⇒ EAI/ESB tool ⇒ Rest API ⇒ Rest API tool ⇒ Data
e.g. IBM ExtremeScale or Redis
So now we’ve got a moderately successful API that can run on our current system. But like all good things, we need to make sure that the API is always evolving and refining. Frequent tweaks to the API design, re-factoring of modules, refining of deployment and versioning will be an ongoing maintenance job.
Sound like a lot to think about and plan out? It is. Developing a successful API is an ongoing challenge, to be the best takes a lot of strategy and stamina. But the good news is, if you successfully roll out an API program your organisation can benefit from:
- Increased ability to serve mobile, cloud and rapidly evolving IoT technologies
- API Management PaaS/SaaS offerings can speed up that transition and get you moving along fast
- Proven ROI models can add revenue lines to your business.
But if this all sounds a little complex, then you can reach out to our team here at IntegrationWorks. Our consultants, architects and developers are API experts who can help you in selecting, designing and delivering the right platforms and API products to enhance your technology. We can also train your team too; to upskill and allow for self-sufficiency in this evolving API journey.