Intro API strategy

Defining an IT and digitalization-strategy is crucial regardless if you are a small, mid-size or a large company. This will give guidance, priorities, and a path on where, how, and what your business should focus on the next 1-, 3- to 5 years.

In addition to this, defining an API strategy connected to your IT & digitalization-strategy will give guidance on how you as a company make the most out of your digital assets.

There are thousands of ways to write a strategy in general, as well as an API-strategy specifically. During the API-era (the past 20 years or so) many companies have built their API strategy around Conway’s Law.

Conway’s Law aims to build systems that closely reflect an organisation’s internal structures. It was formulated by programmer Melvin Conway more than 50 years ago, where he stated:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”

Trying to describe this in a simple picture – where we mirror our system design to our company structure – would look something like this:

On paper, this looks pretty good. To further emphasis this we can illustrate what your organisation is more likely to produce in terms of software using Conway’s law:

Figure 2: Conway’s Law, paraphrased Conway’s Law

Let’s look at an example: suppose your organization deals in both wine and beer, and as part of your digitalization strategy you are looking to build a few customer-facing inventory API’s. If the structure of your organization is heavily divided between “beer people” and “wine people” – each unit having separate tech teams – then you’re likely to end up with two APIs (one for each product) coded very differently.

Criticism of this model claims that the communication structure isn’t always reflecting the organisation structure, causing a complex system environment because people in- and outside the organisation chart has different relationships and communication structure.

The Inverse Conway Manoeuvre

The concept of Conway’s Law can also be applied in a reverse manner. For example, having a target architecture in mind we can challenge and form the communication structures within the organisations and by that achieve our planned design.

If an organisation uses a service-based architecture, each component is developed and managed independently from each other. Individual teams will be responsible for an individual service, having complete and independent decision-making capabilities.

Looking at our “beer and wine” example above, and by applying a service-based architecture, our organisation will use the same product, marketing, and tech teams for each beverage (wine and beer). This will more than likely result in just one API – “beverage” – that does it all in a more controlled matter.

Understanding and applying Conway’s law is a crucial building block of a modern company where we want to bring organisation and technology together as closely as possible, by breaking down communication silos to speed up productivity and quality. It is as much an organisational challenge as a technical one.

Technical challenges tend to be the easiest ones to change. But without being prepared to change the organisation and the communication structures, I promise you this: You are doomed to fail.

Let one of our experienced architects give you a recommendation on how you can accelerate your API journey!

Reach out to Ole Morten Boldevin, boldevin@avella.no to discuss your API Strategy with Avella AS.