Wednesday, June 25, 2008

What is an Enterprise Architect?

Ask ten IT folk and you'll get ten different job descriptions. The simplest illustration of the problem is made by Charles Edwards on his AEA site: Two EA definitions:-

  1. Enterprise Architecture (Software Developers or Project Managers (segment) (view)) = The development of a coherent set of Application Architectures for an Enterprise level system or set of Application systems. In some cases this might also involve the definition of Business processes and other business domain modeling specifically for the Application. Typically carried out by a Solutions Architect (and those) who know about Databases, Messaging, Portals, Application and Web servers, etc. This would also typically be implemented in a Programme, a Project of work or even as a Business as usual process.
  2. Enterprise Architecture (CEO, CIO (enterprise or holistic view)) = the management and definition of the Architecture of the Enterprise (set of organisations) that includes everything from the Business Strategy, to the Business Operation Architecture (static and dynamic) for the purposes of optimizing the enterprise; the Information systems (made up of Applications, Services and Data) and the Technology and Infrastructure that this runs on. EA also includes aspects such as Security, Data, People and Performance. The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investments are aligned. Enterprise architecture models allow traceability from the business strategy down to the underlying technology, in order to do impact analysis and have the ability to react to changes quickly, govern the Architecture and guide the business. To contain the Knowledge and the memory of the Enterprise (Architecture) in a single point of truth.

I definitely see EA as the latter (with the exception of the last sentence that I fundamentally disagree with - I think we EAs are the guardians of multi-POVs and therefore sense-makers of the multiple 'Truths' that exist in all organisations/communities) and from, recent conversations with Charles Edwards and Sally Bean, I seem to be in good company.

Sally and I were discussing this yesterday and agreed that the former was much closer to an Engineer's view (we decided engineers probably don't make the best EAs – although there are always exceptions – I used to write PLAN code!). I mentioned that I'd just started to qualify my 'Enterprise Architect' moniker with 'Demand-side' which seemed to resonate with Sally. I often thought of EAs as sort of 'Super-Business Analysts' (I held the BA title longer than that of SE (PLAN progemmer)- which was my saving grace!) . So maybe my BA roots help explain why this is why the 'Demand-side Enterprise Architect' label works for me. Sally simply describes herself (with appropriate Dilbert-like irreverence as “Some one who talks to people and draws pictures” which I interpret as just the same as me (what I've been known to call a 'Super-Business Analyst with a satchel full of crayons').

I suppose many would argue one or other or both or another of the above EA descriptions is THE correct definition of EA. Meanwhile, the rest-of-the-world continues to be confused about what we do and why.

So rather than search for a single version of the Truth about EA, I'm hoping that adding 'Demand-side' to my job title might just avoid some of the confusion about what I do and what I don't do within the apparently highly ambiguous label of Enterprise Architect.

A footnote: Sally and I also identified another perhaps more sinister type of EA – which I'll call the 'Religious Fundamentalist Enterprise Architect'. These EAs seemed to be more bothered about their chosen methodology (EA frameworks & processes) than the business outcomes and the underlying philosophical and abstract reasons for EA that simply resolve to qualitatively better information systems and more useful and cost effective IT.


Cybersal said...

I wrote a piece a couple of years ago for the NCC 'IT Advisor' publication on 'The Elusive Enterprise Architect' which describes my view of what a true Enterprise Architect does. It draws on an article that Dana Bredemyer and Ruth Malan wrote for Cutter Consortium as well as my own experience.

Nigel Green said...

Sally (cybersal),

I just read your NCC piece – I will be recomending it to EA colleagues. I think the subheadings from the article are right 'on the money': -

Core capabilities of all enterprise architects:
* Communicators and change agents. * Visual system thinkers and modellers with foresight. * Fast learners * Principled pragmatists. * Incisive consultants and troubleshooters * 'Big picture' thinkers.

I recall a similar list in Service Orient or Be Doomed! by Jason Bloomberg and Ronald Schmelzer (the Zapthink guys).


Unknown said...

Some nice builds on this discussion from the Infosys blog here. I wonder if there would be value in creating an EA competency scale/framework that would help us explain the flavour of EA 'services' we each offer?


Stephen Timbers said...

I find there are two types of Enterprise Architect. Those who approach the problem from the front end of the project lifcycle, and those who approach it from the mid-point.

If your route to EA was mostly through the Requirements Analysis, Process Modeller, Data Modeller route it should be no surprise you are more comfy with the concepts of Why? than those of How?

When talking to people who phone looking for an EA I always start by asking what they mean and stressing that I am a Front-end EA not a Back-End one. Opportunities for puns abound.....