Service Contracts Over Technology Standards

To begin with, some 25 years ago, and for a long time, IT architecture was about standardization on technology. It was a craft that began with business principles, moved through contextual, conceptual, logical, and ended with a physical architecture of standards, technologies, products and services. It worked, and it was very nice, because you got traceability all the way from the business requirements to the actual servers that delivered them.

During my 30+ year career, I have been involved in many such initiatives, and they were very satisfying because they often achieved something that is still rare in our industry — a concrete connection between the business and the technology. However, one problem was that it took some time to get everything into place, and we’re talking about months and sometimes years. Another problem was that when we were done, many things had changed, and it was a challenge to keep the architecture up-to-date with the need for constant adjustments. I realized that we needed another approach, something simpler, something agile.

So one day, about 15 years ago, the head of Amazon, Jeff Bezos, issued a very interesting mandate that went something along these lines:

1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired!

Over the next couple of years, Amazon transformed internally into a service-oriented architecture, and one very tangible result is their current cloud platform. I was a very big fan of Jeff Bezos at the time, and even if we talked about Web Services instead of APIs, I realized that he had a very significant point. The important thing is not the technologies we use, but the functionality and information that we expose. This concept is what we nowadays call service interfaces, and when including the service level, we talk about service contracts.

I started applying the same approach at the clients that I worked for, and over time, I have seen that it really works. Autonomous teams (that you can read more about in Use Beautiful Delivery to Speed Up Your Digital Transformation) are more motivated when they are allowed to choose their own tools (as well as the way they work), and since they are responsible all the way from customer needs to run in production, they usually go with what works. This freedom is made so much easier by the cloud, which is actually something that came out of Bezos mandate, what is now their cloud services, the Amazon Web Services. An interesting thing that happens with multiple such teams, is that the tools and technologies they use will spread among the teams in a natural way, and there is no need for architecture documents with rules and regulations. Sound architecture guidelines and principles are still very helpful for these teams, as it will save them a lot of time as well as increase the quality of what they deliver.

Many of my fellow architects share similar experiences, and that is why we agreed on the following general principle:

We support heterogeneity and interoperability, so
instead of standardization on technology, we focus on
creating clearly defined service contracts.

It’s something we strongly support and promote, and therefore it has been included in our Architecture Manifesto.

It’s also reflected in one the of the core values of the manifesto:

Service contracts and automation over technology standards and processes

I will get back to the automation versus process part in a future blog post.