The Summary

There have been many requests to make the basic message of the book available. There is an excerpt that can be gotten via the home page of the book, but that leaves people wondering: what about Chess, then? The excerpt shows the style, and it is a nice story to read, but it doesn’t say much about the argument.

As I’ve written the book in part to get a message out (the other part being that I just like to write), I’m publishing a summary of its main arguments and ideas. This summary, of course, does not have the depth of the book. Statements in the summary may make you wonder: what is the analysis behind that statement? Why is he saying this? For that, you need to read the entire book. There, you’ll not only find the basic argument, but with enough depth to be actually convincing (I hope).

And there is the presentation of course:

Having said that: here is a summary of the book with the main points:

Prologue: Loosely Coupled Spaghetti

The prologue starts out with a realistic example of dependencies that exist across our modern Business-IT landscapes. Such dependencies may be built from best practice patterns and tools, such as enterprise service buses, business rule engines, and so forth, but the complexity remains and the story is about a real problem that occurs in that landscape and how things can go wrong. It introduces the subject of the book: Enterprise Architecture is supposed to help, but it seems not to help at all, and we must ask ourselves why.

1. An Inconvenient Truth

This chapter argues that enterprise architecture, a discipline that is supposed to help manage the complexity of Business-IT landscapes, has in thirty years not substantially helped to improve the situation. We still see the same sort of problems everywhere, both in terms of errors as in terms of the troubles we have in changing our complex Business-IT landscapes. Projects fail, chaos is still everywhere. There has been no technological ‘silver bullet’ and also Enterprise Architecture as a discipline has so far largely failed to produce the intended results. This is also reflected by the fact that Enterprise Architecture initiatives seldom have a long life. They get reorganised a lot, and that is not because organisations are satisfied with their added value, right?

2. Why Enterprise Architecture?

Before digging into the reasons why Enterprise Architecture as it is generally practiced is so unsuccessful, this chapter describes which results it actually must deliver to be successful. There are three main results:

• Prevent chaos in the Business-IT landscape (some structure would be nice…)
• Increase Business-IT alignment (structure follows strategy, with a caveat, see below)
• Increase IT-Business alignment (structure enables strategy)

To get this result, Enterprise Architecture needs to influence the choices that are made continuously in the organisation. Choices should:

• Result in a landscape we’re happy with in the medium to long term future
• Result in a coherent landscape
• Result in an effective and efficient landscape

3. The Orthodoxy

This chapter describes important aspects of the common approaches to Enterprise Architecture: defining a future state to work to, defining principles and guidelines to adhere to, ignoring details, etc. It describes a few problems with these approaches, such as the unpredictability of the future and the ineffectiveness of principles and guidelines to get good design choices, the — sometimes deadly — risks of ‘comply or explain’ and the inability of a (necessary centrally organised) Enterprise Architecture department to have enough domain know how to make good judgement calls. It also notes that there is no shred of reliable evidence that existing methods, ‘best practices’ and frameworks actually work.

Intermezzo: A Short Story about Grief

Opening lines of the movie Wittgenstein from the script by Terry Eagleton, reused with permission. It is about the difference between the rational and the real, something that is related to the position Enterprise Architecture is in, spanning the rational of digital technology and the real of human behaviour. It’s also the motto of my guest column over at the Enterprise Architecture Professional Journal.

4. Chess

This chapter introduces the chess analogy. Chess shares complexity and unpredictability with the situation in Enterprise Architecture. Making and implementing a design decision in the organisation is suggested as an analogy to making a ‘move’ in chess. How do we handle complexity and unpredictability in chess and what could we learn from that for the situation in Enterprise Architecture?

• It is noted that chess players generally do not make a move with an ‘end state’ in mind. The chess player does not work towards some recognisable end position. Instead, chess players work from the current state and think of moves that strengthen their position. Enterprise Architects should do the same. Do not focus on the unpredictable future too much, focus on making the best changes (improving your position) now.
• It is noted that tactical rules in chess are not predictive but descriptive. E.g. a simple rule would be that material advantage is good. You can start with giving pieces points (e.g. Queen=9, Rook=5, etc.) and calculate if you have made a good exchange. But following the rule does not by definition lead to good moves. There are too many special situations. What is true that if you look at games, you will see that the winner almost always built up material advantage. The same is true for design rules in Enterprise Architecture. You will see that good architecture shows the rules, but that doesn’t mean that following the rules leads to good architecture. On the contrary, “comply or explain” is toxic and a source of failed large projects.
• It is noted that in chess, sometimes a pawn is of decisive importance, it can make the difference between winning or loosing. The same is true in Enterprise Architecture. Some details are relevant and ignoring that leads to project dramas as well.
• It is noted (based on famous research by De Groot) that master chess players don’t calculate much deeper than good amateurs. What master chess players have is a superior estimation of where the good moves are likely to be. The same is true for enterprise architects: they need to have a good estimation, which is why applying the logical structure of frameworks does not really help all that much.

So far the good news.

If you compare the real world of organisation with chess, it turns out it is infinitely more complex and unpredictable than chess is. Chess is actually very simple, the field is just 64 squares, there are only 6 types of piece, the current position can be perfectly known, players neatly take turns, etc. In real organisations the ‘board’ is immense, the squares overlap, the rest of the board changes while you are ‘making a move’ (implementing a change), a multitude of players all act simultaneously on that same board, and the strategic goals are complex, vague and even contradictory compared to chess (checkmate!). Enterprise Architecture is the Chess Game from Hell.

The question then becomes: why do enterprise architects believe so ardently in the effectiveness of a simple future state, a simple set of rules and so forth? That is because it is seductive. It is a flight reaction from unpredictability and complexity more than a fight reaction against complexity and unpredictability. There are deep psychological/biological reasons for this.

5. Playing ‘Enterprise Chess’

This chapter lays out a different way to look at fighting the complexity and unpredictability in organisations. The main element is setting up effective and efficient collaboration (between those with know how) and checks & balances (between the overall and specific goals).

We do not only have a complex organisation with complex issues, we can also, if we do it well, harness all the knowledge that the organisation has about that complexity. Nobody, not even an enterprise architect, can know enough of everything. Therefore, we need to cooperate. The question is how that can be done most effectively.

A governance model (based on actual experience) is presented that enables us to make better moves in the our game of enterprise chess. An important element is that we need to recognise that Enterprise Architecture is a ‘separate’ goal of the organisation (with a separate owner), one that is about ‘the overall landscape’, where most changes are about a more limited scope in both subject and time. The model therefore also sets up effective checks and balances between the two. This is quite an extensive chapter with a lot of detail on the way this can be set up effectively, e.g. including what competences enterprise architects need to have.

6. Managing the Future

This chapter pays special attention to managing the unpredictability of the future. It illustrates with a realistic example how basing your enterprise architecture on the organisation’s strategy can actually backfire. It shows that instead of forecasting (which is what we do when we try to predict where it’s all going) or backcasting (which is what we do when we define a target state to work towards), a ‘scenario planning’ like approach is far more effective to get a future state architecture’s most important aspect: robustness under uncertainty. It also notes that the average life span of a large IT system (important building blocks in your Business-IT architecture) is much longer than the average life expectancy of an organisation’s strategy, hence basing your architectural choices on the organisation’s strategy ‘du jour’ is probably not very robust. In fact, for the future of the organisation’s Business-IT landscape an organisation must be able to look beyond its current strategy.

7. Hurdles

As the book is based on experience (trying to put it into practice), there also have been valuable lessons about things that worked and that did not. Even if the practice has shown to be effective (according to me, of course, no scientific study was done), there are requirements for it to function and problems that can be encountered. A few described in this chapter are:

• A lack of board awareness (e.g. of the real complexity and unpredictability problems) and commitment. As the model is based on collaboration and on checks and balances between the ‘overall landscape goals’ and the ‘individual change initiative goals’ and as the future state approach is based on more than just the current strategy, the role of the board of an organisation becomes very important, not as the one setting the rules, but as the one stakeholder that should be in play.  Note: current practices generally shield the board from complexity and unpredictability by presenting make-belief simplistic messages and ‘make-it-so’ certainties, it is our fault as Enterprise Architects that boards are generally unaware.
• A lack of transparency. Collaboration means that people need to know about each other, it is not a ‘division of labour’. Isolationism is an important aspect of organisations because there are important (and partly good) reasons for it to exist. In extreme situations isolationism turns into a ‘siege mentality’, which is anathema to having effective Enterprise Architecture.

There are more hurdles described and analysed in the chapter.

Appendices:

A. Low-hanging Cloud

A story about low-hanging fruit and the next big ‘silver bullet’. The story has also appeared as a blog post here.

B. Current State Architecture

Some remarks about things you can do to get a better insight in your ‘position’, which (as in chess) is useful if you want to make a move. Perfect knowledge is not possible, but we can do much better that we generally do. The details of the techniques used to make such a CSA in the Enterprise Architecture modelling language ArchiMate has been described in another book I’ve written: Mastering ArchiMate.

C. Future State Architecture

Short template for a Future State Architecture document. The story behind it is in chapter 6.

D. Project (Start) Architecture

The full and annotated Project Start Architecture guideline and template document, created and used by me and my colleagues when I was Lead Enterprise Architect of APG Asset Management. Anonymised and reused with permission.

E. Suggested Reading

F. End Notes

G. Index

That’s it. But that is not all. For instance, in the text, there are references to insights from the philosopher Ludwig Wittgenstein (e.g. when rule-following is discussed, we’re deep in Wittgenstein-territory) and so forth. Such links give a bit more depth to the arguments. Note: I’m a very pragmatic and practical sort of architect and this book is not a theoretical or abstract exercise, so don’t let a reference to Ludwig here scare you off. It’s just that few people are aware that some philosophy may be extremely practical (Wittgenstein was originally an engineer, after all) and it is fun to repair what I think are misconceptions (e.g. this one) in general, not just those in EA.

The basic argument is in this summary. To actually get a good feel for it, you will really need to read the book itself, which of course is also a more pleasant read than this dry summary.