Bookseller

Enterprise Architectures come in many shapes, sizes, and guises and those that write them could perhaps be characterised in one of two ways.

Type 1

The centre of gravity of a Type One Architect is structure.

The Type One Architect is usually found gracing the marble halls and ivory towers of large corporates typically taking a traditional classification/cybernetics approach. They will subscribe to Frameworks and models with a focus on classifying people, processes, and systems.

There is a place for this in some organisations, it helps to bring order to chaos, and stability to volatility, However, are these the architects you would turn to for strategy, growth, and innovation?

The challenge of focusing on a top-down structural approach alone isn’t going to win you business which is essentially what a good strategy comes down to.

Type 2

The centre of gravity of a Type Two Architect is content.

Where the type one architect might be a librarian, the type two architect might be a bookseller.

The type two architect gets their hands dirty. They have dabbled with new things, fixed problems, and ultimately tried and failed, many, many times. The type two architect probably asks two questions more than any others.

How does it work?

How can I make it better?

They have persevered on the edge of IT governance, out in the Badlands where they evade spreadsheets and Governance forums and other controls that they see as increasing friction. What gets a type two architect out of bed in the morning is solving problems that ultimately create happy customers, sustainable businesses, and value.

The type two architect is a minimalist. Frameworks and strategy diagrams are adhered to where necessary, they are the means, not the end.

The Memo

Perhaps one of the most successful examples of a Type Two Architect started out as an actual bookseller, albeit with a background in electrical engineering and computer science.

As he was building Amazon, he sent out a simple email in 2002 that set out what turned out to be a very powerful statement of enterprise architecture that last to this day.

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 inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no backdoors whatsoever. The only communication allowed is via service interface calls over the network. 
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.  
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.

That was it, one memo. One single text-based email. No fancy diagrams, no lengthy presentation, no frameworks, no governance. In a short email, he described how he wanted it to work, and an approach to make the business potentially better.

It helped transform Amazon from an online website selling books to an organisation with a fully extensible Service Orientated Architecture platform.

The Outcome

Does this simple memo achieve what any good Enterprise Architecture should do?

1. It clearly sets a priority – Point 6 makes it very clear, this is the number one priority, if you don’t do it you are fired.
2. It sets a strategic technical direction – service base technology-driven through APIs. People who knew what they are doing would have understood this.
3. It sets an expectation around quality and ensures appropriate control – “no back doors whatsoever”.
4. It creates a democratised value system – “Externalisable interfaces”, this gives information nowhere to hide, its value will be determined by subscriber volumes. If you are in the organisation and nobody wants your services, you’re not adding value.
5. It is scalable “It doesn’t matter what technology they use” allows an agnostic approach to tooling and technology, allowing faster adoption and creating a diversity of approaches to drive out improved practices and ensure non-functions can be met by those accountable with no barriers.
6. It creates massive efficiencies, “The only communication allowed is via service interface calls over the network.” Significantly it removes manual processes, paper-based processes and unnecessary meaningless meetings.

For the technically minded amongst you, this is a Service Orientated Architecture, an API driven architecture. Whilst there are many things, good and bad yet to be discovered about these architectures, SOA driven design enables value performance at scale, and Jeff needed a scalable platform to sell his books and move across to other consumable industries.

By creating an extensible platform for selling his books and consumables, Jeff had built a Service Orientated Platform that could be repurposed for others wanting to follow this model.

This mindset was foundational to the success of Amazon Web Services which is one of the global leading cloud platforms in the world today, which is vastly outperforming the original online bookstore.

We will never know whether AWS was an unintended consequence of selling books on a scalable online platform, but we do know Jeff communicated an excellent Enterprise Strategy and Architecture that sustained the growth of the company for over twenty years.

So, next time you need to prepare an enterprise-level strategy and architecture, keep the focus on setting a clear direction and vision, creating value, promoting adoption and action, and driving the priority. Frameworks and structure can help but are simply the means to an end.

Is that short email the best example of an Enterprise Level Architecture we have ever seen?

+++