One minute enterprise architecture

June 2016

Clockwork mechanismSvyatoslav Kotusev, an independent researcher, explains why he thinks that real enterprise architecture practices don’t really reflect the ‘spirit’ of EA frameworks and proposes an alternative terminology.

Presently the notion of enterprise architecture (EA) is closely associated with EA frameworks. However, my analysis shows that real EA practices resemble neither the ‘letter’ nor the ‘spirit’ of EA frameworks. Instead, ‘one minute enterprise architecture’ provides much more clear, realistic and powerful way to explain the notion of EA as well as the general mechanism of EA practice. It conceptualizes EA as a collection of four types of EA artifacts (principles, visions, standards and models) and EA practice as a set of three EA-related processes (Decision-Making, Architecting and Implementation).

Frameworks hardly explain enterprise architecture

Currently for many people the notion of EA is closely associated with popular EA frameworks, such as The Open Group Architecture Framework (TOGAF)1 or the Zachman Framework2. However, as I previously reported based on my analysis of EA practices in multiple organisations, successful TOGAF-based EA practices have essentially nothing to do with the actual TOGAF prescriptions3,4. My additional studies completely support the previous conclusions and can be also generalised from TOGAF to other EA frameworks as well, i.e. no real vestiges of any EA frameworks can be observed in organisations successfully practicing EA.

Interestingly, neither specific details nor even general ideas advocated by EA frameworks can be found in real EA practices. From the details perspective, nobody fills the cells of the Zachman Framework, nobody follows the steps of the architecture development method (ADM) of TOGAF and nobody develops the heaps of EA artifacts recommended by TOGAF, even among the organisations included in the list of TOGAF users provided by The Open Group5. From the conceptual perspective, nobody strives to create formal comprehensive descriptions of their organisations analogous to buildings or airplanes as recommended by John Zachman, and nobody follows ‘plan the whole enterprise and then implement’ sequential logic advocated by TOGAF. Therefore, successful EA practices resemble neither the ‘letter’ nor the ‘spirit’ of EA frameworks.

What is then enterprise architecture?

But if the descriptions of EA and EA practice provided by the sources that are often considered as definitive for the very EA discipline are inadequate, then what is EA and EA practice? My analysis of EA practices in organisations suggests that EA can be conceptualized as a collection of four broad types of EA artifacts: Principles, visions, standards and models.

Principles are high-level policy statements helping align information systems with the organisational philosophy and improve the conceptual homogeneity of the IT landscape. Visions are abstract business-oriented, often one-page diagrams helping manage IT investments and enable the long-term strategic information systems planning. Standards are implementation-level rules helping limit the range of supported technologies and achieve the technical uniformity of the IT landscape. Models are detailed technical diagrams helping select best implementation options and carry out the mid-term and tactical information systems planning.

Principles and Visions are business-facing EA artifacts. They are brief, contain only the most essential information, and written in a plain business language. The purpose of these EA artifacts is to help senior business leaders manage IT. Essentially, Principles and Visions serve as ‘interfaces’ between business executives and architects. On the other hand, Standards and Models are IT-facing EA artifacts. They are purely technical, highly detailed and use IT-specific terminology. The purpose of these EA artifacts is to provide an actionable guidance for rank-and-file IT specialists. Essentially, Standards and Models serve as ‘interfaces’ between architects and project teams.

From the perspective of these four types of EA artifacts, EA practice can be conceptualized as a set of three main EA-related processes: Decision-making, architecting and implementation. Decision-making is a process where top managers and architects collaboratively decide on how a company should operate and where the IT investments should go. Principles and visions facilitate their communication and reflect the resultant strategic direction agreed by business and IT. Architecting is a process where architects translate the agreed strategic direction embodied in Principles and Visions into more specific plans actionable for project teams. Standards and Models are produced as an outcome of this process. Implementation is a process where project teams supervised by architects realise the IT systems required by business. Standards and Models are used as reference materials by project teams guiding their delivery efforts.

This ‘one minute’ conceptualization of EA and EA practice is shown on Figure 1.

One Minute Enterprise Architecture Diagram
Click image for larger version

Figure 1. One minute enterprise architecture

‘One minute enterprise architecture’ is arguably the simplest possible way to explain the notion of EA as well as the general mechanism of EA practice. Regardless of its apparent simplicity, this conceptualization is evidence-based, comprehensive and powerful because it clearly and realistically describes the relationship between all the essential documents, people and processes constituting a successful EA practice in real organisations.

The views in this article are the views of the author and are his own personal views that should not be associated with any other individuals or organisations.

References
  1. TOGAF. 2011. 'TOGAF Version 9.1,' G116, The Open Group.
  2. Sowa, J.F., and Zachman, J.A. 1992. 'Extending and Formalizing the Framework for Information Systems Architecture,' IBM Systems Journal (31:3), pp. 590-616.
  3. Kotusev, S. 2016. 'Enterprise Architecture Is Not TOGAF.' Retrieved 21 January, 2016
  4. Kotusev, S. 2016. 'The Critical Scrutiny of TOGAF.' Retrieved 15 April, 2016
  5. TOGAF. 2016. 'TOGAF Users by Market Sector.' Retrieved 23 June, 2016
 

Image: iStock/61719316

Comments (7)

Leave Comment
  • 1
    Jonathan Ladipo wrote on 6th Jul 2016

    Really enjoyed this. A very interesting, thought provoking and concise article. Frameworks are definitely not sufficient for explaining or promoting the value or relevance of EA to most organizations. I definitely agree EA are better conceptualized as a set of related processes: Decision-making, architecting and implementation, as EA is more about the journey (what, when, why, how) being undertaken rather a destination.

    Report Comment

  • 2
    Paul Reason wrote on 7th Jul 2016

    Thought this captures the true spirit of EA, which I described to my COO as more like Town Planning than Architecture.

    Report Comment

  • 3
    Conor Armstrong wrote on 8th Jul 2016

    Agree with much of what is being said here. From experience many of our clients who initially plan EA based on TOGAF or Zachman inevitably simplify it to something more in line with what is being described. FWIW, for a successful EA realisation, I have never seen one of the established methods delivered without simplification.

    Report Comment

  • 4
    John Lo Hong Kong wrote on 21st Jul 2016

    Thanks. I learnt a lot from your consolidation of the existing industry situation. It's a bit pity if even unicorns and great companies do not follow significantly. May I contribute some of my mind:-
    1. Practically, I have headache how to increase the Top Managers awareness of Principles when they make decsions and how to minimize the wastage or project team frustration due to wrong assumptions in reference materials.
    2. For the 1-min EA, it seems Roadmap and its progress and compliance check and adjustment are inside Model and Implementation. In practice, many values are realized long time after implementation.

    Report Comment

  • 5
    sachin bansal wrote on 21st Jul 2016

    Very good and concise representation of EA. In my opinion, "Decision making" could be replaced with "Strategy" .

    Report Comment

  • 6
    Ian Rowlands wrote on 22nd Jul 2016

    This piece matches what I have seen (and so, of course, it's correct ;-) ). I suspect that the frameworks provide excellent mental models for thinking about Enterprise Architecture, but are "overweight" for the actual practice.

    Report Comment

  • 7
    Praful Lele wrote on 27th Jul 2016

    Good article which clearly indicates a flow of decision making process. I would add to Sachin Bansal's points that both strategy and roadmap along with Business Policy sit at decision making process. These would trickle down into Principles. I thought vision would guide the decision making process as that drives your strategy and roadmap. Happy to know your views about this.

    Report Comment

Post a comment