Verdict: A brilliant compass to understanding the big picture of IT change initiatives

This book is a comprehensive study about all facets of enterprise architecture (EA), ranging from a detailed definition of the artefacts related to EA, processes to deliver those artefacts and the roles involved in these processes.

The book is divided into three parts:

1. Introduction to Enterprise Architecture
2. Enterprise Architecture Artefacts
3. Other Aspects of Enterprise Architecture

As could be expected, Part 1 focuses on the fundamental questions around what purpose EA has, its history, what it actually is (from a static point of view), who is involved in it and how it works (from a dynamic/process point of view). Starting from the observation that many times, EA is equated with EA frameworks such as TOGAF, Kotusev make big opening statement that

“all EA frameworks […] are purest management fads based only on anecdotal promises and self-proclaimed authority of their own authors, but having no examples of successful practical implementation.”

Svyatoslav Kotusev, “The Practice of Enterprise Architecture”, SK Publishing, Melbourne, 2018, page xxi.

In contrast to those “fads”, Kotusev promises a conceptual study of EA that is firmly grounded in empirical analysis of 21 organisations practicing EA or providing EA consulting services as well as more than 20 interviews with architects and EA academics. Hence, the reference to the “Practice of EA” in the book’s title is certainly justified.

As Kotusev points out right at the beginning, the raison d’être for EA lies, as so many things in IT change, in the communication between the people involved in shaping that change. All organisations are inherently complex socio-technical systems who have to “align business and IT” (goals, plans, systems, processes) in order to be successful. Alas, the business people and the IT people do not always communicate well with each other. The goal of EA is to reach this alignment by creating a set of specific documents (or “artefacts”) that serve to overcome this communication gap between business and IT. These artefacts “[describe] various aspects of an organization from an integrated business and IT perspective” (ibid., p. 15). He identifies six classes of these artefacts: (Considerations, Standards, Visions, Landscapes, Outlines and Designs), which look at at rules, structures and changes within an organisation from either a business-focused or an IT-focused perspective.

The static view: Enterprise architecture artefacts

Applying these two dimensions graphically leads to the following 2 by 3 matrix, which also provides more details about the content each artefact focusses on, the stakeholders who are involved in creating them, their usual formats, and their purpose:

In defining these artefact classes, Kotusev adds more analytical dimensions to describe them, such as, whether they describe decisions or facts. The former relate to IT-planning decisions that have been taken jointly by business and IT stakeholders about long-term investments as well as short-term solution delivery. Facts, on the other hand, describe the current IT set-up of an organisation (currently used technologies, system designs, etc.). All artefacts except Landscapes are decision artefacts.

Another dimension that Kotusev uses is lifespan: Artefacts that describe Rules and Structures (see diagramme above) are permanent, i.e., they are created once and then incrementally updated. Their content is less prone to change since they describe, for example, fundamental truths (such as the principles by which an organisation operates or IT-related standards that underlie all IT-related activities) or long-term business structures (such all the IT systems that have hitherto been in operation). On the side of spectrum lie temporary artefacts (Outlines, Designs). They focus on individual IT initiatives and facilitate the collaboration between business and IT during the planning and implementation phase of those initiatives. Once the planned change has been implemented, these artefacts have served their purpose and can be discarded.

This so-called CSVLOD model is at the heart of Kotusev’s writing. The book’s second part is entirely devoted to going into more detail of each of the six artefact classes, providing some still conceptual but more concrete examples of documents used in some organisations. On the hand, these artefacts have, of course, the purpose to store information about different facts and decisions pertaining to IT. However, maybe more importantly, most of these artefacts have to be developed jointly by business and IT stakeholders in order to have a positive impact on the organisation’s success. By collaborating on creating or updating these artefacts, business and IT stakeholders develop a better understanding of each others (and also their own) realms. This leads more clarity and less misunderstanding in the dialogue between business and IT, which is how the communication gap has successfully been bridged at some of the organisations that Kotusev has studied.

The dynamic view: Dialogue, processes and initiatives

From a more process-oriented point of view, Kotusev describes how the dialogue between business and IT usually takes place, typical decision-making processes that an organisation implements and different types of IT initiatives.

The book talks about five discussion points that IT and business representatives can use as a basis for exchange and IT-related decision making:

• An organisation’s Operating Model, which defines the level of standardization of an organisation’s processes as well as the level of integration of its data between different units.
• The Business Capabilities that an organisation wants to be able to perform.
• Specific Business Needs that provide more details about how those desired business capabilities can be achieved.
• The Business Processes that an organisation needs to carry out and which can be supported by an IT solution.
• Business Requirements, which represent concrete, detailed expectations of business stakeholders towards an IT solution.

The idea behind these touchpoints is that business and IT stakeholders will not hold specific meetings to define each of their CSVLOD documents. In real life, business executives, architects and product managers might meet to discuss a particular business capability that they deem strategic (for example, “enabling potential clients of an insurance company to conclude insurance contracts instantly online (as opposed to through in-person meetings)”. The discussion about this business capability is the input that the architect then uses to create or update, for example, a Vision artefact. Creating EA artefacts thereby seems like a side product of the usual discussions that business and IT might have is very close to what I have experienced myself how EA effectively works.

From an organisation-wide perspective, Kotusev identifies three EA processes where different stakeholders collaborate to plan and implement IT changes:

• The Strategic Planning process of EA is where Considerations and Visions artefacts are developed by business leaders and architects, by using Operating Models, Business Capabilities and Specific Business Needs as discussion topics. It is part of the regular strategic management activities of senior management teams.
• During the Initiative Delivery process, business leaders and architects discuss Business Processes and Business Requirements, which helps them create Outlines of new IT initiatives, which are then translated into Designs for project teams. This EA process is embedded in an organisation’s project management activities.
• Architects are the sole stakeholders responsible for the Technology Optimisation process, which produces IT-related Standards and Landscapes and which is not integrated with other planning processes of an organisation.

Part 3 covers some additional ideas about the different types of architects, such as domain architects, solution architectes or enterprise architects, and what their different roles are in an EA practice and how they collaborate at different points of the EA processes. This part also looks at the EA function of an organisation and how governance is ensured through different types of committees that look at strategic and tactical questions either from a business or IT point of view.

There is a whole lot to the book than this, of course. The above are just some of the highlights that I think convey the core ideas of Kotusev’s model.

What I liked

• The book has a clear goal: Describing EA based on what has worked in different organisations. This empirical approach is very convincing to me and it stands in sharp contrast to most, if not all, other books about architecture that I have read so far.
• All the static and dynamic aspects of EA that Kotusev describes are descriptive rather than imperative. Unlike EA frameworks, he does not preach a particular one-size-fits-all process for implementing EA, which requires a particular set of EA documents, roles, rules, etc. He describes what successfully implemented EA practices share in common without demanding that all organisations have to fit into the same mold. Kotusev simply says “others have used these six artefacts in order ot bridge their communication gaps”. Up to you how you want to use these ideas in your own context.
• I appreciate the simplicity of his idea that EA essentially revolves around the six artefacts that he has identified and their purpose of facilitating alignment between business and IT. From my experience, IT-driven change is hard mainly because of the multitude of people involved who all have different ideas, understandings and agendas. So, boiling the practice of EA down to correctly using these six artefacts in order to sustain healthy collaboration between business and IT makes a lot of sense.
• His diagrammes are to the point. I have read many IT-related books where the diagrammes have actually made it more difficult to understand the core ideas, be it because of some low-definition WordArt that the authors thought would look nice or simply because they were too complex. The diagrammes in this book are excellent because they strip away any fluff, use simple lines and labels that print clearly on black and white, are consistent across the book and sum up the essence of an entire chapter or section. There are a lot of well-designed diagrammes in this book that make it very easy to understand its messages and remember them when picking up the book again after a while.
• There are tons of footnotes for the curious amongst us who want to dive deeper into a particular idea. You can clearly see Kotusev’s academic side in his writing style and the fact that there are 40 pages of notes and 34 pages of references at the end of the book.
• Again in contrast to EA frameworks like Zachman or TOGAF, he embeds his EA artefacts and processes in how an organisation typically works instead of imposing a new way of working that is far from realistic. The ideas that he describes are not added on top of an organisation’s usual way of working. The idea of the five discussion topics out of which the EA artefacts are derived is a very innovative way of thinking how EA can be embedded in an organisation. I suppose this approach should make it easier for business executives, architects, product managers, project teams and others who are involved in IT change to implement some of these ideas in their own context.

What I did not like

• I would have loved to see more data on the usage of the EA artefacts that Kotusev identified. He does provide conceptual examples for each of the six artefacts (e.g., Considerations are most often captured in the form of Principles documents whereas Conceptual Data Models are a much rarer type of Considerations) but I would have been interested if this is the same for small, medium and large organisations or whether there are significant differences between public and private ones.
• It would also have been very useful to see some concrete, real-life examples of these artefacts. There are models of each in the book that give you an idea what a Vision or Landscapes conceptually look like. But I wonder if would be possible to add photos or scans of real documents to show the variety of shapes and forms that these artefacts can have. That would definitely have stretched the book’s length beyond a manageable length but maybe that might be an idea for a follow-up oeuvre…
• Speaking of the book’s length, it is slightly too long, I think (440 pages in a format that is as high as A5 but wider). Not because there is anything of low value in there. It is more the writing style, which is a bit wordy. Many times I had a feeling that I had read the exact same phrase a few minutes before. Every chapter has a summary of maybe 1-2 pages at the end, which is very common. But every chapter also opens with a paragraph that summarises what the reader has read in the last chapter (in essence, a summary of the previous chapter’s summary) and introduces the content of the next few pages. This “over-summarizing” reminded me a lot of the writing style in academia and I think some of that could be cut out for non-academics.