Realizing the Business Value of Enterprise Architecture

Information technology (IT) organizations are increasingly faced with reducing the costs of current systems; elimination of multi-year, multi-million dollar, multi-consultant projects; absorbing required maintenance expenses; and delivering new systems faster, with lower risk, and at lower costs. CIOs are being asked to do more with less and stakeholders are demanding results in months—not years.

Enterprise architecture (EA) addresses many of aforementioned pressures facing corporations and federal agencies today. EA provides the architectural models and governance mechanisms that help an enterprise guide its change programs to design their solutions in a consistent and integrated manner. EA is the mechanism by which a business interprets its IT strategy into a series of change programs. In order to “do” EA, one needs a collection of resources that can be used to guide the development and maintenance of a broad range of architectures (Business, Data, Application, Technology etc.) This collection of resources is often referred to as an Architecture Framework. The output from these Architecture Frameworks is a collection of artifacts (viewpoints, views, process data and functional models, infrastructure specifications etc.) that variously consist of the actual architecture descriptions themselves. These architecture descriptions are then implemented as IT solutions.

When effectively implemented, an enterprise architect can bring order to the IT chaos that exists in many enterprises today and act as a key mechanism for bridging the worlds of business and IT. Unfortunately, few EA programs are properly implemented. With the passage of the Clinger-Cohen Act of 1996, federal agencies have been required to develop EA as a foundation for IT planning and implementation. As such, consultants have rarely been called in to perform an EA engagement from scratch. Instead, they are usually brought into an EA engagement that is having problems demonstrating business value. Typically, the consultant will find:

• collections of shelf-ware and an EA program effort that is isolated from the business;
• outdated technical reference manuals with technical specifications, best practices and recommendations;
• multiple data stores of ‘enterprise’ systems;
• mounds of spreadsheets and business process models created by a past parade of consultants who used a hodgepodge of modeling tools, taxonomies, and methods;
• collections of strategic papers, recommendations, and blueprints ; and
• a confused and frustrated client who has spent millions on these efforts with little to show to management that demonstrates business value.

There is a misconception that the adoption of an EA framework (i.e. Zachman, FEAF, TOGAF), following the CIO Council’s guidance on EA, using the OMB Federal Enterprise Architecture (FEA) Reference Models, and purchasing an EA modeling tool somehow magically result in the creation of tangible business value. However, there are numerous cases where the client religiously followed the aforementioned tenets of EA and came up with a collection of well-worded binders of information that was obsolete upon its completion and was unused by their strategic planners, application owners/ developers, or technical staff.

In the cases where the objective is to derive business value from past unsuccessful EA efforts, the following steps tend to apply:

• Make a complete inventory of past EA models, methods, artifacts, tools and repositories.
• Make a complete inventory of current documents/spreadsheets/repositories of information germane to EA such as application systems, investments, technology, strategic initiatives, etc.
• Detail the stakeholders of the above information assets and document the reports and forms derived from said information assets and how they’re used.

The goal is to glean as much business value as possible from existing EA artifacts rather than start another EA effort. The easiest way to garner such value is to collect, integrate and normalize these existing artifacts into an EA repository. One of the challenges a consultant faces, however, is the introduction of another piece of technology, such as an EA repository, to an already jaded client. The client has likely been sold EA modeling tools that have been improperly labeled as repositories and may have difficulty understanding the business value of an EA repository. To effectively integrate and make sense of the collection of EA and EA-related artifacts in the enterprise, however, a modern SQL-based EA repository is needed. The business case for the investment in an EA repository is based on the elimination of the myriad of current data stores of EA and EA-related artifacts. The repository must integrate, normalize, and facilitate the lifecycle of EA and EA-related information. The ability to finally extract and publish integrated reports that cut across previous stovepipes of information should be emphasized. The key to success is to get various stakeholders to agree to give up their current spreadsheets, MS Access databases and ad hoc data stores, provided this new repository meets their needs.

One client, for example, was managing an eight-volume technical reference manual which included best practices, technical standards and recommended technical products for various implementation scenarios. The simple act of updating, reviewing and publishing the document likely cost the client more than $200,000 a year. Given that the document was published annually and their rate of technology obsolescence, the document was outdated quickly. There was no link between this technical reference manual and their deployed systems. The application owners wanted to know when technical standards changed and how their systems were impacted. Such analyses were performed manually, resulting in additional shelf-ware for this client. The CIO wanted to know which of his enterprise applications were dependent of outdated technologies and which systems could be affected when a technology was replaced / removed. System developers wanted to know what collection of best practices, technologies, and products were related to the creation of a new technology service and where, if at all, this feature had been implemented in the enterprise. The paper-based manual simply didn’t meet their needs.

Fortunately the technical reference manual was written and structured logically. This enabled the client to take the information in the manual, structure it within the context of the OMB FEA Technical Reference Model taxonomy, and then tie the information to another repository of systems being maintained by the security Certification & Accreditation (C&A) personnel. The result was a repository-based technical reference manual and system inventory that could be queried, had traceability and roll-back features, standard reports, and a web-client interface. Perhaps the biggest demonstration of business value for the client was the ability to demonstrate the generation of any part of the original technical reference manual at the touch of a button and to show each stakeholder his or her requested report. This key interim success allowed the client to gain buy-in from the business community to further expand the EA program effort from a technical focus to a business and strategic focus. The EA program is now an effective component of their IT Governance processes.

One point, discussed earlier, was the notion that this central EA-focused repository would replace redundant stores of EA and EA-related material. As the scope of EA analysis grows from technology to business, to strategy, and to financial data stores, this notion of replacement and elimination of the other data stores is unrealistic. Most EA and EA-related data stores fall under the domain of the CIO and thus, in theory, can be consolidated if it makes business sense. These other data stores contain information and/or metadata of interest to EA, but are owned and maintained by other business units. For such a scenario, a federated architecture is most appropriate. Federation is the concept that a collection of resources can be viewed and manipulated as if they were a single resource while retaining their autonomy and integrity. Federation creates a temporary “view” by integrating up-to-date data from multiple sources on the fly. Federation allows clients to combine data from different databases. Data need not be copied, but replication can be used to create a centralized view of enterprise information and to support time series analysis. Within a federated database architecture, the central EA repository can query data from other autonomous heterogeneous data sources which can be structured or unstructured. The key to fostering cooperation with these other business domains is to demonstrate the value of information-sharing and to demonstrate the ease of a federated architecture over labor intensive data calls.

EA repositories have evolved from collections of non-integrated architectural artifacts to elaborate decision-support systems. There are significant differences, however, among EA repositories. Before selecting a given repository one should consider:

• Relational versus Object-Orientated versus Hierarchical designs
• The ability to perform true SQL-based queries
• The ability to manage the lifecycle of data within the repository
• The ease of data management, data import and data export
• Role-based security features
• Ease of canned queries, ad hoc queries, standard reports, HTML generation
• Data-driven visualization of object relationships within the repository
• Integration with existing modeling tools and other data sources
• Pre-built dash boards and applications
• Portal interface
• Open database support versus dependency on a single vendor’s solution
• Technical support, stability of the company and installation references

Experience suggests the use of a relational repository over object-oriented or hierarchical designs. The ability to perform true SQL-based queries is predicated on a relational architecture. Reporting, data management, data integration and performance are all superior with relational-based repositories.

Deriving business value from EA need not be difficult. For the most part, enterprises likely have collections of information on hand from which to derive value and drive modernization. The value of this legacy data is often called into question, but you can always find some value in the data when it is integrated with other sources of information. The key to the derivation of business value is the collection, integration, normalization and presentation of this data as information to stakeholder groups. A repository based on a relational database architecture is key to the integration and normalization of this data. Most organizations can immediately derive positive ROI on the repository investment from the elimination of redundant data stores. This approach yields quick results to a broad base of stakeholders, increasing the odds of program success.

by Dr. Fred C. Collins, Ph.D.