The Value of Enterprise Architecture

There has lately been a lot of discussion about Enterprise Architecture (hereafter EA) in my neighbourhood of the blogosphere. Perhaps this is a sign of adolescence for EA. Its existence is apparent, and now EA needs to decide who it should hang out with and what it wants to be when it grows up. As part of a wider discussion, Richard Veryard has posted some excellent thoughts on the importance of a value proposition for EA. I totally agree with Richard’s view that EA is not just about making projects successful and since this is my blog, I’ll put my view on what I think is the value of EA. EA provides two perspectives which are vital in any long-lived and complex system such as an enterprise.

Continuity: EA provides continuity across organizational boundaries, geographies and – most importantly – the span of time. This is something that any individual project – successful or not – could not do. During the lifetime of an enterprise there are multitudes of projects executed in different places, by different people – outsourced and insourced. Ultimately all these projects must pull in approximately the same direction to support the business strategy.

To take a hypothetical example: “The data warehouse project in Bangalore being built by Tatosys must support the new marketing system being built in Sydney by Bluehair Consulting. And both are critical components for the mobile commerce platform slated for 2012 go-live by either PDQ Global Services or IBS (an HQ company) depending on who bids the lowest fixed price. And by-the-way the core transaction systems run on a mainframe that we are phasing out in the next three years as part of our 2002 strategic plan.”

Each of these projects is a major undertaking in its own right. Even if every project is 100% successful, you cannot be certain they will all fit together in a coherent and efficient manner. Making them fit is more than just a business problem. It goes beyond getting the functionality right and encompasses deeper technical layers of standards, frameworks and systems partitioning which are neither the domain of the business nor of business analysts.

Self Correction: The second value proposition of EA that I see is the role of “external observer and governor”. Enterprises exist in a constant flux of technologies, fashions, methodologies and business requirements. Someone needs to have the ability to evaluate new practices and make the decision to incorporate those that are valuable and relevant. This is not something that individual projects can do, although they may have a role in trialing new practices.

Each of these areas of change exist in the domain of different parts of the organization. The business is hopefully across changes in business requirements, the Project Management Office is (perhaps) across changes in software development methodologies, and the IT department always want to try out the cool new tools. But normally these parts of the organization don’t interact outside the constraints of an individual project. You need some constituency that is across all these areas and helping to guide the amalgamation of new “best practices” into the enterprise. I think that EA is the natural venue for this interaction.

So is this just the “old fashioned” value proposition of “EA-as-IT-planning”, instead of the cool new view of “EA-as-business-strategy”? I see it as something midway between the two. Certainly “EA-as-IT-strategy” is close, but also “EA-as-trusted-advisor-to-business-strategy”. Leave the business strategy to the business, but when it comes to the mechanics of implementing business strategy in terms of systems, processes and technologies, the strategy-makers should be able to rely on EA to guide them as to what works, what doesn’t – and who might take them for a ride.

Richard mentions that he’s “not convinced that the EA value proposition is understood by its customers”. I would go so far as to say I don’t think the EA value proposition is even trusted by its customers. EA needs to engage with its customers, figure out the value proposition and then execute.


#1 Richard Veryard on 06.16.09 at 11:29 pm

Of course. How can the value proposition for enterprise architecture ever be understood (let alone trusted) by its customers when it doesn’t seem to be very clearly or consistently understood even by its practitioners?

I think a value proposition along the lines you suggest could be very powerful. Chris Bird suggested something similar to yours in a comment to my blog.

My suggestion is that we should try to use Osterwalder’s template to lay out a value proposition for EA in a systematic fashion. I am working on one, and I invite you to have a go as well.

#2 Peter Evans-Greenwood on 06.17.09 at 11:55 am

Richard makes an excellent point. We need to consider why EA’s value proposition is poorly understood by most practitioners before we tackle bigger questions. There’s too much blind following of method, and not enough thought into EA’s role in the business. Witness the common tendency too staff EA teams by hiring someone into each role defined by TOGAF.

Any value proposition must also be defined in terms the customer cares about. Defining ourselves in term of “transformation”, “projects”, “IT assets” or “governance” is a path to irrelevance. Enterprise technology and its role in business has changed dramatically since EA started–with applications becoming commoditized and the emergence of alternatives like SaaS–and we need to change with it.

EA is becoming an advisory function. EAs should work with and across the business to help the business leverage technology to drive performance. Something this might mean procuring a technology asset, but increasingly it means engaging an external partner (BPO) or service (SaaS). Our value prop needs to be defined in how we help drive business value, not how we spend CAPEX.

More thoughts in a preso I gave to RMIT’s masters in EA class.



#3 Enterprise Architecture is not the same for everyone - The Next Big Thing - on 07.10.09 at 5:42 am

[…] create a value proposition that holds up. One important question that must be answered is: Is the Enterprise Architecture closer to the CEO or the CIO based on the kind of CIO a company […]

#4 Paul Boos on 08.03.09 at 11:21 pm

Based on the article, perhaps every Agile team should have an EA ‘pig’ (if we want to focus on a Scrum approach) attached to a development project. It would be their goal to assist developers in understanding what components they could integrate, helping the Product Owner understand the business benefit, help the team to ID and lower risks, and also to feed back into the EA those components that will change or be added as they evolve because of business-driven needs. It will help the organization realize the impacts ahead of deployment without being dictatorial about it.

Finding some continual evolutionary process seems a way to integrate the Agile (short) and EA’s (longer) cycles. I have been giving quite a bit of thought to how EA can assist an organization be more Agile without getting in the way of development and without having to attach itself to a specific technological approach (i.e. web services) since EA is about understanding business processes and data as well. I don’t have any answers yet as I have just started researching this myself, but I am a strong proponent that the various architectural perspectives/views and associated ‘governance’ (if self-managed teams even need such a thing) should be there to help, not hinder. EA is more about providing information to help in, not as a constraint to, decision-making.


#5 Saul on 08.04.09 at 8:34 pm

Hi Paul, thanks for your thoughts on this and I agree that there is a lot of value that can come from EA being more involved and in-touch with the development teams.

The EA team is a stakeholder or customer of a project just as much as the “business” is. Hence in an Agile approach if it makes sense for the business to be embedded in the project, then the same applies to the EA team.

I share your concern that governance is often viewed as a constraint rather than an enabler.

Ultimately governance is a vehicle to enable continuity. How governance happens is cultural, and like many such thing, the culture can be good and supportive or bad and restrictive.


#6 EA and Agile Projects | soabloke on 08.14.09 at 8:20 am

[…] recent comment on my post about the value of enterprise architecture suggested that enterprise architects should […]

Leave a Comment