- What is EA all about, what is the (emerging, changing) identity of EA?
- What is the value proposition for EA?
I personally find the second of these two questions much more important and interesting than the first. Questions of identity often result in entrenched positions, and (as I discussed in my previous post Think Globally, Act Locally) can produce division between different views. In the case of Enterprise Architecture, there is a traditional view (EA-as-IT-planning) and an emerging view (EA-as-business-strategy).
I think the question about the value proposition opens up a much more interesting discussion about the possible evolution and potential multi-tasking of enterprise architecture teams.
(EA itself needs to understand its business model to help it survive. The full exploration of the value proposition needs something like the Osterwalder business model canvas we discussed in our workshop on on Business Modelling for Business Improvement, so I'll have a go at that. See below for Osterwalder template.)
One of the key questions for the value proposition is the timescale. Sometimes enterprise architecture is described in terms of longer-term value: through-life coordination and capability management. Some people are still comfortable with this; but other people see a difficulty with the fact that business needs to wait so long to realise this kind of value, or even to measure it properly. In contrast, there is growing support for a much shorter-term delivery of value.
Essentially, that means EA must deliver value within same timescale as projects. And what is the nature of this value? Roger Sessions points to the massive failure rate in IT projects, and argues that's something EA can and should be fixing. In other words, the EA value proposition can be defined in terms of improving IT project success ratios.
I see two difficulties with this. The first is one of perspective. If EA is working closely with the projects, then how is the EA perspective any different from project perspective? And if the problem is that projects are doing things wrong, then how can EA fix the problem from within the project perspective? The EA view of business requirements is hardly going to be very different from that of the good business analyst on the project. If EA is no longer taking the long view, then its value proposition is largely based on the hypothesis that the architects may have a bit more knowledge and experience than the business analysts, and some slightly superior tools and techniques. But we might achieve this outcome more efficiently and effectively by simply upgrading the business analysis practice and redeploying the architects as senior business analysts. Indeed, some IT organizations seem to be moving in this direction, although they haven't taken away the formal job titles yet.
The second difficulty is that the job of overseeing projects and ensuring project success is hugely duplicated. Within a large IT organization, we might have project management, programme management, IT governance, tools and methods, quality management (control and/or assurance) as well as enterprise architecture, each with its own "body of knowledge", each trying to prevent projects from getting things wrong (and claim the credit). The word "silo" springs to mind here. (All of those roles might possibly be held by the same person, but does that remove the complexity?)
From a systems-thinking perspective, this looks completely crazy. If the value proposition for EA is simply to correct things that projects are doing wrong, then this counts as "failure demand". If the value proposition for EA is to make sure that projects are successful, then that's putting the responsibility in the wrong place. It is the project's job to be outstandingly successful. If they can achieve this unaided, this appears to make EA redundant.
In summary, I'm not convinced that the traditional value proposition for enterprise architecture is convincing to its customers, whoever they are. (Who are the customers anyway, the CIO or CFO who have to pay for it, or the business line management and IT project managers who are being asked to spend time and effort on EA "for their own good", and are not always grateful for EA attention?) I think the top priority for the enterprise architecture discipline is to find and formulate a viable and meaningful value proposition. And it really doesn't matter whether we call it "enterprise architecture" or not.
Thanks to several Twitter friends for today's discussion: A Jangbrand, Anders Østergaard, Andrew Townley, Brenda Michelson, Colin Beverage, Roger Sessions, Todd Biske. (Did I miss anyone?)
See also: Purpose of Enterprise Architecture (January 2012)
Hi Richard,
ReplyDeleteI think that's a pretty good summary of the day's discussion (at least the parts I saw because I wasn't initially following everyone). There were really two distinct views, and I think Roger's right that more pressure needs to be put on traditional EA practices to demonstrate how they are actually delivering value to the business.
One answer could simply be defining more meaningful metrics. I've found it difficult to get a consistent view of metrics used in the organizations I've talked to about EA. If you don't know what your value targets are, you won't have a hope of defining relevant, business focused metrics that actually influence decisions.
Of course Roger is right about demonstrating value. But there are some important reasons why enterprise architects have persistently failed to do this in the past, and I don't completely agree with Roger's view on what EA value looks like.
ReplyDeleteI agree that the EA role must be distinct from the roles of any specific project. I also agree that EA must somehow demonstrate value.
ReplyDeleteIt appears to me that many EAs have become focussed on managing the corporate assets (the Configuration Management Data Base or CMDB for example) and capturing usage statistics and other valuable metrics. So EA as corporate librarian. To some extent, I think EAs have grabbed this role because it needs to be done, does provide some value, and is doable without ruffling too many feathers. Following on from there, I see EAs as the keeper of corporate standards. Yet another role that is valuable, yet another role that nobody else wants. So EA as the kind of bottom feeder scooping up stuff that needs to be done, that nobody else will do.. However, I don't think that is what EA is about at all.
To me EA is and has almost always been a strategy role. Aligned with the business strategists, doesn't belong in IT at all but perhaps in corporate marketing, business development or wherever senior strategists make their homes. Of course earning the right to be there is a different problem.
So, if EA is housed in IT, if EA has much to do with project or program management, then EA is overhead. If EA acts as the corporate conscience or scold, ensuring that the systems (not technology) spend of the organization, that what is done is moving the organization towards its stated goals, then it is doing the right thing.
What are the weapons that an EA has at his/her disposal? The weapons of patterns, the weapons of the various lenses through which the business is viewed.
What is the direct and measurable value? The value of ensuring that the right things are undertaken, that the proposed systems move the enterprise forward. That the ever diminishing headroom for innovation be utilized effectively and perhaps even reversing that diminution.
Hi Richard,
ReplyDeleteI saw your blog link on twitter. I would agree that the EA value proposition is different from that of business analysts on projects. Also agree with some of the comments made by Chris.
From my experience EA brings value by maintaining a holistic view of the architecture and through standards and processes retaining some control over that architecture. Without this role projects may drive the architecture out of control.
In my mind that makes it a strategy and operatonal role who's main customer is the CIO, but indirectly the rest of the C-Suite.
Hi Richard, I agree that projects are necessarily focused on their own specific outcomes. Even if we could magically improve project success to 100%, there would still be something missing in the bigger picture - an organizing principle.
ReplyDeleteThis is what I see as the main value of Enterprise Architecture. I've expanded on my thoughts on my blog.
Richard asked a couple of important questions:
ReplyDeleteWhat is EA all about, what is the (emerging, changing) identity of EA?
What is the value proposition for EA?
In response to the second question, Richard discussed two common perspectives: EA-as-IT planning; EA-as-business-strategy.
These may be widely held views of the role of EA but I genuinely think that the Enterprise Architecture function is neither about IT planning, nor about business strategy. Both are red herrings.
In my worldview, EA is all about organizational integrity – making sure that the enterprise is internally and externally congruent and coherent.
We need more joined-up management in a joined-up world and EA can facilitate effective systems integration.
Maybe EA = Enterprise Aliens?
My comments concerning root cause analysis of the lack of perceived value for EA programs is here.
ReplyDelete