Error message

User warning: The following module is missing from the file system: mollom. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1156 of /volume1/web/drupal/includes/

The promise and perils of Enterprise Architecture Frameworks

Figure 1

Enterprise architectures shape the design of the businesses in an enterprise so a desired future state can be achieved. An Enterprise Architecture Framework is a type of conceptual framework that organizes the development, implementation, and sustainment of such architectures. There are quite a few frameworks, and each is intended to guide the formation of architecture descriptions by:

  • defining a common vocabulary across structural architectural elements
  • establishing a repository for capturing and managing the content of these descriptions
  • leveraging methods for managing the elements and governance of these elements and their properties, to ensure they are fit for the purposes they are employed to accomplish, while assuring integration across their temporal, spatial, and functional dimensions.
  • prescribing the standards that are to be followed as these elements are implemented

The information in these architecture descriptions is intended to provide a practical starting point for the concurrent production of the detailed architecture definitions. The frameworks typically provide a toolbox of constructs, but may not provide a comprehensive methodology and implementation framework. These constructs tend to fall into three broad categories:

  • An Operational viewpoint which defines why a system of interest is needed, by specifying the relationships between the system and its environment in order to achieve its mission and provide the services it offers.
  • A Functional viewpoint which explains what the system has to do (i.e. its mission), including the rules and constraints for system operation, without specifying how such results are to be achieved.
  • A Structural viewpoint that defines how the system will be realized, by defining its key functions, attributes of the physical parts (hardware, software and humans) necessary for realization, and how these must collectively interact with each other and their environment for the system to operate acceptably

For example, in figure 2, viewpoints are organized to target particular stakeholder groups (in this case, planners, owners, designers, and builders), in a way that unifies their perspectives. Without this harmonization, a great deal of wasted effort will be spent on redundant explorations that may never go anywhere. Unsurprisingly, artifacts which are produced to comply with such frameworks run the gambit from descriptive to prescriptive. When projects are pushed for favorable news to report, may favor buying off immature artifacts rather than making the extra effort to assure that they conform to key architectural patterns. Unfortunately, frameworks may not provide adequate guidance to evaluate the quality of these artifacts or to understand their relative importance in achieving the architecture definition's purpose.

Figure 2

The views comprising these viewpoints are designed to communicate multi-faceted aspects of the system that are meaningful to particular stakeholders. While all of these viewpoints may not be necessary, the information defined in them focuses on the changes required as the system evolves from a 'current' baseline to the capabilities defined for a 'target' representation of the system. For example, the Department of Defense Architecture Framework defines 26 different views to communicate all aspects of a complex system of systems, not every system of interest needs such broad coverage. So while all these viewpoints were used to define the Future Combat System (see retrospective), a more modest subset of these views could adequately define changes for a single system.

Such viewpoints are intended to allow architectural descriptions of even complex systems to be understood in the same way that architecture drawings guide the design, construction, and sustainment of a building, using viewpoints such as floor plans, site plans, and cross sections. Each of these views is iteratively defined to unfold multiple levels of detail in standardized layers:

  • At the highest level, enterprise architectures are fundamentally concerned with identifying information assets that can be reused to orchestrate build-out of the architectural implementation. These assets are expected to enable the implementation of a business's strategy, by helping organizations evaluate whether its resources are properly aligned to the mission, goals, and objectives of the broader organization. From an investment perspective, these strategies are used to drive decisions about the business's portfolio as a whole, so the primary stakeholders for its products are the leaders who have the fiduciary responsibility to assure that the investments in the architecture drive change as effectively and efficiently as possible.
  • At intermediate levels, segment architectures lay out roadmaps for each core mission area or service. At these levels, architectures are structured to improve the delivery of services to users, and to manage change within the scope, dependencies, and resource allocations negotiated with the business owners supported by those architectures. The primary stakeholders for these architectures are the lines of business that operate within the scope of the system of interest and make investments to automate or consolidate business functions.
  • At the lowest enterprise level, solution architectures define the technical assets used by service providers to implement all or part of each system or business solution. Solution architecture have relationships to segment architecture and enterprise architecture through shared definitions and constraints, such as the definitions of data or interfaces necessary for implementing a core mission area or service, and that may be constrained by specific technologies and standards that are maintained at the enterprise level. The users of these architectures are the system users and developers that develop, sustain, and use these services.

Figure 3

A SysML profile known as the Universal Architecture Framework attempts to simplify, structure, and extend the views defined for TOGAF, DODAF, or FEAF, as depicted in Figure 4. Such profiles enable the representation of integrated model layers such as expressing an outcomes model layer, a component model layer, a Human-Systems Interaction Model, and a Life Cycle Processes Model. Figure 3 provides a visual summary of this structure, which Zachman himself acknowledged as an improvement on his original work. Yet the size of the matrix is indicative of the complex information space that must be developed and maintained to be useful to its customers.

Despite the benefits that advocates of such Enterprise Architecture Frameworks claim to provide, their effectiveness in guiding the definition of the architecture itself and its subsequent realization has been inconsistent. Since the customer of the resulting work products are often the architecture organizations themselves, their utility in enabling the achievement of business goals is often difficult to measure, as their interpretation is often subjective rather than objective, so that their contributions can be difficult to pin down. In an investigation of usage of these architecture artifacts, three specific items are identified as responsible for the low success rate of such initiatives:

  1. extraordinary efforts are needed to develop and maintain the EA documentation, so the work is rarely completed
  2. the typical quality of EA documentation is low, which undermines its usability
  3. EA practice is not sufficiently integrated into the organization, but remains isolated within a concentrated group of specialists

As Marc & Laura Sewell describe in The Software Architect‘s Profession:

It is ironic that … in a field where precision would be expected … it has become common for software professionals to bandy about words such as 'architect‘, ‘designer‘,  'architectures‘, 'styles‘, and 'models‘, without using their commonly held meanings. We only mystify what we say when we use commonly understood words to mean wholly different things.

Figure 4

As an example of the difficulties caused by this ambiguity, in their 2004 report to Congress, The Federal Enterprise Architecture and Agencies' Enterprise Architectures Are Still Maturing, the Government Accountability Office stresses its inability to utilize the material in assuring accountability at the agency level:

OMB requires agencies to map and align their architectures with the Federal Enterprise Architecture. However, since these terms are not well-defined, GAO asks if the expected relationship between the FEA and agencies‘ architectures is clear enough.

As a demonstration of the consequences of such ambiguity, in a 2005 internal audit performed by the Department of Justice‘s, "The Status of Enterprise Architecture and Information Technology Investment Management in the Department of Justice", the Inspector General provided what later would be described as an 'almost perfect example of a typical federal EA program':

Efforts to develop a Department Enterprise Architecture have been underway since 1999. However, the Department‘s efforts to develop an Enterprise Architecture have suffered from a lack of institutional commitment and a changing perception of the composition of, and priority for, a Department-level Enterprise Architecture. Adding to this confusion are the additional Enterprise Architectures developed by components.

In 2001, the Department began developing an Enterprise Architecture based on the Federal Enterprise Architecture Framework (FEAF). The Department secured funding and hired System, Data, Infrastructure, and Business Architects and an Investment Management Coordinator. This group assembled 'as-is' business, data, and application architectures by December 2001. However, a Department official told us that other priorities prevented this early Enterprise Architecture effort from continuing. Further, the 'as-is' architectures were not updated and were not useful for later efforts to develop a Department-wide Enterprise Architecture.

In 2002, the Department began using the Federal Enterprise Architecture Management System (FEAMS), a web-based automated tool that provides agencies with access to initiatives aligned to the FEAF and associated reference models to assist in developing an Enterprise Architecture. The FEAMS was designed in close cooperation with the OMB, and the OMB required the Department to use the FEAMS to develop its Enterprise Architecture. According to a Department official, the Department considered the FEAMS to be a cumbersome system that made inputting and extracting data difficult. Further, while the system served as a storage place for models, it could not perform analyses. Consequently, despite the OMB‘s direction, the Department discontinued the FEAMS.

In 2003, the Department piloted the Popkin System Architect software for use as its automated tool. Although the DEA used the Popkin software in developing its Enterprise Architecture, a Department official stated that Popkin would require significant modifications to serve the Department‘s purposes. Based on the results of the pilot, the Department decided not to use Popkin. A Department official stated that commercial off-the-shelf tools are now being explored as aids to the development of the Enterprise Architecture. However, the Department has no timetable for acquiring an automated tool to document the development of the Department‘s Enterprise Architecture. In addition, Department officials were unable to provide expenditure data for Enterprise Architecture efforts prior to FY 2004.

After rejecting the FEAF, along with the FEAMS automated tool, the Department began devising its own framework intended to lead to a Department-wide Enterprise Architecture. The Department expects the framework, called the Capability Delivery Model, to be completed in late FY 2005 and the resulting Enterprise Architecture by late FY 2009.

These gaps result from both deficiencies in the Federal Enterprise Architecture Framework itself, and in each agency's ability to effectively build architecture definitions for their business that was compliant with it. These deficiencies continued even as these higher level improvement efforts continued throughout and beyond these target dates:

  • In 2006, Robertson, Ross, and Weill of the Harvard Business School, in their book, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, highlight the need for improvements in Enterprise Architecture definitions, saying "In presentations we have railed against traditional IT architecture efforts for their remoteness from the reality of the business and their heavy reliance on mind-numbing detail represented in charts that look more like circuit diagrams than business descriptions and that are useful as little more than doorstops."
  • In 2007, computer consultant Ivar Jacobson summarized his assessment of enterprise architecture this way: "Around the world introducing an Enterprise Architecture has been an initiative for most financial institutions (banks, insurance companies, government, etc.) for the last five years or so, and it is not over. I have been working with such companies and helped some of them to avoid making the worst mistakes. Most EA initiatives failed. My guess is that more than 90% never really resulted in anything useful.
  • Later that same year, in a report on enterprise architecture, Gartner predicted that "... by 2012 40% of [2007’s] enterprise architecture programs will be stopped."
  • A 2008 study, by performed by Erasmus University Rotterdam in concert with the firm who started the Business Process Management software industry, IDS Scheer concluded that two-thirds of enterprise architecture projects failed to improve business and IT alignment.
  • In a 2009 article, industry commentator Dion Hinchcliffe wrote that "Recently there’s a growing realization that traditional enterprise architecture as it’s often practiced today might be broken in some important way. What might be wrong and how to fix it are the questions du jour."
  • In 2011, in a report to the U.S. Congress, the Office of Management and Budget reported that "most departments and agencies reported they expect to realize the benefits from their respective enterprise architecture programs [...] sometime in the future. What this suggests is that the real value [...] from developing and using enterprise architectures remains largely unrealized".
  • Also in 2011, federal enterprise architecture consultant Stanley Gaver released a detailed report which examined the root causes of these problems, echoing the conclusions from an October 2010 meeting of chief architects called to examine why the federal enterprise architecture program were not "as influential and successful as in the past."

Throughout this timeframe, agencies struggled to implement the FEA on their own, without a shared methodology that could be improved with time, and without clarity about how the expected business benefits would actually be realized. Finally, in 2012, a Common Approach to Enterprise Architecture was developed, and a second version of the FEAF was released the next year. In a 2016 postmortem, Why Doesn’t the Federal Enterprise Architecture Work, Gaver reflected on the progress which had been made over the previous 15 years from over $1B in Enterprise Investments at the agency level:

What should have been a very simple idea – five standard, federal-wide taxonomies to categorize investments, performance measures, and IT resources uniformly across the federal government – has, by misnaming them, spawned massive confusion about them and their real (simple) purpose... most people thought that the Reference Models were real models of something, or real things that autonomously existed in their own right, so these models gained a larger presence or significance than actually existed.

Two concerns of such frameworks are the robustness of the framework itself and the failure of organizations to develop effective measures of effectiveness to track progress over time. Since a framework's requirements are often broad and shallow, rather than narrow and deep, the biggest risk of EA efforts may be that of overcommitment, which is problematic to mitigate once a major EA effort has been launched.