Enterprise Architects: Time for more job titles?
- Andrew Manning, Principal Architect, Infosys
I noticed a recent survey that showed a marked increase in the number of Enterprise Architects (EAs) over the past several years. A reflection, perhaps, of the increased awareness of the importance of the role; of pressures making architectural benefits more relevant than ever; and a broader use of ‘Enterprise Architect’ (to cover: business architects, data architects, application architects, technical & infrastructure architects… as well as ‘solution’ architects working at program and project levels).
It started me thinking about whether the title ‘Enterprise Architect’ needs a bit of a makeover. The following are some of the titles that sprang to mind as I waited for a delayed flight:
- Extraprise Architect - this architect looks across organisations, aiming to join things up at organisational interfaces. The need for these ‘EAs’ is driven by changes at a social, business and technical level that lead to processes and interactions that can span the globe and are continually changing. Distinct in many ways from the more introspective ‘traditional’ EA.
- Agile Enterprise Architect - driven by experiences of doing things iteratively and collaboratively. The “sleeves rolled up” approach to EA. Can lead to clashes with top down centralists.
- SOA Enterprise Architect - quite often an Agile EA at heart, with an eye on making use of external services (see Extraprise EAs). The SOA EA who wants to extend the use of SOA beyond a small number of projects, and away from the technical angle knows that they need the disciplines and governance of ‘traditional’ EA and Business Architects. Apart from anything else, the SOA movement can help drive greater agility into the heart of EA. Overtime, SOA EAs might be looked down on by “Event Driven Enterprise Architects” and Goal Orientated Enterprise Architects”.
- Meta Enterprise Architect – for those EAs who do less creation of architectures but who focus on setting up EA capabilities and groups. A pragmatic type of Meta EA is the “Guerilla’ Meta EA. These take a more agile /iterative, ‘duck and dive’ approach to implementing EA capabilities. Top down, bottom up, from the middle outwards; whatever helps take things forward, even if it’s only a few steps at times. Not to be confused with the "Gorilla" Enterprise Architect who uses size (budget, position…) to achieve the same objectives, steam rollering through those who stand in the way.
- Benefit Enterprise Architect - highly sought after (especially when they have a keen eye for budgets emerging from the mist). Most Agile EAs see themselves as Benefit (or ‘Value’) EAs. This is increasingly an area for Business EAs.
- Enterprise Architects 2.0 - have an almost religious fervour about getting two way involvement with those driving forward change- especially project teams. As architecture gets taken closer to the changing organisational ‘edges’ this can lead to a revelation about what architecture means from the consumer perspective. Has a natural affinity with Agile EAs and some Extraprise Architects. Keen on web2.0/enterprise 2.0 .Sometimes labelled as “Collaborative EAs”.
This blog isn’t intended to provide a comprehensive taxonomy of EA roles. Most EA groups will need to cover the above; depending on scope, culture, mindsets and priorities.
How different people might react to or consider taking forward the points above could be an interesting indicator as to which EA title might best fit
P.S. for a survey of EAs in various companies and their priorities see http://www.infosys.com/IT-services/architecture-services/ea-survey/enterprise-architecture-survey-2007.asp
Comments
Hi Andrew,
This article is very interesting and I fully concur with your view of associate meaningful job titles to enterprise architect role. I am in the process of migrating from team lead/ application architect position into an enterprise architect role and am thinking how to quantify value of an EA? What you have suggested is great in that you clearly get a sense of what an EA does by looking at his/her title. "EA" is too vague any way in my opinion too.
Thanks for this great blog.
Posted by: Mahesh Gadgil | April 28, 2008 02:26 PM
Having spent 5 years as a partner with one of the people considered to the "father of enterprise architecture", and having delivered the EA at over a dozen Fortune 100 companies, I have a pretty good idea what EA should be (at least initially) defined as. However, I have struggled for many years to come up with an adequate analogy that can be quickly and effectively communicated to anyone.
The analogy that I have found to be most understandable, is the following; If the CIO is the conductor of an orchestra, made up of strings (communications), brass (software), percussion (infrastructure), woodwinds (security), etc. then the EA role is the composer - the one that writes the musical score that allows all the sections to play together to create harmonious music. The inputs to this orchestrated plan for the business are strategy, legacy environments, budgets, skills, and future trends.
Enterprise Architecture fundamentally results in a "system of systems" view of the environment, solving a business and management problem.
Technology architectures are a "system of components" (where systems produce stand-alone value, and components have to be composed into a system to produce value) - solving a technical set of issues. Software, data, network, security, ... architects fall into this category, optimizing their silos.
Most of the so-called EA roles out there are technical architects, and not true enterprise architects. The EA role deals with corporate strategy, business initiatives, the technical domains (platforms, storage, communications, application development, packaged software, tailored applications, databases) process and methods, staffing/skills, and organizational design, and how they should all fit together to enable business value.
Historically, software was NOT the center of the universe (enterprise) - the delivery of IT service capability was. This has been lost by many technocrats, relegating the EA leadership role to a glorified programmer. The Problem - relatively low dollar (software / data driven) architecture efforts typically drive the bigger dollar IT infrastructure investments – often not the best approach, nor the one that can benefit a company the most.
Posted by: Kirk Rheinlander | May 7, 2008 02:40 AM
@Mahesh - Thank you for your comment. You raise an interesting point about quantifying the value of EA. My thoughts on the topic are here: http://infosysblogs.com/ea/2008/05/quantifying_the_value_of_enter.html
Posted by: Andrew Manning | May 12, 2008 05:40 AM