One thing I’ve witnessed over the last few months as I’ve worked with dozens of customers is that, despite the fact that companies already have hundreds and thousands of APIs (anything that is an “interface” is an API in my mind), companies are still adding more. This includes the thousands of interfaces exposed by an SAP or Oracle, or the hundreds of SOAP web services, FTP jobs, asynchronous batch jobs, newer REST APIs. And let’s not forget the companies that have been acquired or partnered with, and all of their interfaces from their internal systems.
When are there going to be enough APIs?
Short answer: Never.
Businesses are still banging on IT’s door progressively louder and louder saying, “give me more, and now!” It’s like the business partners that endless refills on their drinks.
Why? Because business’ objectives focus on continually innovating, producing new routes to market, improving customer relationships, creating stickiness through social and digital marketing strategies, and integrating into an increasingly fragmented cross functional value chains. This is going to require new layers of innovation platforms and ecosystems to grow.
Let’s make some more APIs!
Typically what I’ve seen is that we throw more APIs at the problem. That works occasionally but if you don’t follow a deliberate methodology – it won’t. (Note: I’m not trying to narrow this problem to just APIs – it’s about culture, governance processes, and other aspects of the technology stack too).
So what’s the solution? There are multi-faceted approaches to the problem that all need to concurrently be taken into account.
- It’s about approaching how you design APIs with the user in mind – that is, to follow the API design life cycle. I briefly mentioned this in my last blog post.
- Following a set of architectural principles to “future proof” your API – centric architecture.
- Ensuring you are able to support a successful roll out of your APIs by putting the appropriate API management and governance controls in place – more on this in a future blog post, stay tuned!.
I’m going to spend the rest of this post talking about the second bullet.
This is where the Enterprise Architect comes in
Having an architecture and an API strategy is important. It’s about trying to drill down into the business processes in question and determine what they are trying to achieve. Then it’s about understanding what are the information assets in these processes and breaking that down further into logical data models. From this point, it’s imperative to aggregate all the sources of data in your organization and figure out a strategy around providing that single source of truth. More on this in a subsequent blog.
But all said and done – the final stage is when you’re deciding on what that API will look like – and how it will be implemented from the backend. This is tough. What works best is splitting up vertical layers of APIs, where one layer provides more of the canonical functionality and data that serves as a common denominator for the other layers that provide more contextual APIs based on the consuming entities.
All in all, what I’ve been seeing is that companies are naturally evolving towards building an agility layer. Key to being able to build layers is to orchestrate below, because the last thing you want is a bunch of brittle spaghetti like piping. Don’t be ambivalent to what happens below the API – otherwise you might end up with lipstick on a pig.
Interested in more?