I work for a company with 580+ cloud APIs (with every API implementing different functionality, but with a lot of overlap) and even more micro services. There have been many attempts integrate all those APIs into one API and data model with minimal duplication.

Before throwing technology at the problem, I am trying to come up with a list of possible problem causes and see which ones apply to us. One thing that comes to my mind is Conway's Law:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." - Celvin Conway (1967).

Some of the reasons I came up with:

  • "Central" API team being the bottleneck
    • Unable to keep up with stakeholder requirements
  • Different services providing different protocols (SOAP, OData, RPC, ...)
  • Services being in different product life cycle stages

What are common reasons to why it is hard for large organizations to build one API with one data model? Not asking for solutions.

  • 2
    What do you mean by "Single API"? Do you mean that you have 580 APIs doing the same thing? If they're different things, what do you mean by a "Unified API"? Sep 6, 2019 at 18:25
  • Hi @VincentSavard, I clarified further. 580+ APIs for different use cases, but they have a lot of model overlap.
    – mitchkman
    Sep 6, 2019 at 18:35
  • 1
    What are common reasons why large car companies struggle to build single, unified car experiences? Sep 6, 2019 at 18:37
  • 1
    Can you make the car vs API comparison a little bit more clear?
    – mitchkman
    Sep 6, 2019 at 19:24
  • 3
    @mitchkman: xkcd.com/927 Sep 6, 2019 at 21:20

2 Answers 2


Big companies are often a bunch of small companies operating under a common name. Either because of historical reasons (they used to be independent until some merger or take-over) or because of practical reasons (having decentralised management can be more agile). The sub-companies enjoy some independence and may even have their own culture. They can make their own decisions and they will do so based on their own focus. Each is fixing their own problems. And as long as they are functional islands this does not have to be a bad thing.

When it comes to building something it will be tempting to just push ahead and fix your own problem. Cooperation will slow things down and partners will likely not be interested at the time you need a solution. The only way to synchronize these developments is through central management which will likely not be aware of the need (if there is one) to do things in a uniform way. So chances are you will get some diversity.

Once you have all these systems and the need pops up to have them interact, you can still implement new interfaces for that purpose. It is only "hard" while there is not a real problem to be solved.


Another factor is that such an API has a lot of reasons to change - e.g. the accounting team neds X,Y and Z, the marketing team A,B,C, and even worse - they might need similar data but differently organized, e.g. marketing needs all data in a table for a data science algorithm, but accouting cannot work with that data structure. Cramming such disparate reasons to change and different requirements into a single API is guaranteed to overwhelm your API. It needs to fullfill incompatible requirements and change & evolve into different directons. You either end up with a API which satisfies no one or is a convoluted mess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.