2 September 2015

Are Architects ruining Enterprise Architecture?

Photo credit: Alan Levine

The signs are not good. A recent CIO Survey reported a big decline in demand for architects. Some highly respected experts are promoting new concepts, such as evolving microservices and "Death Star" diagrams which appear to defy many architecture conventions. I have worked in several organisations where I have been told not to mention architecture because executives are still angry about previous failed initiatives. These are not isolated instances. Visit any of the busy architecture community forums and you will find numerous discussions about the woeful state of the discipline and proposals for how to remedy the situation. My current role is focused on the enterprise architecture aspects of the CIO's portfolio so this is all a bit worrying. Can we save architecture? Should we try?

The answer to the latter question is a resounding yes! When it works, architecture thinking and tools help executives make better decisions by balancing the efficiency that comes from scale and top-down coordination with the quality and pace that small, autonomous teams can achieve. Architecture is involved in tackling almost every CIO challenge covered in this blog. I would not be surprised if architecture replaces project management as the foundation of portfolio management in the future.

So how do we save architecture? I think we have to start by changing our architects.

Attack and defence

I've been using chess as an analogy at work quite a lot recently and it might help explain what needs to change in architecture. A chess game ends in one of a small number of forms of mate - checkmate is the most famous but there are others. The end of a game of chess is quite easy to define - probably a single page will do - and almost all players have a clear understanding of it. The best players do not have a more detailed or precise definition of checkmate than novices. All of the action in chess, and where players show their calibre, is in the long series of small moves - how they use their pieces to control the chess board and manipulate their opponent.

In enterprise architecture a target architecture takes the place of checkmate. These are normally fairly obvious and fall into one of a few common patterns. Most can be summarised in a page or so. Your opponent in the enterprise architecture game could be a well-known commercial competitor who is deliberately moving pieces to spoil your plans. In addition, the pieces in this game will get moved by unfortunate events, shifts in your supply chain or even competing internal demands for money and resources. Just as in chess, you can't control your opponents directly but you can affect or limit their moves by the way you use your pieces. They will also have some patterns or preferences which you can learn about through observation and experience.

From novice to Grand Master

I find many architects are excessively focused on the target architecture. This is a bit like a novice chess player seeking a more sophisticated and precise definition of checkmate - you can't win at chess this way. By contrast, chess Grand Masters are prepared for games which might take 40 or so moves but they only really have a grip on the next 5 or 6 steps. They focus on how the game will progress, not just on how it ends, and use all of their pieces to put themselves in a strong position.

Enterprise architecture has a lot in common with this. Architects need an understanding of the end of the game but they should not be consumed by it. It is more important to understand all of the pieces and how they can be combined to maintain a strong position. For enterprise architecture these pieces do include design and technology but they also include things like leadership, governance, capital investment, procurement and, of course, portfolio management.

Check! Now it is your turn to make a move

Eventually, enterprise architecture practices will mature and the architecture community will change but this does not seem to be happening very quickly. In the meantime, here are some steps which CIOs can take to start to change their architects and save architecture.
  • Educate your peers and your team and set expectations about how architecture will work.
  • Avoid grand architecture initiatives, especially those focused on IT.
  • Get your architects out in the business working with central strategy teams or solving problems with your major projects and programmes.
  • Invest in broad capability development for your architects which should including a good working knowledge of how your organisation manages money and handles operational risks.
  • Measure architects engagement in decision making, not their production of architecture documents.

Unfortunately, many of our current architects will not want to play this game and organisations will need to make some tough choices about who they keep in their teams and what roles they ask them to play.

Related blog posts

Service architecture and user journeys by @benholliday

Junior designers vs senior designers by @joule

Is enterprise architecture completely broken by @TheEbizWizard


  1. Richard, you nailed the topic with this line "Measure architects engagement in decision making, not their production of architecture documents."
    If EA is dying, it because architects are killing the profession. In my job as EA Consultant, I come across many EA functions where focus is on target architecture, like you mentioned, and they are completely disconnected from what is in the portfolio of projects / programmes. Architects have their own view, and often a complex one, of principles that every new initiative must follow. More often than not, these EA principles are vague and act as road-blocks and create administrative overhead for design and plans of biggest investment programme of the organisation. Architects often blame organisational politics and lack of involvement for not being able to contribute to decision making. Part and parcel of that problem is that architects are offering their services at terms and timescales that are unacceptable to their customer (Business change function / Programme Directors / Business Unit Heads and of course, CIO).
    The second problem is complexity: If TOGAF wasn't complex enough already for non-architects, then Archimate - the latest initiative from Open Group - surely is. I cant put an Archimate diagram in front of CIO before I sent him on a archimate modelling crash course! Architects often love the complexity they build into architecture viewpoints (isnt that a complex name for deliverable) and artefacts (or artifacts or whatever).

    Why cant we make simple project scope architecture which a Project manager can use during the Project Mandate and initial business case development? Why cant architects work with Programme Manager to develop logical architecture representation of change that will be delivered by a programme and define additional business capabilities that would be required to support the new lines of business? Wouldn’t a programme director like to include such a supporting deliverable to inform the business case for programme and justify funding required?

    1. Anil, Thanks. You've raised lots of good questions at the end of your comment. I think the answer to all of them is: "We can!" Any hints or tips to share about what has worked for you?

  2. Nice to see someone else use chess as an analogy for EA, though your analogy (which is interesting) differs from mine with respect to the end state. I think you will enjoy Chess and the Art of Enterprise Architecture. It uses chess as an analogy for more elements of EA, these are in a summary also available via the book's home page (http://bit.ly/eachess).

    1. Gerben,

      Thanks. I will take a look at Chess and the Art of Enterprise Architecture.



Contact Us


Email *

Message *