Personal tools
You are here: Home Library EIMI Archives Volume 2, Issue 5 - August 2008 Edition Why Isn’t Enterprise Architecture In The Big Time?
Document Actions

Why Isn’t Enterprise Architecture In The Big Time?

By Ian Rowlands

Consider the supposed purpose of Enterprise Architecture (EA): “The Enterprise Architect connects the IT Organization to business goals” (Van Meter 2008).  Then consider the IT budget – anticipated by one respected research organization to hit something close to $1.5 trillion by 2010 (Morgan, 2007).  Put those two facts together. Shouldn’t Enterprise Architecture be the driving force of the IT function?  

Well, perhaps it is – but my experience says otherwise, and I can offer a couple of data points.  First, I’d like to offer commentary from a couple of distinguished witnesses:  Ivar Jacobson observes that “Most EA Initiatives failed."  "My guess would be that 90% never really resulted in anything useful.” (Jacobson, 2007)  Allen Brown, President and CEO of the Open Group[1], suggests the “profession” of Enterprise Architecture is in its infancy, “It’s a new area and a new profession,” he says. “We’re looking at how we can actually address enterprise architects as we would a profession like legal, accounting or building architects. We’re taking baby steps at the moment”. (Brodkin, 2008)

Let’s confess, then, what we really know in our heart of hearts … Enterprise Architecture is a discipline that hasn’t really made it to the big time.  If that’s the case, what are the causes? Is EA a rocket that hasn’t got off the launch pad, or a firework that has fizzled? I’m inclined to think it’s the former. Some more simple data points:

  • An informal survey of salaries for Enterprise Architects seems to suggest that the position commands better than $100,000 in many organizations, with senior roles paying over $140,000.
  • Although there are many products available to support EA, few of the vendors have much in the way of revenue, but consolidation is starting, with the market leader (Telelogic) recently having been snapped up by IBM – consolidation is almost always an indication that a technology is about to become mainstream.

So, EA is just about to come off the launch pad, but hasn’t made it yet.  What are the delaying factors?  The problem seems to be that once past the one-minute elevator pitch, enterprise architects have trouble saying what they do, and how it benefits the enterprise.

The fundamental question is “how will EA make a sustainable and demonstrable contribution to enterprise profitability (or to whatever metric is fundamental to the operation)?”  Answers will depend on your perspective on the EA role.  One of the broadest perspectives is that of John Zachman who argues for the management of a set of architectures that, when complete, would describe every aspect of the enterprise.  A much narrower view argues that the essence of EA is the modeling of technology choices to support business strategy, which is essentially none of the architect’s business. It really doesn’t depend on where you are on the spectrum, it is how do you answer the basic question – “How do we know that an investment in EA will add more to revenue and reduce costs more than any competing investment?”

An issue related to ROI is that of deliverables. What are the products of Enterprise Architecture, and who cares? It can be a sobering exercise to map deliverables against potential audience and try to figure out if the intended recipient could do without a cherished artifact!  In a way this is a drill-down from the gross ROI question.  It amounts to asking for models, plans, designs and architectures: “How does this add to the success of the person I’m providing it for?” One telling point as this issue is considered, is that there is no clear agreement as to what the “right” set of deliverables is (Goethals) it should of course, be observed that EA may not be an end in itself, but a provider of inputs for processes such as Portfolio Management and Governance – which would legitimize different views of appropriate deliverables.

Given there is not a consensus about the deliverables it is not surprising that there is not a “standard” standard. In fact, there are many “standards”, although the one that perhaps should be core to all formal EA programs might be IEEE 1471 / ISO/IEC 42010:2007, which “addresses the activities of the creation, analysis and sustainment of architectures of software-intensive systems, and the recording of such architectures in terms of architectural descriptions.”

As I started to think about the issues of ROI, deliverables, and standards, I was reminded of a question that has been niggling away at me ever since I became involved in EA programs: “How can we verify that enterprise architecture is good?”  The more I reflect on that question, the more I conclude that it’s a matter of advertising! What claims are you prepared to make about your EA program, and how will you be accountable? The problem, of course, is that there are too many variables, and it is impossible to establish the dependencies (or absence of dependency) between them.  Will you claim, “Our Enterprise Architecture will improve enterprise profitability by 11%?"  How about: “This Enterprise Architecture will provide a framework for hardware and software initiatives for the next five years?" These are easy assertions to make – but difficult to validate.

So what’s an Enterprise Architecture Professional to do to earn respect? We all have the sense that EA is really important (in fact I think it should be a natural stepping stone – perhaps the last stepping stone – before the CIO function). How do we get the enterprise to share this high opinion of the profession?

Let’s change gears for a while. Without trying to be exhaustive, let’s look at some of the trends which are reshaping the IT landscape. Three categories that come to mind are external, social, and technological.

Some external forces to consider are macro-economic change, the related issue of globalization, and the associated issues of governance and regulation.  How can the EA function be positioned as steering the enterprise through the implied changes to staffing, applications, and constraints that are implied by shifting supply and demand patterns, changing staffing approaches and trans-border constraints on policy?

Three significant social factors influencing the IT function are the changing demographics of the workforce – in particular the “graying” of IT, the shift in control of the IT investment from the IT function to business management, and the increasing enterprise dependence on knowledge workers.  How can the EA function ensure that the organization deals with the issues of a work force that is:

  • Losing knowledge at the top end as senior staff retire, while becoming more dependent on knowledge to succeed.
  • Increasingly demanding in terms of “attractiveness” of IT capabilities (this is a large question, but monolithic mainframe applications carried an element of “take it or leave it” which is increasingly being superseded by role-specific distributed functionality).
  • Decreasingly “altruistic” in providing funding for information technology.

Some intertwined technological factors to consider are the adoption of service-oriented architectures, the emergence and sophistication of virtualization and the shift to a holistic approach to managing the information technology / business relationship.  Possibly these trends have delayed the development of the EA “profession” as they invalidate architectures that had previously seemed well founded[2].  How can EA provide a framework that adapts to technology changes in a sufficiently agile fashion to support the claim that EA delivers sustainable value?

It will be no surprise to those who have read some of my previous articles to know that I believe that among the keys to unlock the EA puzzle are a narrative-based approach to understanding the relationship between IT and the enterprise (business), and an enterprise metadata repository.

A root cause of the failure of EA to “cross the chasm” into general acceptance is that it is still largely perceived as a discipline that benefits the CIO. When it truly becomes the facilitator of the dialog between the CIO and the CEO and the rest of the executive team then it will draw upon a much wider support base – and become mainstream. Of course that may drive down salaries for all but a select few.

The metadata question is an interesting one. There seems to be a general acceptance that sustainable EA requires a metadata repository – but not much agreement about how deep and broad it should be. I take the view that it should encompass the business and process models typically held in an enterprise repository, the infrastructure and operations information located in a configuration management database, and the design models in an application repository. That argues for EA as an application pulling metadata from a federated metadata universe such as that marshaled by ASG’s MetaCMDB technology.

To conclude: There’s nothing wrong, fundamentally, with the nature of enterprise architecture. The rocket is still on the launching pad. There is some retooling to be done, but the engine is basically sound. Strap in, and get ready for blast-off!

 

About the Author

Ian Rowlands is a Senior Director of Product Management at ASG Software Solutions. He is responsible for the definition of ASG’s enterprise metadata repositories, ASG-Rochade ™ and ASG-Manager ™ Products, for the creation and implementation of product launch and delivery plans and for creation and management of partner relationships. Originally from the U.K., Rowlands is a standing member of the British Computer Society and a Chartered I.T. Professional.


Works Cited

Brodkin, Jon. 2008. www.networkworld.com. Network World. [Online] may 21, 2008. [Cited: July 28, 2008.] http://www.networkworld.com/newsletters/edu/2008/051908ed1.html.

Goethals, Frank. An Overview of Enterprise Architecture Framework Deliverables. www.econ.kulueven.be. [Online] [Cited: July 27, 2008.] http://www.econ.kuleuven.be/leerstoel/sap/downloads/Goethals%20Overview%20existing%20frameworks.pdf.

Jacobson, Ivar. 2007. www.builderau.com.au. builder au. [Online] November 2, 2007. [Cited: July 29, 2008.] http://www.builderau.com.au/blogs/syslog/print.htm?TYPE=story&AT=339270872-2000064750t-339270768c.

Morgan, Timothy Prickett. 2007. IDC Says Global Spending Will Kiss $1.5 trillion by 2010. www.itjungle.com. [Online] January 15, 2007. [Cited: July 20, 2008.] http://www.itjungle.com/tfh/tfh011507-story06.html.

Van Meter, Emily and Brown, Eric G. 2008. Role Profile: The Enterprise Architect. Cambridge, MA : Forrester Research, inc., 2008. Analyst Report.

Wu, John. 2005. Coherent Enterprise Architecture. www.liteea.com. [Online] September 27, 2005. [Cited: July 30, 2008.] http://www.liteea.com/lea.php?itemid=501&catid=91.


[1] The Open Group, a vendor-neutral and technology-neutral consortium has promoted TOGAF (The Open Group Architectural Framework), arguably one of the most influential platforms for EA implementations

[2] For some interesting thoughts, see John Wu’s work on “Light Enterprise Architecture”(Wu, 2005)

Navigation
 
 

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: