Ever get the feeling that software development has degenerated into a cat and mouse game? The business defines a requirement, provides a budget that covers about two thirds the cost, specifies an 8-week deadline, and then changes requirements in midstream because their needs changed as did the competitive environment. The result is a game of dodge ball where the winner is somehow able to duck the finger pointing.
The practice of Enterprise Architecture (EA) was invented to make IT proactive rather than reactive. So, come and give us an impossible deadline, and we’ll implement a consistent process that, after analysis, determines the possible, and then enforces a process to ensure that the possible happens. In that sense EA is much like Business Process Management (BPM) for IT’s software or solution delivery business in that you try to imbed your best practices when implementing systems projects.
At the end of the day, the goal of EA is to make all the processes related to implementing and supporting IT systems consistent. Yes, it can be about determining the standards for physical architecture, such as preferred database, OS, application choices, and SOA policy and all that. But more broadly, it’s a form of Business Process Management (BPM) applied to IT’s system activities. EAs have many different frameworks to choose from for codifying how IT responds to the business in making the decisions governing specification, implementation, and maintenance of systems; among the best known EA frameworks are the Zachman Framework, the granddaddy which takes a matrix approach to identifying all the facets of implementing IT systems, and TOGAF, the Open Group-sponsored framework which takes more of an iterative process-centered approach.
Enterprise Architecture has a strong band of adherents, primarily in large enterprises or public bodies that also have strong process focuses. The actual power and influunce of the enterprise architect himself or herself obviously varies from one organization to the next. The Open Group’s EA conference this week still had a pretty strong turnout in spite of the fact that layoffs and budget cuts are dominating the headlines.
But Enterprise Architecture has a branding problem: Try and pitch Architecture, promote the benefit that it is supposed to be transformational, and if you work in a more typical enterprise, you’re likely to get one of two responses as you are thrown out of the office:
1. Transformation sounds too much like Reengineering, which translates to all pain and little gain.
2. What the heck is enterprise architecture? I need software!
Cut back to the chase: how can IT successfully pitch enterprise architecture? Should it pitch EA? And how is the idea actually thinkable during a recession when IT budgets are getting slashed and people are getting laid off?
We were reminded of the issue of keeping EA relevant as we sat on a panel at the Open Group’s Enterprise Architect Practitioner’s Conference in San Diego this week hosted by Dana Gardner, along with Forrester Research principal EA analyst Henry Peyret; Chris Forde, VP Technology Integrator for American Express and Chair of the Open Group’s Architecture Forum; Janine Kemmeren, Enterprise Architect for Getronics Consulting and Chair of the Architecture Forum Strategy Work Group; and Jane Varnus, Architecture Consultant for Enterprise Architecture Department, of Bank of Montreal.
Gardner polled the audience on what kind of ROI was realistic for EA initiatives; an overwhelming majority of attendees stated that a 2-year payback was reasonable. The problem is that today, money is just not that patient. As one consultant joked to us after the session, anyone proposing a 2-year payback should enter the CxO’s office with another job offer in their back pocket. Consider this: if you proposed a project in July 2008 for a natural resources company based on oil prices exceeding $140/barrel, your plans would have been fine until the collapse of Lehman Brothers 2 months later.
EA could borrow some lessons from the agile software development community which has proven that in some cases (not all), lighter weight processes may be adequate and preferable. With agile development predicated on the assumption that requirements are a moving target, it takes a looser approach to requirements called “stories” that can change at the end of each spring or iteration, which could be anything from 2 – 6 weeks. Conceived for web development, agile is not the be-all or end all, and likely would not be a wise choice for implementing SAP. If you keep in mind that the goal of EA is not process for its own sake, but instead is aimed at ingraining consistent policy and methodology for decision making, the notion of “lite” EA is not all that outlandish. Your organization just has to decide what the pain points are and address relevant processes accordingly.
TOGAF 9 is an encouraging step in this direction in that it has made the framework more modular and the pieces of it more self-explanatory. No more do you have to borrow from different parts of the framework all the concepts and processes that you need in place to conduct a planned systems migration, and it makes it easier to implement piecemeal. We agree with Forrester’s Peyret that EA needs to accounts for the fact that the world is more virtual, scattered, and networked, and that EA frameworks need to account for this reality. But at the same time, EA needs to provide a lighter weight answer for smaller organizations that desire the consistency, but lack the time, resources, or depth to undertake classic EA.
And while we’re at it, lose the name. The term enterprise architecture is awfully vague – it could mean process architecture, physical architecture, not to mention the reengineering and capital “T” transformation connotations. When pitching EA, and especially EA lite outside the choir, how about using terms that connote steady, consistent decision making and predictable results? If you’ve got a better idea on how to brand EA, please let us and the world know.