EA vs. The ‘ea’ Approach: The Advantage of Focusing on Individual Initiatives

When enterprise architecture (EA) works well, it is a tremendous asset to the business units that employ it. EA provides the ability to manage complexity across a number of domains, decrease costs, reduce redundancy, increase revenue, improve processes, and expand business opportunities.1

Unfortunately, not all EA efforts work well. Early adopters, looking for a method to streamline business operations, optimize processes, and align IT and business, found a few years later that implementation was inconsistent, expensive, and time consuming, and the overall size of the effort was difficult to manage. Departmental focus on short-term financial results hinders implementation and reduces the long-term effectiveness of the endeavor. As a result, those footing the bill vowed “Never again.” The sad fact is many efforts in EA have fallen into this category.

But the promised benefits of EA are too much to ignore. One reason for EA’s persistence is the belief that if someone could get it right, the return on investment would be worth all of the tears shed by the practitioners that went before them. There is an allure to the value of applying good, practical logic to business complexity that keeps EA afloat and keeps business interested in another try.

Enterprise Architecture Hurdles

Most new disciplines go through a number of growing pains. EA is no different.

Currently, EA practitioners and implementers vary on how they define what EA is, what it can provide, and how it can be accomplished. These growing pains manifest themselves in a number of issues that must be overcome before smooth implementation can be achieved. Clearly defining what EA is, removing EA from the shadow of its better-known IT architecture predecessor, and overcoming early failures will help business leaders understand what to expect, and it will help practitioners understand what to provide.

The first issue is definition. By now, most people feel they have a pretty good idea of what EA is all about. Unfortunately, these ideas tend to vary widely. There are almost as many definitions for EA as there are practitioners. A few example definitions include:

• Carnegie Mellon: “A means for describing business structures and processes that describe business structures.”
• Information Society Technologies: “The model of organization and operation for a public administration, as described in a set of interrelated views. It consists of the generic model and its various instances that may vary, e.g., amongst the particular public administrations in which the enterprise architecture is employed.”
• Office of Management and Budget: “The explicit description and documentation of the current and desired relationships among business and management processes and information technology.”

All three of these definitions have one thing in common—they all imply building models. From the sound of these definitions, the purpose of EA is to build nice models for the sake of building models. In the minds of most business leaders, these models might be to have, but it is hard to see any immediate business value in them. There might be long-term value, but most likely this will not be recognized until after the current decision makers have moved to new positions. In the end, these EA definitions leave business leaders not only confused about what to expect from EA, but with the impression that EA was a theoretical exercise that lacked measurable results.

Information technology leaders, on the other hand, are more predisposed to EA. Fifty years of software and hardware development have shown IT professionals that architected solutions are easier to install, easier to fix, and easier to change. Acceptance by IT professionals has been a mixed bag for EA. While it gives EA practitioners employment, and the opportunity to perfect and use data models, it creates an artificial marriage between EA and IT. As a result, EA is often pigeonholed within IT. Misconceptions such as “EA is the same as SOA1,” or “EA cannot help me with my business problems” have arisen. IT is a participant in EA, not the other way around.

Another hurdle facing EA is that early failures seem to have echoed around the world. Many decision makers have been burned by failed EA projects, or know someone who has. We have all heard about the EA projects that consumed large sums of money, took years to complete, and delivered wall-sized pictures of the world. These projects produced great views of complex “as-is” environments by modelers in ivory towers and left clients feeling they received no real value from the invested time and effort. To these decision makers, EA is perceived as an esoteric practice that eats money, time, and labor but has no benefit in the “real world.” Wall-sized “as-is” diagrams created for their own sake hold little value to most decision makers.

It is an unfortunate truth that the majority of decision makers who are familiar with EA believe it to be a bad word. As soon as the words “enterprise” and “architecture” are mentioned, decision makers’ eyes glaze over, and they start thinking about useless drawings, glacial time scales, and, worst of all, spending large sums of money. Most EA engagements must overcome these hurdles at the outset. Communicating to decision makers that EA will provide benefits outside of IT and explaining that EA provides value other than drawing pretty pictures can be a daunting task. And it is a task that must be done before the first model is drawn. Changing this cultural opinion is important, but time and effort that could be spent fixing problems are wasted playing politics and attempting to change minds.

Don’t despair; EA is not lost. The potential of EA is too valuable to be abandoned as unattainable. Simply sidestepping the baggage associated with the words “enterprise architecture” can be done. Here’s how.

Defining Enterprise Architecture

The first thing EA needs is a way to describe itself without using a tainted vocabulary. It also needs a better method of communicating business value. IT largely understands the value of a well modeled and articulated operating environment. But IT has difficulty in relating this environment to business organizations, processes, and/or objectives. On the other hand, business units have difficulty in articulating, with any real rigor, anything beyond a simple process chart, an organization chart, or a list of, often poorly written, goals. EA can help with these difficulties—if it can be properly defined at the outset. The authors at Wikipedia have provided a good starting place for this idea:

Enterprise architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization’s processes, information systems, personnel, and organizational sub-units, so that they align with the organization’s core goals and strategic direction. Although often associated strictly with information technology, it relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, organizational structure, and process architecture as well.

This definition is certainly a step in the right direction. It captures the multidimensional aspect of EA and goes a long way to moving EA out of the “IT Only” realm. But it still appears to focus on the creation of diagrams. Very little in this definition appears actionable, plus it’s wordy. The sad truth is, in the information rich world in which we live, if it does not fit on a PowerPoint slide, it may not be usable.

Let’s consider a simpler yet effective definition: enterprise architecture is a method of streamlining and integrating IT and business strategies. This definition spans IT and business domains and gives decision makers the feeling that an optimized operating environment is the result. Notice the focus in this definition is moved from what EA is to what EA does, and is succinct enough to be used in conversation or a presentation.

Establishing the Enterprise

The typical model for engaging in EA has been a large, all-or-nothing approach. These efforts seek to encompass an entire enterprise or business unit—which usually means large staffs, large budgets, long time frames, and big goals. There is a belief that in a few years the business segment in question will be modeled and understood so it can be managed more effectively, and the large investment needed to get to that point will have been worth the cost. But if EA programs fail to reach a significant level of maturity after initial funding runs out, business leaders will say they made an effort and blame EA for not being able to deliver on its promises.

These large, all-out, engagements encapsulate Enterprise Architecture with a capital “E”. That is to say, these are the granddaddies of EA engagements. They benefit from the support, both financial and mandated, of higher management and are afforded time to architect on very large scales. The majority of decision makers believe this is the only way EA can be effective. And, in truth, a successful engagement at this level should be the eventual goal of every EA practitioner and decision maker who understands EA. But few companies feel they have the available capital for such a large effort. As a result, business leaders are slow to adopt EA because of the resources they feel are needed to achieve the capital “EA”.

What Is ‘Enterprise Architecture’?

The word “Enterprise” seems to get in our way, again. A quick glance at the definition reveals why:

enterprise: 1. endeavor, endeavour a purposeful or industrious undertaking (especially one that requires effort or boldness); “he had doubts about the whole enterprise.” 2. an organization created for business ventures; “a growing enterprise must have a bold leader.” 2

Enterprise: A group of departments, divisions, or companies which make up an entire business.3

It seems when the word “Enterprise” is used, the concept of big comes with it. These definitions, which use words like “undertaking,” “bold,” “whole,” and “entire,” give the feeling that when “Enterprise” is involved something large and complex is taking place. No wonder then that most of the previous EA engagements have been on grand scales. After all, that is what the name “Enterprise Architecture” presumes.

In practice, the enterprise is what you define it to be. The word not withstanding, enterprises can be as small as you wish. An individual initiative can be an enterprise; software upgrades can be an enterprise; every thing that is involved with a company’s waste management process can be an enterprise; the list goes on. This might sound like common sense, but the truth of the matter is there is resistance to believing that an enterprise can be small. Size, as far as EA is concerned, does not matter; benefits can be felt regardless of the size of the engagement. The key is to define the scope of the area in which you will operate, and then stay inside of that circle, own that circle, architect inside of that circle. That is the concept of the little “ea.”

The Lowercase ‘ea’ Approach

Many business leaders and even some EA practitioners fall into the trap of believing that there are “EA initiatives.” With the possible exception of large “as-is” undertakings, the “EA initiative” concept is patently untrue. There are no EA initiatives; there are only initiatives. EA assists in creating well-formed, complete end products. Initiatives create those products, and EA facilitates. Put another way: EA is a verb, not a noun. It is not something to own; it is something to be done. EA is a set of techniques and methods used at all levels of engagement to create a common vision and language inside the enterprise of interest. Because EA is something you DO, not something you put on a shelf, it has the ability to help no matter what the size of the initiative.

An alternative to the capital “EA” approach can be thought of as a lowercase “ea” approach. Instead of focusing efforts on large business segments, attention is placed on individual initiatives. Apply sound EA principles inside the domain of an initiative. While your footprint will be smaller, and the benefit of EA will be realized only inside the initiative, value can still be obtained—just on a smaller scale. And scale is the only significant difference between the capital and lowercase EA approaches. But, as it turns out, this is a big difference.

The “ea” approach can be broken down into six activities:

1. Gather documentation and requirements. Pull out and organize discrete elements and create logically associated lists. Level of detail is not an issue here; the key is to capture as much information as possible. Together these lists will serve as the scope of the enterprise.
2. Capture “as-is” environment. Without understanding the current landscape of the enterprise, it will be nearly impossible to see what needs to be changed, or how that change will affect elements across different dimensions. It is important to note that every element listed in the activity above is accounted for here.
3. Identify area(s) for improvement. Analyze the “as-is” environment and identify the area(s) where change would be beneficial.
4. Create a vision of the desired state. This document states where the enterprise should be and what general changes are needed to get there. It provides a large target for the “to-be” environment to aim for as the preferred state is designed.
5. Design “to-be” environment. Architect and document the desired state of the enterprise once the initiative has been completed. This activity includes models of the new environment, future state requirement documents, and maps of dependencies outside of the enterprise. Capturing these dependencies is one of the most valuable benefits of architecting the “ea.”
6. Create a road map. Documenting the differences between the “as-is” and the “to-be” provides detailed requirements to get to the desired state. These requirements, coupled with business priorities, are used to create the road map for establishing the new, desired environment. This road map should be detailed enough to enable initiative implementers to translate requirements into actions.

Little “ea” engagements focus on the front end of initiatives. Architecture provides the basis for sound scoping, planning, and design of these initiatives, providing implementers with a clear understanding of what they are tasked to complete and a clear grasp of what the problem space includes. The little “ea” makes it easier for implementers to move from conception to completion. But “ea” is not a complete effort by itself. No consumer, for example, has ever bought a cabinet because it had a complete parts list and a well-designed set of plans. Consumers buy cabinets because of sound construction. Having a complete parts list and proper design leads to faster, cheaper, and better construction, and an overall better cabinet.

At the end of the day, following these six activities will help with the design and functionality of business initiatives, no matter what the size of the enterprise.

Benefits of “ea”

There are a number of short-term benefits to using the initiative-based “ea” model. At a macro level, architecting initiatives provides implementers the advantage of understanding the full scope of the problem area and what it will take to complete. For business managers, “ea” provides a clear road map for initiative implementation and the ability to manage resources accordingly. For decision makers, “ea” provides a logical, well-planned initiative without incurring the time or cost of a full-blown “EA” effort.

At a micro level, initiative scoping is improved by identifying discrete elements regardless of the domain believed to be in question. For example, initiatives thought to be exclusively IT related can be seen affecting processes and organizations. These other domains, originally, may not have been considered in scope. With this fully articulated scope, requirements gathering is easier and more complete.

Another short-term benefit of a clear scope is the ability to fully identify dependencies. A dependency is anything on which a component of the completed initiative will rely. A major drawback to architecting “ea” is the smaller the defined “enterprise” the larger the number of dependencies. Or, put another way, dependencies are inversely proportional to the size of the enterprise. Elements inside of the enterprise can be integrated, but elements outside the enterprise must be interfaced, and any change on either side of the interface could affect all three (component, interface, and component). Architecting “ea” will provide a clear map of these dependencies. Decision makers are then afforded the opportunity to expand the scope of the initiative, or accept the limitations of size. This will go a long way to minimizing unintended consequences during project development and deployment. Mapping dependencies helps minimize the inevitable problems initiatives face once deployed.

Long-term advantages for “ea” exist as well since “ea” provides many of the same advantages of “EA,” and like its big brother, the benefits increase over time. The more initiatives that take the “ea” approach the more principles, such as “requirements-driven,” “architecture-centric,” “model-driven,” and “iterative” become ingrained in how problems are solved.4 Time and work can be saved as initiative space overlaps and previous work can be reused in future or concurrent initiatives.

Foundation for ‘EA’

All encompassing, fully articulated, mature enterprise architecture should be the eventual goal of any enterprise or business unit that wants to become and remain agile in a rapidly changing environment. And “ea” provides a number of steps creating a solid base that can be incrementally expanded to reach a mature architecture.

First, “ea” sidesteps the confusion over what “EA” means. The words “enterprise” and “architecture” are never mentioned. Since “ea” is a method, not a “thing,” decision makers do not need to be weighed down in the details of how “ea” is done. Discussions about “artifacts” can be skipped. Oftentimes words like “artifact” can evoke in decision makers memories of useless old things that sit in cold, quiet museums. Remember, the details of “how” architects do their job is not as important as communicating the value of what is provided. Results count, not necessarily how the results were attained. In this way, decision makers can be exposed to EA without signing off on a big, monolithic undertaking.

Second, “ea” will provide practice in defining what models, frameworks, artifacts, and methods work best in a particular business segment. Each initiative provides an opportunity to refine best practices and develop samples and templates. Initiatives also provide a place for practitioners to hone architectural skills and communication methods. All of these mature into a well-formed set of standard practices that can be formalized to provide the foundation on which the big “EA” sits. With homegrown, experienced practitioners who have an understanding of the business unit, an “EA” environment is easier to build and sell to leadership.

With this foundation already in place, and leadership exposed to EA principles (without necessarily calling them “enterprise architecture” principles), the first hurdles of EA acceptance will have been passed. EA can be positioned as an expansion of best practices and formalization of current practices already in use.

The benefits of EA cannot be ignored, and a working, functional “EA” is a value to any business unit that reaches that point. But initial first steps can be daunting and difficult. The little “ea” provides a road map for taking that first step. And even if the nirvana of “EA” is never reached, the benefits provided by “ea” at the initiative level will have been worth the effort. But with a little luck and a lot of practice, the little “ea” has the potential to grow to the capital “EA” providing benefits along the maturity process.

Bibliography

1. ABE: A Better Path to Enterprise Architecture by Roger Sessions, March 26, 2001.
2. WOR: WorldNet Cognitive Science Laboratory, Princeton University Web site, http://wordnet.princeton.edu/perl/webwn?s=enterprise.
3. GEO: Georgetown University Web site, http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html#E.
4. UML: UML, RUP, and the Zachman Framework: Better Together by Vitalie Temnenco, November 15, 2006.

by Brian Kling, a consultant with SAIC. He has worked on architecture programs for the Federal Government, BP, and Texas State Utilities. He can be contacted at klingbj@saic.com.