The value of EA
June 1st, 2007
I recently gave a presentation at a CIO Summit, promoting the need for Enterprise Architects in general and for preferring professional grade members of the Association when hiring staff or contracting with service providers. The feedback suggests that the presentation was well received but I came away with a couple of impressions I would welcome your comments on.
First, it seems that the majority of CIO’s do not enjoy a relationship with the CEO where the latter sees IT in a positive way. IT seems to be perceived as something that holds back innovation rather than something that leads it. A part of the business where things can only go wrong, where the enterprise continues to pour money and where 80% of the budget is spent just keeping what they have going, rather than delivering any real benefit.
Second, less than a handful of CIO’s had heard of TOGAF (or any other industry standard frameworks for that matter) and even fewer had heard of maturity models.
Third, the things that were top-of-mind in the people I spoke with were things such as the theft of credit card details of over 45million customers of the retail group, TK Maxx, compliance generally and staff issues, as well as pressure to reduce IT spend.
So, if this is the reality of your CIO’s world, staff issues excepted, we should be able to apply enterprise architecture to address these priorities. The challenge, I suspect, in many instances is overcoming the concerns that an EA effort will do no more than take people’s time away from other more pressing priorities, take a long time to produce anything at all and when it does will only tell us what we already knew. Now no one is going to say that as such. It is more likely going to be phrased in a sentence that includes those three little letters ROI.
So, in this environment, rather than trying to sell anyone on the idea of an EA effort to address the CIO’s issues, I would suggest picking one discrete subject, talk to the people involved in it and produce a brief report summarizing the situation and recommending some quick wins. You will most likely find that if there are problems or opportunities, that someone you talk to will know about them. This can be done with relatively little investment of anyone’s time and if there are no quick wins, you may still be able to ease the mind of the CIO on that subject. If there are, then don’t forget to give the majority of the credit to an EA approach, rather than taking it all for yourself or giving it all to the contributors to the study. Just make sure that the contributors get there fair share though.
Guidance on this approach can be found in the TOGAF Resource Base under the heading of Business Scenarios.
I would be interested in whether or not these are issues in your enterprise and what approaches you have used with success to promote the value of EA.
Allen Brown
Entry Filed under: About AOGEA
The issue is ROI. Concentration is on ROI. To sell EA focus should be on return value. I read a paper by Roger Sessions, “A Better Path to Enterprise Architecture”, of which he wrote on this very topic. His position on implementing EA successfully is based on partition-iteration approach. The advantages of partition-iteration approach is that you start showing a returned value in a shorter amount of time (time-to-value TTV) because your deliverables are segmented, thus increasing your success ratio with each segment and shorting your TTV. As soon as you demonstrate some value implementing EA, the sooner you will get the buy-in your promote EA.
I agree with MPenabad on the time to value concept, but ROI is quite difficult to show in the short term, it comes from a longer term cumulative set of lots of short wins.
I also believe its about managing the CIO/CEO’s perceptions. By this I mean that if you use an iterative approach to delivering EA value, and you show (prove) by measuring and actively marketing the value you add each iteration, (where iterations are +/-1 month each), then you start showing the value and they will begin to buy-in.
It is all a bit of a catch-22 situation however, because of the 3 problems that Allen Brown alludes to in his blog, because until you get the CIO and CEO to accept that the enterprise needs an EA Practice in the first place, you won’t yet be able to show value.
I guess TOGAF need to keep on with all the good work they are doing on marketing EA (conferences, etc.) and slowly it will get through to the CEO’s and CIO’s. In the mean time myself and a few people are building a process called AgileEA which takes an iterative, adaptive and evolutionary approach to delivering EA value. - we’d appreciate any collaboration on the wiki and forum from any of you too.
TOGAF is a tool - a very good tool but one that needs experience and knowledge to be used to best effect. And effective application of a tool is where the real value is generated and then only in the final results produced. So I am not surprised that people’s experiences show TOGAF of little real interest, certainly in the inital stages of establishing EA, to any CXO who will be looking to the bottom line. However, I would certainly expect architecture frameworks in general, to be included in the scoping of, and artefacts to be expected from, an EA capability/practice/service.
EA is a journey and starting small with more immediate returns is absolutely the way to go - then building on that credibility and moving up the architecture capability maturity curve.
As an example, first focus on architecting specific projects ensuring people, process and technology are adequately addressed in an end-to-end business or operational context. Then look at commonality and potential for reuse across business units with shared solutions underpinning business processes. Then consider real enterprise architecting where common processes and business information are defined and supported by shared service models together with all the ITO and/or BPO that might be appropriate.
Each of these steps should make people think about the savings and improvements that were enabled and the problems which were avoided by taking an architected approach. Its all about engagement and value-add - focus on what your organisation needs and can get from EA, and build sustainable working relationships with the key players and your journey to EA adoption should be made that much easier with a wider IT and business community being involved and sharing in improvements to that bottom line.