EA - Enterprise Architecture or Extreme Aggravation

- Sanda Morar,

Last Sunday (20th April), I presented a tutorial titled “I've Downloaded TOGAF, Now What?” at the Open Group Conference in Glasgow (the sessions and presentations will be available here). It was an interesting experience and also a challenge to make the presentation interesting to an audience  comprising of TOGAF veterans and newbies.

In the presentation, I addressed the questions of “What TOGAF is?” and “What TOGAF is not?” Other aspects covered include the need for lining up support within the organization and the need for appropriate governance. This was probably one of the very few presentations addressing such basic questions. (An aside - The Open Group plan to reuse this presentation a part of the introduction pack for organizations new to TOGAF).

At the start of the presentation, we discussed the options available to understand TOGAF in 60 minutes:

• Option 1 - Read 524 pages end to end, i.e. 8.73 pages / minute
• Option 2 - Identify  the relevant parts to read and keep the rest of the pages as reference material
  

TOGAF documentation (togaf811.pdf) has 524 pages. Identifying the relevant parts to read is not an easy task. Ambiguity is never easy to handle. Here are some tips / questions to ponder, that might help you with TOGAF (based on experience ):

• A good idea is to start by understanding what you downloaded – i.e. What TOGAF is and is not and some of TOGAF’s concepts
• Before you do any more reading, remember that you cannot apply TOGAF without buy-in from your organization or your customer. How do you gather support for TOGAF and get a mandate within the organization? You have your work cut out to demonstrate the benefits of TOGAF to convince people
• Once the battle is won and you have the go ahead to use TOGAF, you will need to do some more work. For instance, you will need to customize, model and extend the TOGAF Framework to address your organization’s specific needs
  

So, what is TOGAF?
That is something you will have to explain a lot to your boss, to your customers and then to your friends and family. The definition is provided by The Open Group, but is not always easy to explain to a customer. Making a table and showing what TOGAF is and what it is not clears the ambiguity.

Which of TOGAF’s concepts are relevant and which aren’t?
Well, “togaf811.pdf” will tell you that depends on a lot of things. The problem is that when you have all those “things”, togaf811.pdf will not help you out with a rule or sort of a logic to identify the “relevant concepts”. You don’t really want to ramble the whole of togaf811.pdf in front of a customer.

How do you get buy in from your organisation or customer?
Yes, TOGAF is cool but so what? How do you show the value? Enterprise Architecture is full of the unknown and things that cannot always be quantified. So, you will be glad that sometimes things can be measured - like “customer satisfaction”

How do you customise, model and extend TOGAF?
Again, togaf811.pdf will tell you that “it depends”. This goes back to the question of what TOGAF is and what is not. TOGAF is a generic and very good framework, but you will have to apply yourself to make TOGAF work for you.

I have noted below some of the thoughts expressed during the course of a stimulating discussion (post-session)

• TOGAF is not easy but it can be make it work for you in a matter of weeks
• I felt the same way about TOGAF, that it is difficult to understand
• Does the new version of TOGAF address the problems highlighted in the session?
• Are there best practices and guidance about how to customise, model and extend TOGAF?
  

I am writing this late at night. I had an awesome evening here at the conference and I learned a lot of things and met a lot of cool people

I’ll cover more about TOGAF in my next post - what TOGAF is and what it is not, how to enlist support, how to customise, model, extend TOGAF and what to do next.

Posted by Guest Author at 11:15 AM | Permalink | Comments (0) | TrackBacks (0)

- 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”.

The above do overlap and there are other types of 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

Posted by Andrew Manning at 06:20 AM | Permalink | Comments (10) | TrackBacks (0)