Reading Time: 9 minutes

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.

So there is a no shortage of APIs – far from it in fact. So, a “lack” of APIs is definitely not a problem.

When are there going to be enough APIs?

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

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.

Architects and technology leaders need to approach API design as an opportunity to really step back and think in terms of fundamentals.

What we need to do is take the same approach Warren Buffett takes to investing: it’s not about the short term gain, it’s about the fundamentals and foundation that the business is built upon.

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.

(Quick side note –> I can’t emphasize enough how much of a pain this is. – A single view into everything the business processes touch is powerful because businesses can make better decisions based on an expansive, collectively exhaustive approach to peering into what is truly the state of the enterprise. It’s about trying to provide a single source of truth for all data across a super fragmented landscape! It’s about trying to ensure that data flows correctly so whatever is presented at the top layer is THE truth. )

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.

I like to think of the common denominator layer as that agility layer because you’ve got the basic Lego bricks you need to quickly piece together what you need to respond to the core set of business needs – and then you add the icing on the cake (in terms of the more contextual layer of APIs). (Quick Side note – this is a little different for purely internal APIs where we’re talking about pure horizontal machine to machine interactions – more on this later as well).

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?