Noticed a tweet yesterday from Brenda Michelson about enterprise architecture (EA), prompted by a GigaOm post from James Urquhart about how cloud might impact on EA:

to which I responded:

This prompted a Twitter conversation between myself and James Urquhart about the appropriate responsibilities of enterprise architects, which got to this point:

where we seemed to have exceeded Twitter’s 140-character constraint, and I decided I needed to write this post. 🙂

 

First, enterprise (or business) architecture describes how a business or organisation is (or is going to be) built to accomplish its purpose. It is a three-legged stool (so every “leg” is critical):

  • People: the roles, responsibilities and skills required of the people employed to achieve the business purpose
  • Organisation: the values, strategy, operating model, management structure, policies and procedures, and business capabilities required to achieve the business purpose
  • Systems: the business processes and supporting technologies required to achieve the business purpose.

The foundational artefacts of EA are:

  • the organisation’s values (often embedded in a “values statement”)
  • a definition of how an organisation is going to differentiate itself; its value proposition and competitive strategy
  • its operating model (for the best explanation of this, see Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, particularly Chapter 2)
  • the desired business outcomes or objectives.

Collectively, these make up the organisation’s DNA, and define what it WILL do, and (importantly) what it WON’T do, to achieve the business purpose.

Just like a city, a business has several “levels” of architecture at play. The next set of architectural artefacts at the enterprise level include (not an exhaustive list, just some of the more important things):

  • a model of the business capabilities (“what” the organisation does; its functional decomposition)
  • a model of the high-level business processes (“how” it performs those functions)
  • organisational structure chart
  • policies and procedures manuals
  • a technology portfolio.

Beyond that there will be more detailed functional descriptions, individual role descriptions, system documentation – other “architectural” designs at narrower, deeper levels of detail (all the way down to software code, if necessary). Critically, from the highest level of abstraction (enterprise architecture) to the lowest (writing a job description, or cutting some software code) there should be a clear relationship between the levels (a framework), so that no matter what the task, your efforts should be traceable back through all the layers, up to the business purpose and the organisational DNA. Just as they are architecturally different in nature (like the difference between a town plan, and an individual building design), they are the purview of different roles – solution architects, business analysts, organisational development specialists, etc. The work of the enterprise (or business) architect will influence, inform and occasionally constrain them, but it will be the responsibility of this different role to produce the necessary level of architectural detail.

Keen observers will notice that I haven’t delved very deeply into technology yet. The reason is simple: at the enterprise level, architecture is a business responsibility, not an IT one. While the impact on IT will be considerable, it deals with the “what”, not the “how”, and (as with all the other business specialisations in play, like HR and accounting) those lower-level decisions are left to the specialists. This is (in terms of James’ original post) where “cloud” is beginning to make an impact – it’s a solution design, rather than enterprise architecture.

That being the case, where does governance come into it? Just like architecture, there are several (related) levels of governance – I’ll concentrate on two: architectural and IT (since I suspect that this is what James’ question was aimed at).

Architecture governance is strategic and transformative in nature, and extends to decisions beyond the domain of IT. At the highest level, a company board or executive committee will make decisions on purpose, strategy, values and operating model. These are the touchstones to which all company activities should be linked. At the next lower level of abstraction architecture review boards define policies, principles and guidelines that must be complied with to ensure integrity of the business design. These will include a Technology Architecture Board (or similar) that maintains and enforces principles that are technology-related, without specifying a particular technology solution. Architecture governance is a holistic approach that requires a broad framework, such as Fragile to Agile (the framework I prefer to use).

IT Governance, by comparison, is more operationally focussed and relates entirely to IT services such as project, IT configuration, incident and problem management; and business continuity/disaster recovery planning. IT governance can be accommodated via frameworks such as COBIT and ITIL.