Something else I took away from Sally Bean’s and Peter Haine’s workshop Reflecting on EA at EAC 2009 was the relationship between two sets of questions. 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.