Chess and the Art of Enterprise Architecture

I recently read Chess and the Art of Enterprise Architecture (sample chapter available here), by Gerben Wierda.

 

 

I really enjoyed reading this book because the author succeeded in making me feel less stupid that I felt previously.

This is why…

 

IT standards

The IT landscape is dotted with standards for everything ranging from application and network design to business analysis and project management. We are led to believe that if only we study these standards and adhere to best practice, then our applications will have 1 million downloads, our networks will never go down and our system architecture will be perfectly aligned with the corporate business structure.

If this doesn’t happen then it’s our fault for not applying the standards correctly.

This plethora of standards is partly an allergic reaction to the good old days of IT. Once upon a time;  anyone who could hack some BASIC code had a good chance of becoming a programmer for a major bank, anyone who could cable up a LAN party had a good chance of becoming a network administrator and anyone who could persuade management that they knew what they were talking about, could become a system architect.

Due to this unprofessional enthusiasm, business departments saw themselves as captives held to ransom by geekdom. Managers rebelled against the IT cowboys and demanded standards and accountability. They asked peevishly, “I had to go to university to get my job. So which piece of paper says that the IT people are qualified to do theirs?”

The IT industry responded to this criticism and so began the age of IT standards and certifications.

 

Standards and rules

Most IT standards are not scientifically structured. Instead, they prescribe a standardised, best-practice way of doing things. In the best possible scenario, this means that an IT standard is comprised of a sensible set of rules that can be used to ensure that everyone is dancing to the same, sensible song.

Management can now feel secure in the knowledge that they have enforced a minimum quality standard. Employees can now feel secure in the knowledge that if they follow this standard they will be perceived to have done the right thing.

In reality, however, an IT standard must always represent a simplification of a complex problem. It is not possible for an IT standard to cover every nuance in every scenario, because if it did, it would describe the way the entire world works.

As Gerben Wierda relates in Chapter 3 – The Orthodoxy (page 48):

…I visited the enterprise architecture outfit of a large bank… we ended in the room of the enterprise architects… in that room was a shelf. And on that shelf stood something like twenty large binders… Those binders contained this bank’s reference architecture, which almost exclusively consisted of principles, guidelines and other comparable items (policies, suggestions, explanations, examples and so forth)… When I visited them, they were still very proud of their accomplishment…

There was a problem though: nobody used them and that… made them meaningless… it was impossible for any architect in a change initiative to know all these rules…

When organisations started to realise that these huge sets of rules (principles and guidelines) were unusable and thus meaningless, a counter-movement ensued. …speaker after speaker announced that organisations should… select roughly ten or so ‘basic’ or ‘foundational’ rules to guide change initiatives. …This approach… clearly doesn’t solve the problem either. The main reason is that these ‘high level guidelines’ are far too abstract and – indeed – high level to have a deciding effect on the actual low-level choices that create the chaos in the first place…

In short: a set of principles is either a too large set of narrow rules, or a small set of overly broad rules.

By definition, an IT standard, which defines set rules for approaching an IT implementation, must simplify a complex problem. However, simplifying complex problems guarantees that you will never address the core of the problem, which occurs in the area of greatest complexity.

How then should we relate to these helpful, but possibly limiting, guidelines?

 

Chess

In Chapter 4 – Chess, Gerben Wierda compares enterprise architecture to chess. To play chess you need to know the rules. You also need some pointers to guide your strategy and tactics. It can also be useful if you are able to memorise some classical games and moves. But ultimately, playing good chess depends on pure skill that will tax the player to their utmost.

Similarly, to do good enterprise architecture, you do need to know the rules of the game as set forth in enterprise architecture standards. But the rules are the beginning, not the end; the end is pure skill. Doing good enterprise architecture demands all the perspicacity, staying power, decision making ability and intuition that is required of a world-class chess player (page 76):

A good chess player does not follow the rules, the rules are ’embedded’ in his skill without being exactly visible during play. For enterprise architects the same must be true: the architect should not be governed by the rules, the rules should be an (invisible) part of the architect’s skills.

A 10 year old chess player knows the rules of chess in the same way as a chess grandmaster knows the rules of chess. But there is a vast difference in the way they play. The 10 year old thinks, “According to the rules, what can I do?” The grandmaster thinks, “Keeping to the rules, how can I design this game of chess?”

And the same goes for enterprise architecture. The standards are the rules, but personal skill is irreplaceable.

 

Detail and wishful thinking

The argument that IT standards are just the rules of the game, and not the be-all and end-all of good practice, applies equally to all areas of IT. Gerben Wierda makes the following point about enterprise architecture in particular, however:

Enterprise architects like to think that they are the big-picture people. I personally came across this attitude when talking to the enterprise architect for a large corporate who said, “The dev team will get into the nitty gritty, while I survey the landscape from a high altitude.” This attitude of disparaging detail, is apparently common among system architects (ibid.):

Many enterprise architects loathe details. For them, details are for (IT) engineers, a rather lowly form of corporate life… But the devil is in the details, as the saying goes… The enterprise architect has his mountain perfectly targeted in his crosshairs, but the enterprise never even hits that mountain because it has stumbled over a neglected molehill long before it gets to its goal.

Enterprise architects pride themselves on being the people who look at the big picture, but the big picture is comprised of small details. Getting the details right will probably lead to the big picture being right. Focussing on the big picture alone, will probably lead to the big picture fragmenting into shards, when the rubber meets the road.

It is a very attractive proposition to think that focussing on the big picture alone will create a nice clean corporate IT landscape. But anyone who has had programmed will know that getting the big picture right is the easy part. It is getting the last 1% of the program to do exactly what you want it do, which is hard. And getting that last 1% of the program right, may require changing 50% of the program structure. The same is likely to happen to a wishful picture of the future IT landscape, which is painted with a flourish by an optimistic architect.

Gerben claims that this fatal error is instinctive (page 86):

We do not confront complexity… but we run away from it to a make-believe simplified world where life is not complex beyond our capabilities, where we can reliably plan and feel ‘in control’. The belief in… those understandable and simple principles and guidelines gives is the idea that we are not powerless at all, and this is an extremely seductive psychological state. It is a form of ‘wishful thinking’.

In other words, getting IT architecture right is a hard problem, which perforce must take detail into account. Applying comfy IT standards at a high level, will be dashed against the rocks of detailed reality before long.

 

Precis

To summarise, Gerben Wierda’s fundamental points seem to be as follows:

• It is not possible to derive precise knowledge from IT standards, because IT standards are not based on scientific principles. Instead, IT standards consist of general advice given by professionals who have experienced similar problems to those that you are attempting to solve.
• If you come to a conclusion in your specific scenario, that is at odds with the standard, it is likely you are right and not the standard.
• You will not learn how to think precisely and rigorously by studying a standard (maybe the converse). If you want to learn how to think precisely and rigorously, go and study the works of a methodical thinker (Gerben seems fond of Wittgenstein. There is an interesting post here which matches Wittgenstein against Heidegger .)

Getting back to how Chess and the Art of Enterprise Architecture saved me from feeling stupid…

I used to gaze wonderingly at IT standards as founts of knowledge and think about all the awesomely clever people who had contributed to these standards. However, in reality, there is a limit to the fidelity of the information contained in IT standards.

IT standards are the rules of the game. The rules cannot predict the right move, they can only tell you what comprises a valid move. Studying the rules more will not provide the correct answer. Ultimately, only your creativity, insight and foresight can tell you what the best move is.