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:
heading to @forrester #FEAF12 today. Curious to #entarch crowd reaction to @jamesurquhart (rightly) poking the EA box – https://t.co/OMuR3HII
— brenda m. michelson (@bmichelson) May 2, 2012
to which I responded:
@bmichelson My first reaction: what @jamesurquhart calls EA I describe as solution architecture/system design; see https://t.co/hOqjVLs2
— Ric Hayman (@achurchassoc) May 2, 2012
This prompted a Twitter conversation between myself and James Urquhart about the appropriate responsibilities of enterprise architects, which got to this point:
@achurchassoc @bmichelson OK with that as well. Not all EAs seem to think that, however. Where does governance fit into EA?
— James Urquhart (@jamesurquhart) May 2, 2012
@jamesurquhart @bmichelson 1. Then I'm not sure they're EAs 🙂 2. will have to address governance in a blog post – needs more than 140 char
— Ric Hayman (@achurchassoc) May 3, 2012
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.
In the context of your post your first tweet makes sense as does your governance model. Others no doubt have different frameworks which is where most of the debate lies.
Walter @adamson
Well, it’s certainly true that we see the world through the prism of our own experience … and you’re right; that’s what creates a lot of this debate. But that also explains why this particular framework is my current preference: it helps me (AND my clients, most importantly) make sense of the business environment.