I’m not telling you something new if I say the demands on IT from business are ever increasing. Certainly the last few years, business is looking more and more towards IT as a big part of the solution to their business problems.
Organizations are forced to undergo a digital transformation, where IT is the strategic enabler of their business. Think about IoT, mobile enablement, omni-channel sales/communication, partner integration and so on.
How can you provide a solid IT architecture that can cope with all of these business requests? I call them business requests, because what we are actually trying to do here is exploiting technology to create business value.
I recently heard a term I quite like that hits the nail on the head: organizations need to become “composable enterprises”. If we take a look at the IT landscape of a typical mid-sized enterprise, we see a mix of custom-built and off-the-shelf software, using a variety of technologies, both on premise and in the cloud.
All these building blocks that make up their landscape are typically connected point-to-point, pumping data from one application into the other, without thinking about things like re-use, maintainability, replaceability and so on. By transforming all these point-to-point interactions to decent interfaces on top of these applications in the form of services/APIs, using commonly accepted standards like REST and SOAP, you add a lot of robustness to your architecture.
In short, projects can now use assets that are of value to them much faster and in this way innovate faster with shorter cycle times. Don’t just think inside your own company’s little box but think bigger: projects that involve sharing data with partners, selling assets to third parties who can innovate using your data and so on, this all becomes possible when using APIs.
Furthermore, you can increase the value of your own assets by aggregating data from your own APIs and those of third parties, and exposing this material as a new API. They all provide a common way to interface with them, which makes aggregating this data a breeze. This kind of use cases are typically handled by an API gateway, for both security and performance reasons.
So, these APIs seem really attractive, don’t they? However, I can anticipate the following questions you will certainly have:
- How do we identify what exactly should be exposed as an API?
- What’s the impact on our current architecture, where does it fit in?
- How do we develop an API and make sure it’s reusable, maintainable, secure?
- How do we manage this new “composable enterprise”?
All these questions will be answered in full on our upcoming AE Foyer, but I’ll give you a sneak peek on some of these questions.
Before going into more detail, we have to make a difference between APIs for internal use (on premise application-to-application communication, own mobile app, cloud integration etc.) and APIs for opening up your enterprise to partners or third parties in general. We will be focusing more on the second category, since that is where the real new value of APIs lies.
A first challenge you come across when starting an API program is of course the definition. Unfortunately, defining these APIs isn't always as obvious. Below you can find a possible path to follow for this challenge:
Once we have these business goals and requirements, we can continue with a solution design and the realization of the APIs. But it doesn’t end there. An important part of an API strategy that is often overlooked is the operational and retirement part. How will you make sure people can rely on your services? How can you make life easy for them to integrate with your APIs? How do you even get them to know about your API and encourage them to use it?
Since APIs are built for agility, they will evolve fast! Learn how to cope with breaking vs non-breaking changes. Talking about breaking changes, how long will you support a certain legacy version? Third parties need time to evolve along with you.
Depending on the use case, API security is probably also on top of your checklist. Exposing APIs to the outside world does not mean putting your internals at risk! Make sure you don’t expose your internal data structure because that can be abused. Also make sure that when you expose APIs, your internal systems can’t get harmed on performance level or on data/infrastructure/application security level. Putting an API Gateway in place can mitigate a lot of these potential risks, but the challenge here is to identify the concerns and to mitigate them in a proper way.
Did I trigger your attention with these questions and remarks? Please join us at the upcoming AE Foyer.
If you're unable to attend the event and have some more questions on this topic, do not hesitate to contact us.
