Advancing Enterprise Architecture Maturity

Version 2.0

Developed for: The Federal CIO Council (CIOC)

The Federal Enterprise Architecture Program Management Office

(FEA-PMO)

By: Industry Advisory Council’s Enterprise Architecture Shared Interest Group

January 2005

i

Table of Contents Table of Figures.................................................................................................... iii Disclaimer ............................................................................................................. iv Credits.................................................................................................................... v Executive Summary.............................................................................................. 1

1. Strengthened and Continued Executive Sponsorship and Involvement ..... 1 2. EA Development Planning ......................................................................... 1 3. Need to Share Lessons Learned and Best Practices Across the Federal

Enterprise .................................................................................................... 2 4. Lack of Clear and Consistent EA Guidelines ............................................. 2 5. Need for Consistent and Complementary Maturity Models ....................... 2

EA Maturity Model Paper Version 2.0 ............................................................... 4 1. Introduction..................................................................................................... 4

1.1 Audience .................................................................................................. 4 2. Organization of This Document...................................................................... 4 3. Benefits to the Government ............................................................................ 5

3.1 ROI and Business/Mission Benefits ........................................................ 5 3.2 Current Maturity Assessments................................................................. 6

4. Successful Practices for Developing Enterprise Architectures....................... 7 4.1 Obtain Executive Buy-In and Support..................................................... 7 4.1.1 Applicable EAMMF Element(s)........................................................... 7 4.1.2 Successful Practices .............................................................................. 7 4.1.3 Pitfalls to Avoid .................................................................................... 9 4.2 Establish Management Structure and Control .......................................... 9 4.2.1 Obtain Organizational Buy-In............................................................... 9 4.2.2 Structuring and Utilizing the EA Team Effectively ........................... 14 4.3 Define an Architecture Process and Approach ....................................... 16 4.3.1 Defining the Purpose, Scope, and Framing of the EA........................ 16 4.3.2 Establishing an Approach to Enterprise Architecture......................... 20 4.3.3 Plan the EA Program .......................................................................... 27 4.4 Develop the Enterprise Architecture and Sequencing Plan .................... 30 4.4.1 Recognize and Leverage Thought Leadership.................................... 30 4.4.2 Developing the Enterprise Architecture.............................................. 32 4.4.3 Facilitating Reuse................................................................................ 47 4.4.4 Establishing Agency-to-Agency Integration....................................... 49 4.4.5 Conduct Independent Verification and Validation (IV&V) ............... 50 4.5 Use the Enterprise Architecture .............................................................. 51 4.5.1 Tie EA Sequencing Plan into the CPIC Process................................. 51 4.5.2 Utilize the EA for Operational Decision Making ............................... 53 4.6 Maintain the Enterprise Architecture...................................................... 53 4.6.1 Applicable EAMMF Elements ........................................................... 54 4.6.2 Description of Successful Practices .................................................... 54 4.6.3 Pitfalls to Avoid .................................................................................. 54

5. Summary and Recommendations ................................................................. 55 1. Strengthened and Continued Executive Sponsorship and Involvement .. 55

ii

2. EA Development Planning ...................................................................... 55 3. Need to Share Lessons Learned and Best Practices Across the Federal Enterprise ..................................................................................................... 55 4. Lack of Clear and Consistent EA Guidelines .......................................... 56 5. Need for Consistent and Complementary Maturity Models .................... 56

Appendix A — Description of the GAO EAMMF and the OMB EAAF......... 1 A.1 Overview of the GAO EAMMF .................................................................. 1 A.2 OMB EAAF Overview ................................................................................ 3

Business Value of Enhancing EA Maturity .................................................... 4 Emphasis on Benefits at Each Level............................................................... 4

Appendix B — References.................................................................................... 1

iii

Table of Figures Figure 2-1. FEAF EA Process ................................................................................ 5 Figure 4.2.1-1. Overall FEA Schema.................................................................... 12 Figure 4.2.2-1. Typical Structural Relationship Between the EA Team

and Other EA Governance Entities (From the Practical Guide)............... 15 Figure 4.3.1-1. The Relationships of Various Architectures for Planning

an EA Program.............................................................................................. 17 Figure 4.3.2.2-1. The Line-of-Sight PRM Mapping of Metrics from the

Technology to the Business Outcomes ..................................................... 23 Figure 4.3.3-1. Example Governance Structure.................................................... 29 Figure 4.4.2.2-1. The FEAF Depicts the Major Generic Components of

the EA That Are Required ........................................................................ 34 Figure 4.4.2.2-2. The FEA Reference Models and How They Work Together

in an EA Context....................................................................................... 35 Figure 4.4.2.4-1. Mapping of the FEA Reference Models to the Zachman

Framework (Note: the DRM shown above is from a previous draft of the DRM.)............................................................................................. 40

Figure 4.4.2.5-1. Example Relationship between Process Life Cycles ................ 41 Table 4.4.2.5-1. Representative EA Life Cycle .................................................... 42 Figure 4.4.3-1. Use of XML to Specify Data Exchange Standards...................... 48 Figure 4.4.4-1. Depiction of the Sharing and Reuse Concept of the FEA............ 49 Figure A-1-1. EAMMF Version 1.1 ....................................................................... 2

iv

Disclaimer While the American Council for Technology/Industry Advisory Council (ACT/IAC) has made every effort to present accurate and reliable information in this report, ACT/IAC does not endorse, approve, or certify such information, nor does it guarantee the accuracy, completeness, efficacy, and timeliness or correct sequencing of such information. Use of such information is voluntary, and reliance on it should only be undertaken after an independent review of its accuracy, completeness, efficacy, and timeliness. Reference herein to any specific commercial product, process, or service by trade name, trademark, service mark, manufacturer, or otherwise does not constitute or imply endorsement, recommendation, or favoring by ACT/IAC.

ACT/IAC (including its employees and agents) assumes no responsibility for consequences resulting from the use of the information herein, or from use of the information obtained from any source referenced herein, or in any respect for the content of such information, including (but not limited to) errors or omissions, the accuracy or reasonableness of factual or scientific assumptions, studies or conclusions, the defamatory nature of statements, ownership of copyright or other intellectual property rights, and the violation of property, privacy, or personal rights of others. ACT/IAC is not responsible for, and expressly disclaims all liability for, damages of any kind arising out of use, reference to, or reliance on such information. No guarantees or warranties, including (but not limited to) any express or implied warranties of merchantability or fitness for a particular use or purpose, are made by ACT/IAC with respect to such information.

v

Credits This white paper was developed by the below individuals under the auspices of the Industry Advisory Council (IAC):

Name Organization E-Mail Address Supriya Ghosh Lockheed Martin supriya.ghosh@lmco.com Craig Miller Blueprint Technologies cmiller@blueprinttech.com John Przysucha Booz Allen Hamilton przysucha_john@bah.com Chander Ramchandani Computer Sciences Corporation cramchan@csc.com Michael Tiemann AT&T Government Solutions tiemann@att.com

The authors would like to specially thank our leader, Chander Ramchandani, for his patience, persistence, and support in helping us produce a quality paper, and the IAC Enterprise Architecture (EA) Shared Interest Group (SIG) leadership team — Chair, Puvvada Venkatapathi (PV); Co-Chairs, Dan Toomey and John Dodd; and Federal Programs Coordinator, Davis Roberts — for their sponsorship and support of this White Paper.

The EA-SIG would also like to thank Carolyn Strano, Senior Professor at the National Defense University IRM College; Mike Dunham, former Chief Architect at the U.S. Department of the Treasury; Steven Lowe, Senior Enterprise Architect at the Department of Housing and Urban Development; and John Sullivan, Chief Architect at the Environmental Protection Agency, for their time and thoughtful reviews and comments, as well as contributions, to this paper. A listing of all comments and the authors’ responses/actions is available on request.

1

Executive Summary This White Paper was prepared by the IAC EA SIG Governance Subgroup with the intent to address specific issues identified by the Government Accountability Office (GAO) as a result of a Government-wide survey. The GAO created the EA Management Maturity Framework (EAMMF) based on the EA Practical Guide that measures how Enterprise Architectures are/are not addressing the root business/mission and IT gaps that the passage of the Clinger Cohen Act of 1996 was to address. What the GAO found in using the EAMMF was that, while there has been progress, there are still many shortfalls in the maturity of processes, and the utilization of EAs in actual governance and decision-making is still lacking.

This paper is intended to specifically address these shortfalls and to present successful practices used by experienced industry and former Government architects to remedy or correct them and to assist in closing any gaps. In many cases, pitfalls to be avoided are also identified. The document is structured using the Practical Guide EA Development Process as an organizing structure and the GAO findings to target areas where significant improvement is necessary. We are confident that Federal organizations will be able to utilize many of these practices to successfully advance the maturity of their EAs.

In addition to presenting successful practices, the paper also identifies five significant obstacles that many Federal organizations are experiencing in their EA development efforts and provides recommendations for removing these obstacles. The recommendations are based on a comprehensive review by the EA SIG and reflect many of the EA lessons learned (good, as well as, bad), best practices, and corporate knowledge of the IAC member companies. These obstacles and corresponding recommendations are summarized below.

1. Strengthened and Continued Executive Sponsorship and Involvement The lack of strong executive sponsorship and ongoing leadership was identified as a major hurdle in agency EA development efforts. This appears to be a widespread problem; EA development is generally delegated to the CIO, and, in many cases, there is very little continued involvement in its development by agency heads and senior executives after the initial kickoff.

Recommendation: IAC recommends that OMB require agencies and departments to document their plans for continued executive involvement and sponsorship (e.g., as part of an EA Executive Review Board that meets periodically) to monitor progress, and to ensure that resources are provided to enable the required momentum to be maintained on EA development.

2. EA Development Planning It appears that many agencies/organizations lack up-to-date, realistic EA development plans that are adequately funded.

Recommendation: IAC recommends that OMB prepare detailed guidelines on preparing and funding EA Program Plans to assist agencies with developing/updating their EA development, governance, and program activities.

2

3. Need to Share Lessons Learned and Best Practices Across the Federal Enterprise While some departments and agencies have mature EA programs, the majority of the organizations are struggling in their EA development efforts. EA programs in most departments and agencies would benefit from sharing of lessons learned, successful/best practices, and artifacts relating to the best practices, as well as pitfalls to be avoided in order to enhance the pace and the quality of EAs being developed.

Recommendation: IAC recommends that the CIO Council Architecture and Infrastructure Committee, through the Chief Architects Forum or other Subcommittees, facilitate this knowledge sharing. In particular, specific steps that could be taken by the Committees and with the IAC as partners include the following:

Developing a process and a set of quality criteria (and/or template) for documenting, collecting, and vetting EA lessons learned across the Federal Enterprise, and making them available in either a repository or a directory of links that serves as an organizing framework for use by all agencies.

Developing a process for identifying, evaluating, selecting, collecting, and vetting examples of high-quality EA documents, models, artifacts, and work products, and making them available in a repository for use by all agencies.

4. Lack of Clear and Consistent EA Guidelines The GAO used the FEAF and other previous CIO Council EA guides and addressed the overall methods, capabilities, and approach to developing an EA. These EAs are at varying levels both at the department-wide and at the component levels of agencies (as well as at smaller agencies and independents boards and commissions). Currently, no guidance or policy exists that defines the comprehensive coordination of the development of component agency level EAs ( as articulated by the GAO), or how to distill and integrate the agency-level architectures into departmental EAs (or departmental EAs into a Federal EA — including the Lines-of-Business and E-Gov initiatives). It is believed that this lack of clarity has hampered EA maturity across the Government.

Recommendation: IAC recommends that a coordinated presentation on the recommended approaches to developing departmental EAs, ensuring alignment of each constituent agency’s architecture with the department-level EA, be developed and broadly disseminated including briefing agency heads and senior department and agency managers. Key areas of the approach might be collaborative governance, development of business cases across multiple agencies (lines-of-business), and identification of common/shared services to be implemented at the department level, among others. This could ultimately mean revising all of the past and current guidance into a comprehensive set of EA guides. It would also articulate the compatibility and complementary aspects of the current set of FEA reference models with previous EA methods and frameworks recommended and used. The guides could also address gaps in current guidance, such as how agencies can apply Model Driven Architectures and Service Oriented Architectures.

5. Need for Consistent and Complementary Maturity Models Multiple EA maturity models that overlap and do not consistently measure the goodness, the impact, and the completeness of EAs can be confusing and very frustrating to the staffs of agencies and departments that are trying to use them to improve EA maturity. The OMB and

3

GAO EA Maturity Frameworks could be tuned to ensure that they are consistent and complementary, if not mutually exclusive in their measured assessments. Recommendation: IAC recommends that the GAO (EAMMF) and OMB (EAAF) maturity models be reviewed and normalized such that together they form a consistent yet non-redundant set of maturity metrics that measure the goodness of the EA methods and practices as well as the EA impact and traction toward agency modernization and transformation.

4

EA Maturity Model Paper Version 2.0

1. Introduction The purpose of this White Paper is to facilitate the advancement of the maturity of Enterprise Architecture (EA) efforts within Government organizations in order for the benefits of enterprise architecture to be achieved. EA efforts are key to the transformation of Government to a business value–driven approach. This paper describes practices and lessons learned from successful EA programs and is based on the experience and knowledge of the authors — all EA practitioners.

The document is not a comprehensive guidebook on developing EAs, but is rather a collection of successful practices and advice from members of the IAC SIG on Enterprise Architecture. The successful practices have been described for selected elements of the EAMMF 1.1, as well as activities involved in the development of EAs.

1.1 Audience This paper is intended primarily for Federal and other Government personnel who are involved in the development of an EA for their organization. This includes, but is not limited to, management (including the agency head, the CIO/CTO, other executives, business area managers, line managers, and project managers) and IT investment managers and staff members who are involved in EA development and support activities. This paper is also intended for chief enterprise architects and other practitioners who have a need to advance an organization’s enterprise architecture maturity successfully, and need assistance to do so. Conversely, this paper is not intended for those who have no prior knowledge of EA and its requirement for use in the Government. The paper does require some prerequisite understanding of basic EA premises and approaches.

2. Organization of This Document Successful practices in this document are organized by the steps in the FEAF process depicted in Figure 2-1 (taken from “A Practical Guide to Federal Enterprise Architecture” [Reference 1]), which was also the basis for the GAO EA Management Maturity Framework (EAMMF). Section 4 of this document contains a subsection for each step in the FEAF process; the steps for generating the baseline and target EAs and the sequencing plan are presented in a single subsection.

5

Obtain Executive Buy-In and

SupportEstablish

Management Structure and

Control

Define an Architecture Process and

Approach

Develop Baseline Enterprise

ArchitectureDevelop Target

Enterprise Architecture

Develop the Sequencing

Plan

Use the Enterprise

Architecture

Maintain theEnterprise

Architecture

Section 4.1

Section 4.2

Section 4.4Section 4.4

Section 4.4

Section 4.5

Section 4.6

Control and Oversight

Section 4.3

PC2000-3915-001a, 8/26/04

Figure 2-1. FEAF EA Process

3. Benefits to the Government

3.1 ROI and Business/Mission Benefits A key to measuring the return on investment (ROI) is to establish the rules for attribution of the savings or value of the benefits early on. For example, calculating the direct costs savings and the indirect benefits to processes integration of data reuse or components standardization and reuse, and then attributing it as a certain, preset percentage, is a way of starting to aggregate some of the payback values of the EA. This takes careful articulation and negotiation, often with the budget personnel and/or the performance measurement and tracking group. Nonetheless, if the attribution rules are set, then there is a basis for collecting and aggregating the costs, be they business efficiencies, new capacities, expenditure avoidances, and/or actual dollar value savings.

In addition to these attributed savings, there are broader benefits that cannot be easily articulated via a dollar value but that are still very important. Recently, a staff person from the Environmental Protection Agency said that the added integrity and dependability of its data were critical to citizen confidence and were immeasurable in terms of actual dollars. The surety of Government information, impacted in no small means through quality architecture, is, as they say in the recent popular credit card commercial, PRICELESS.

The OMB now requires that an aggregated or consolidated EA Program be defined and that an Exhibit 300 business should be carefully aligned with and derived from the EA. This is a good opportunity to start the identification and definition processes for the ROI calculations, including the rules for attribution, as ROI is a major business case component. The Exhibit 300 should be carefully aligned with and derived

The added integrity and dependability of aggregated data are critical to citizen confidence and are immeasurable in terms of actual dollars. — Environmental Protection Agency

6

from the EA Program Management Plan. It should also take into consideration the findings of the GAO and OMB maturity assessments and attempt to base activities and initiatives that address requirements that enable achievement of greater program maturity.

3.2 Current Maturity Assessments In addition to the EA documentation, the models, definitions, principles, and other artifacts that make up the EA, it is important to assess the EA Program and the other aspects of how the EA is being utilized within IT governance and decision making. There have been two recent assessments conducted that measured at least in part these facets of EA at Federal agencies. They are the GAO’s Survey using its EA Management Maturity Framework (EAMMF) and the OMB’s EA Self-Assessment Framework (EAAF). The latter attempts to measure the traction of the agency’s EA in the context of how and what it is impacting. The GAO survey is more focused on the EA Program and an agency’s capacity to develop and use an EA, and how far it has come in terms of actually creating an EA. The two maturity frameworks are complementary and are described in greater detail in Appendix A.

There are not many organizations in the Government that have been assessed at greater than level 3 on either framework; however, it is quite possible that within the next year there will be quite a few agencies which will have achieved either a level 3 on the OMB scale or a level 4 or 5 on the GAO scale. In part, the added emphasis of having these measurement indexes has created additional focus and utilization by the agencies. Many contracts for EA Program support are indexed to achievement of increased maturity levels. In the GAO survey, only the Executive Office of the President was able to provide supporting justification to be given a level 5 designation. Also, the brand-new Department of Homeland Security got a level 3 grade, at least partially on the shoulders of much of the EA work done in its component agencies, like the U.S. Customs Service, which had been a level 5 on the previous GAO survey in 2001.

Generally speaking, a mature organization in terms of its EA is one that uses it in multiple ways, from IT decision making to organizational realignments and business redesign and transformation. No budget is approved unless it is in alignment, explicitly, with the EA. This alignment is real and must be documented via an objective assessment process and defined criteria.

In an organization with a high level of EA maturity, no budget is approved unless it is explicitly aligned with their EA.

7

4. Successful Practices for Developing Enterprise Architectures This section contains practices that the authors have used successfully in their EA projects. Each subsection contains one or more topic areas. The discussion of each topic area is organized as follows: An overview of the topic area

Applicable EAMMF elements — this is the Maturity model Stage and Attribute for the element(s) being addressed by the subsection

Successful practices

Pitfalls to be avoided.

4.1 Obtain Executive Buy-In and Support As reinforced by the GAO and articulated by most EA practitioners, the highest-level executive sponsorship of EA is a key success factor. This sponsorship then permeates the rest of the organization. Further, development of a successful EA requires active participation by both the agency business lines (i.e., Bureaus, Offices, Agencies, and/or Programs) and Information Management/Information Technology (IM/IT) organizations. An effective, visible executive sponsorship of the EA Program goes a long way toward ensuring that an agency commits the right level and type of resources to conduct a successful Enterprise Architecture Program. Lack of senior executive leadership and attention was the major, and titled, finding of the November 2003 GAO Report on EA progress in the Government [Reference 2].

4.1.1 Applicable EAMMF Element(s) Stage 2, Attribute 1, “Demonstrates Commitment.”

4.1.2 Successful Practices Two important EA sponsorship practices observed in agencies where EA is considered successful are demonstrated serious managerial commitment and a sponsorship network.

Demonstrated Serious Management Commitment The Practical Guide [Reference 1] clearly identifies the need for agency EA sponsorship by the agency head. For example, at the IRS, the Commissioner was the visible sponsor of the EA Program. Similarly, on the Department of Defense (DoD) Financial Management Modernization Program (FMMP), which will modernize financial management operations throughout the DoD, the Secretary of Defense has clearly and consistently articulated a strong message of organizational commitment for the development of the Financial Management Enterprise Architecture (FMEA). Within that department’s top 10 programs, development of the FMEA falls only one below Homeland Security. At the Department of

Despite OMB’s architecture-related activities, agencies continue to face the same management challenges that we identified 2 years ago — that is, obtaining top management support and commitment, overcoming parochialism, and having the requisite resources (financial and human capital) to get the job done. Moreover, the percentage of agencies identifying these management challenges has grown. — GAO EA Survey, November 2003

8

Veterans Affairs (VA), the Secretary has vocally articulated both the reasons for and the vision to use the EA as the transformational mechanism to achieve the goal of “One VA.” Slight variations of this approach have been shown to work as well. At the DOE, the Deputy Secretary, as the agency’s Chief Operating Officer (COO), was directly involved in articulation of the EA vision.

In all of these instances and others like them, the need to drive the technology plans as well as agency transformation from the EA have been understood and articulated by leaders. In every case this also translates into ensuring that the business units participate, contributing appropriate input so that the business models are accurate and sufficiently detailed.

Agency heads or the other senior executive sponsors (such as the Deputy Secretary as the COO) need to periodically reiterate their commitment throughout the life cycle of the EA Program. This can be done in a number of ways, but most effectively it is accomplished by ensuring that the EA is a visible component of the senior leadership’s strategic and annual plans and their performance agreements. It is also important that the executive sponsorship translates into budget commitment commensurate with the size, scope, and complexity of the agency’s EA Program. For example, the DoD Financial Management (FM) initiative created a separate budget line item in order to get support and approval for funding by OMB, the President, and Congress. The budget resources provided the funding for all needed elements of the FM Enterprise Architecture (FMEA) Program, including the Program Management Office as well as contractor support for FMEA development and documentation. This was also the case at the DOE where a multi-year Corporate Systems Modernization budget line item was created and approved. It includes monies for architecture, planning, business process redesign and technology acquisition, design, and implementation.

At the Immigration and Naturalization Services (INS), sponsorship by the agency leadership, in the form of a memo from the Commissioner, enabled the dedication of resources across the agency committed to the fulfillment of the EA project. The INS EA initiative received funding appropriate for the complexity of the project, and a cross-agency commitment of personnel representing the business areas to provide ongoing support related to internal processes, critical cross-agency information, and future direction.

The business value of enhancing an EA is not always readily apparent. In many cases, so far, the criteria seem to be more along the lines of “Do you have an EA?” and not “What is its quality, depth of coverage, completeness, or accuracy?” There can be significant value in the enhancement of an EA Program because it can give the proper vision to open up a great number of additional e-Gov and consolidation opportunities. These can also lead to other approaches to IT like consolidation of services, help desks, and infrastructure. In at least one major department, the analysis of potentials identified approximately $25 million in savings, per year, based on an architectural analysis supported by infrastructure consolidation.

Increasingly, senior management is aware of the Federal EA efforts, and it is not as hard as it once was to get EA on to their agendas. Using the maturity evaluation of GAO (and/or OMB) is one way to help executives understand the EA and the need to mature it.

Establishing a Sponsorship Network Sponsorship by the agency head, or at least the Chief Operating Official, needs to be cascaded and reinforced through the organization in order for the EA Program to receive the degree of cooperation from and participation by all needed stakeholders, or at a minimum, from the influential business units. Thus, it is important that an agency develop a sponsorship network consisting of agency senior managers who keep the EA Program on the “radar screen” of necessary agency participants. As an example, on the IRS

9

EA Program, the sponsorship network included the COO and the executives responsible for governance and execution of the modernization programs.

At the sub-agency level within the Department of Energy (DOE), sponsorship networks were developed through an iterative planning and project development process. By addressing immediate initiatives, the EA teams were able to provide proofs of concept related to the enterprise perspective.

When planning IT projects, EA teams were able to confirm that EA was a vehicle for achieving savings and leveraging investments. After identifying the first viable business sponsor and demonstrating the benefits of a broader perspective, other business area initiatives were folded into the EA migration process with willing sponsors.

4.1.3 Pitfalls to Avoid It is important that the sponsorship declarations, both from the agency head as well as from the sponsorship network, be made at the very outset of the EA Program, and reiterated periodically throughout the duration of the program. Common pitfalls are that the sponsorship is provided after the EA Program is underway, or only in passing by a few senior managers with no further reiteration of the message. This can happen by virtue of administration change or just by the changing of executive leadership at the top of the agency. There are ways to mitigate this, the most important of which is to ensure that, in as many ways as possible, the EA is integrated into the fabric of each agency’s management policies, procedures, and structures.

4.2 Establish Management Structure and Control

4.2.1 Obtain Organizational Buy-In Implementing an EA in any but the smallest organizations will require the support and buy-in of many organizational units and sub-units. Most Federal agencies are composed of many semi-autonomous groups, each of which has its own current architecture. Some may have started planning and developing an EA or may have identified functional or business drivers. All will be stakeholders in the agency-wide EA implementation process. A successful EA development and implementation process must recognize and accommodate the disparate and heterogeneous organizational units at all levels of the organizational hierarchy. Obtaining organizational buy-in may be facilitated by the following practices:

Recognizing the hierarchical structure of the organization and aligning the EA scope to it

Developing a modular EA that allows choice or substitution of components

Offering support and assistance to groups (sub-agencies) implementing the EA.

These practices are discussed below. They are primarily shown as applying to the EA development phase, but may be extended to all phases of the EA life cycle.

Obtaining EA support from within an organization requires buy-in from stakeholders that represent all of the various business and technical components.

10

4.2.1.1 Applicable EAMMF Element(s) Stage 2, Attribute 1, “Demonstrates Commitment.”

4.2.1.2 Successful Practices

Recognizing the Structure of the Organization and Scoping the EA to It Organizations are generally hierarchical in nature. For example, a simplified organizational hierarchy representation of the Federal environment might include the organizational hierarchy levels shown below.

1. U.S. Government

2. Federal Government (Federal Enterprise-wide level)

3. Agency/Administration/Department (Departmental Level)

4. Bureau/Agency/Program/Office (Component Agency Level)

5. Independent Agencies, Commissions, and Boards

6. Other Related Stakeholders

The architectural approach selected for the EA must identify aspects or components to be implemented at each level of the organizational hierarchy. It must recognize and accommodate the likely existence of an EA above or below the level where the current EA is targeted. Often, early recognition of this fact and accounting for it in the scoping can avoid later potential clashes and confusion.

An EA developed at the agency level must allow bureaus to develop suitable EAs supporting their non-redundant internal operating environment. An EA developed by a bureau, where the agency has not yet begun development of an EA, must be able to accommodate the eventual development of an agency-level EA. The EA for any level of the hierarchy must balance the need for a consistent architecture in all organizational units below that level against the need of each subunit to develop an EA at their level that recognizes their often unique business/mission needs.

With the advent of the Federal Business Reference Model and the other reference models (Performance, Service Components, Technology, and, most recently, Data), the requirements for alignment of agency EAs at the Federal cross-Government level is increasingly expected and required by the OMB.

For example, an EA developed for the Department of Health and Human Services (DHHS) must provide a common architecture for all of DHHS and still allow the National Institutes of Health (NIH) and the Centers for Disease Control and Prevention (CDC) to develop aspects that will address their specific needs not in common with the rest of the enterprise. The architecture for NIH and CDC must allow each to customize their architectures to support unique business needs while remaining consistent with, and integrated and interoperable with, the overall DHHS architecture. All of this must also align with the National Health Line-of-Business architecture and encompass past activities such as the common patient record collaboration between a number of Federal agencies with heathcare business functions.

This level of flexibility is necessary to achieve the buy-in of organizational subunits. Each subunit must be involved during the EA development phase. This includes the business and functional elements as well as the IT elements of each subunit. Early in the EA process, achieving organizational buy-in requires that each subunit be contacted, invited, and involved. Each subunit must be assured of how the development of the EA can benefit it, and how it is to participate.

11

Often the work done on the EAs at the bureau levels can be applied to or leveraged at the agency or department level to accommodate EA portions that either are not yet developed or are not as robust as the lower-level EAs. There are many instances at cabinet-level departments where this is true and is in fact happening. Some of these federated agencies where the department-wide effort includes or incorporates their agencies EA parts, models, artifacts or components include the Departments of Energy, Labor, Health and Human Services, Homeland Security, and Veterans Affairs, to name just a few. While the length of this paper precludes providing added details regarding the specifics of how these incorporate their component agencies’ EAs, coordination with their EA staffs regarding how they achieved this may be warranted for agencies facing a similar challenge.

Developing a Modular EA that Allows Choice or Substitution of Products The EA approach must be designed from the start to consider what is allowed in the way of multiple, occasionally competing technologies and business practices within a specified range (i.e., business area, divisions, regions, or organizations). Typically, this is after an assessment of which technology modules would be most appropriate for specific organizational structures. An example of the tailoring required is a personnel management module of the EA that is only suitable for an organizational unit of less than a few hundred employees, and a module that is only suitable for a unit of more than several thousand.

The EA should define these options, ensure compatibility and interoperability, and facilitate the possible future move to combined personnel management architecture for the entire organization. This will facilitate the growth and evolution of the EA over time, as products and technologies change. It will also increase the ease of obtaining the buy-in of sub-organizations, as each subunit will be able to see how and where it will be able to insert component modules that are most appropriate for them, within the broader reference models and bounds of the overall agency-wide EA. In the above example, for instance, as the FEA Human Resources Line-of-Business (LOB) matures and solutions across the Federal sector are proffered, these functional areas of the Department and agency EAs in all likelihood will be superseded. And unless this adaptive approach is taken, major dislocations in the EA will ensue. Figure 4.2.1-1 below depicts the overall FEA Schema with the current LOBs identified.

12

Business Alignment

Change

Convergence

Integration

Governance

AgencyEA Program

Line ofBusiness

EA Program

FEA PMO E-GovEA Best

Practices

SRMERM TRM

DRMPRMCitizens

Partners

Emerging Technology

Changing Business Conditions

Legislation

Agency Mission

Better Management

of IT Portfolio

The current FEA LOBs are:• Human Resources• Financial Management• Grants• Case Tracking• Federal Health Architecture

MaturityBusiness ModelRequirements

ResultsOperational EADrivers

Business Alignment

Change

Convergence

Integration

Governance

Business Alignment

Change

Convergence

Integration

Governance

AgencyEA Program

Line ofBusiness

EA Program

FEA PMO E-GovEA Best

Practices

SRMERM TRM

DRMPRM

SRMERM TRM

DRMPRM

SRMERM TRM

DRMPRMCitizens

Partners

Emerging Technology

Changing Business Conditions

Legislation

Agency Mission

Citizens

Partners

Emerging Technology

Changing Business Conditions

Legislation

Agency Mission

Better Management

of IT Portfolio

The current FEA LOBs are:• Human Resources• Financial Management• Grants• Case Tracking• Federal Health Architecture

MaturityBusiness ModelRequirements

ResultsOperational EADrivers

PC2000-3915-002a, 10/12/04

Figure 4.2.1-1. Overall FEA Schema

The architecture must be designed to be modular so that organizational subunits may implement the pieces that they require, yet in a manner consistent with higher-level architectures (such as departmental EAs or the FEA Lines-of-Business). In some cases, for example in the technology layer of the EA, this may mean allowing the use of competing products, provided that they use common, compatible, or interoperable technical standards. Subunits often will be unlikely to buy into an architecture that does not allow them freedom to choose the components that they feel they legitimately need to satisfy business/mission needs or capabilities.

Especially in large, federated departments, it is recommended that a technology performance standards approach be adopted. In large, federated departments the ability to realistically control tightly developed technical standards is limited. Through technology performance standards, a department should be able to ensure compatibility and interoperability for any technologies deployed. It frees the department from the responsibility of trying to enforce technology standards and focus more importantly on the resulting performance. Technology performance standards are also more adaptive to changes in technology.

An EA that is not governed flexibly or designed to allow some choices and/or substitution of components is unlikely to succeed in a large, diverse agency, although it may work well as a strategy for smaller agencies. This is beginning to change and some interesting experiments are now underway in several large agencies wherein the imposition of limited desktops, servers, and related operating systems and software is being phased out. For example, all parts of an organization are unlikely to buy into a technology architecture that permits the use of only one database product or one messaging system. However, an architecture that specified performance standards for an enterprise-wide major database

13

system/software and a compatible low-end desktop database system/software, describing the parameters for how they would interoperate, is more likely to succeed.

Offering Support and Assistance to Groups Implementing the EA Organizational subunits are more likely to buy into a demonstrated architecture when the “owner” of the EA implementation, such as the EA Program Management Office (PMO), provides implementation support and assistance. Demonstrating the feasibility of the technical aspects of EA may require a test bed, where the components can be shown operating as intended and where new, unique components of subunit architectures can be tested with the common solution set. This test bed can provide a training ground for technical and business process professionals who will be implementing the EA in the subunits. Implementation assistance such as this can increase the level of buy-in throughout the organization dramatically. Of course direct funding for EA implementation (by the CIO or Chief Architect through the EA group, the PMO, or direct sponsoring of contractor support) will help increase organizational willingness to develop, adopt, or comply with the architecture. Other forms of assistance that can be provided to subunits include:

Onsite training in processes, tools, or new products

Facilitation of business, data, applications, and technical working groups to develop common solutions

Development of a common technical reference model, showing a baseline configuration of all subunits

Establishment of templates and guidelines for the development of project management plans, schedules, and resource estimates for EA implementation in subunits or business areas

Sample reference models for unified business practices, including documentation such as personnel management information manuals or system security plans that conform to the EA model

Organization-wide quantity purchasing discounts.

4.2.1.3 Pitfalls to Avoid There are some common pitfalls that often prevent all or some parts of an organization from buying into and supporting an EA. They include:

The false belief that the CIO, agency head, or other top official can unilaterally force an EA approach onto a large agency, given the law. Buy-in from all (or most) levels and organizational subunits is still necessary for the long-term success of an EA Program.

Developing an EA that is a “one size fits all” approach. For many elements of the EA, you may want to offer choices like a “large, medium, and/or small size” solution or a high/low service level.

Developing an EA prematurely without sufficient analysis and consultation to demonstrate that it is feasible not only technically but also business-wise and politically.

Offering so many choices that your EA does not congeal into at least some common, reusable business processes, data objects, applications, user interfaces, shared infrastructure, and other EA outcomes to bring the benefits of standardization and common practices.

14

Presuming that an EA that is acceptable to all organizational subunits will automatically be fully accepted. It must be shown that it is operationally compatible with and achieves buy-in from each subunit’s management.

Not recognizing the wide diversity in a large organization and ensuring that the EA can accommodate it, such as in flexible business models, component deployments, or even data definition and use; in such cases, consider having some of the more respected and influential subunits implement the EA first, and then assist other subunits.

4.2.2 Structuring and Utilizing the EA Team Effectively The composition of the EA team has a major impact on the quality and completeness of the EA that is developed. This subsection describes selected successful practices in structuring and utilizing the EA team.

4.2.2.1 Applicable EAMMF Elements Stage 2, Attribute 1, “Demonstrates Commitment.”

4.2.2.2 Successful Practices The development of the “To-Be” business strategy and architecture for an organization is a significant undertaking that requires the participation and buy-in of senior business managers in an organization. Often this activity is delegated to mid-level or junior-level managers or staff in the organization, without adequate review of senior management, including the agency head. The decisions made in conducting this activity have a major impact on the effectiveness of the business transformation, the IT strategy, and the investment decisions made by the organization, and can fundamentally affect the way in which the organization conducts business in the future. It is therefore critical to involve senior agency business managers in this activity from the outset and to ensure their continued oversight after the business architecture is identified.

Many organizations staff their EA projects or program offices largely with technical architects and do not include members drawn from each major business unit/line-of-business within the organization. In some cases, while the team includes representatives from the business units, their time commitment is not commensurate with the needs of a successful EA effort. This leads to the EA being overly focused on technology, without adequate consideration of business functions, capabilities, needs, and benefits. The EA Program Manager (or Chief Architect) must seek to ensure the adequate participation of business unit representatives and escalate staffing issues to the highest levels of organizational management if not resolved.

Also, the relationship and structuring of the EA team, the EA Program Office, and the various EA governance bodies are important to the EA development and implementation. Figure 4.2.2-1 below, taken from the Practical Guide to Federal Enterprise Architecture [Reference 1], shows one fairly generic depiction of these relationships. It is important for these structures and relationships to be defined and understood as well as properly aligned to EA policy and guidance in the organization.

There is no substitute for direct involvement of senior, knowledgeable business executives and managers in the development of the “To-Be” business architecture.

15

EA Program Management Office

Business Line Organization

Architecture Core Team

Staff Organization

LegendEA Team

Chief Architect

Risk Management

Chief Information

Officer

Configuration ManagementEvaluation

Technical Review

CommitteeQuality

Assurance

Capital Investment

Council

EA Executive Steering

Committee

Agency Head

Subject Matter

Experts

Domain Owners

PC2000-3915-006a, 10/13/04

Figure 4.2.2-1. Typical Structural Relationship Between the EA Team and Other EA Governance Entities (From the Practical Guide)

4.2.2.3 Pitfalls to Avoid The following kinds of issues or challenges can be pitfalls:

Not attempting to involve senior executives and business area managers in the early stages of the EA Program, and continuing to keep them involved and abreast of the EA as it is being developed

Accepting anyone sent whether or not they fit the EA level of knowledge

Not reviewing the business strategy, goals, and the “To-Be” business architecture with senior agency executives and business area managers and obtaining concurrence prior to proceeding with undertaking substantial work on the data, applications, and technical architectures that can sometimes result in substantive changes to their business plans

Not accepting the fact that, when done properly, the EA will result in significant organizational change that will require the continued and ongoing support of both senior agency executives and business area managers.

In addition to the important team issues, the definition of the Architecture Process and Approach (See Section 4.3) also needs to be in place to support a mature EA Program.

16

4.3 Define an Architecture Process and Approach

4.3.1 Defining the Purpose, Scope, and Framing of the EA There are key decisions that need to be made by management before they move forward with their efforts to put an Enterprise Architecture Program in place. These include issues such as “What is the purpose of the EA, and, based on the identified management purpose, what is the scope and the framing for the effort?” Very often there is little or no real identification of integrated goals for the EA beyond that it is required by law and is required to show compliance with the Clinger-Cohen Act. However, there are valuable goals that can be achieved. For example, one cabinet Secretary stated that the EA is the transformational mechanism to create “One Agency … focused on its Customers.” In another case, a DoD major command, recently created to consolidate nine other subsidiary commands, noted that it is using the EA to set up a major systems and server consolidation that will help congeal the single command while also saving money and simplifying support. In both cases, the EA is seen by executive management to support not only technology ends but also cultural and organizational changes.

4.3.1.1 Applicable EAMMF Elements Stage 2, Attribute 2, “Provides Capability to Meet Commitment.”

4.3.1.2 Successful Practices

Understand the Purpose and Scope for an EA The purpose of Enterprise Architecture is assist managers in implementing change and improving the delivery of services through the more efficient use of a department’s or agency’s IT portfolio. It is therefore critical to link the EA to a specific purpose that fills a management need or void. It provides a much-needed focus and is a way to quickly gain traction and resources. For example, the OMB in its 2005 budget guidance, last year, talked extensively about using the EA as the mechanism for supporting and helping define ways to establish departments’ and agencies’ modernization efforts. This makes good sense because the EA should result in numerous initiatives that will greatly aid this overarching goal. Also, these initiatives, while often containing technology solutions and components, frequently involve process reengineering and revised business rules as well.

In another way, the EA can be used to more narrowly define a set of more singular goals linking to or focusing on specific mandates or objectives. These could include e-Government approaches, broad information dissemination, or even consolidations of technologies and infrastructures. There is nothing wrong with having a focused result of an EA being stated — while it is not a specified singular or normal outcome of an EA, it is, nonetheless, something that can capture the executive’s attention to ensure the appropriate EA support and the traction to put the EA Program in place. The above-cited technology consolidation would be such a stated outcome and a good example of this approach.

At the same time, the enunciation of a purposed goal will help put the EA Program on the map, not for its own sake, but rather to enable it to reach the appropriate audiences it must to cause the changes sought. Also, every EA in the Government has and will continue to increase the number of its interfaces to other EAs, be they for parent organizations or Federal Lines-of-Businesses or for other non-Federal Governmental EAs and stakeholders. Again, positioning the EA Program with a set of purposeful goals will further substantiate it as a useful and important mechanism for achieving the goals.

17

Clearly articulating the scope of an agency EA in relationship to the EAs of partnering agencies will go a long way toward focusing its efforts to those resources unique to it and not redundant or duplicative with partnering agencies’ Eas (see Figure 4.3.1-1). For example, there are natural “nestings” that occur across the Government where departments have agencies that have offices or programs. Under such a scenario, the EAs should be developed at multiple levels. To ensure that duplication does not occur, it is very important that a clear a hierarchy of how EA artifacts are inherited between hierarchical levels be defined. They define interface standards for how the hierarchal levels of the EA connect with each other. For example, we know that the FEA has pushed for the consolidation of Federal pay service centers and that these common services will be used across the civilian sector of the Federal Government. For such commonly supported services, there need not be separate unique definitions within the EAs of agencies. Unique definitions are only appropriate if there are aspects that are not covered by the services. Otherwise the interfaces, data models, and schemas of the pay centers should be inherited from the hosting agency. This is true across all departments where a service provider provides a set of common administrative and management services. The LOBs for HR and FM will most commonly affect EAs of all departments and agencies.

These EA definitions of common processes, data models, applications, and technology capabilities or interface standards should be viewed as being inherited by the receiving agency and therefore out of scope of their EAs. Lastly, there are increasingly specialized EAs that are being developed that take portions of other EAs to form a new or aggregated EA. Typical of this is a military taskforce, but it could equally apply to issues such as a medical emergency or a terrorist event.

Agency XAgency Z

Agency Y

Board or Commission Program

Site

Site

Region

Site

Program

Office

SiteRegionAdministration

Lab Bureau

Bureau

RegionOffice

Site

Federal Enterprise Architecture

SiteOffice

State

Agency XAgency Z

Agency Y

Board or Commission Program

Site

Site

Region

Site

Program

Office

SiteRegionAdministration

Lab Bureau

Bureau

RegionOffice

Site

Federal Enterprise Architecture

SiteOffice

State

PC2000-3915-004a, 10/12/04

Figure 4.3.1-1. The Relationships of Various Architectures for Planning an EA Program

This last category of EA is also one that most often would skirt and ignore important levels of Government that could have specialized knowledge or information that significantly impact the potential for successful implementation of an EA program. The need to effectively develop inheritance and common sharing of components and interfaces is also gaining greater momentum across Federal, state, Tribal, and local Governments. While the need is recognized, the

One of the lasting effects of EA is to enhance the common sharing of components and interfaces across the Federal, State, Tribal, and local governments.

18

mechanisms for sharing architecture definitions, models, artifacts, and other elements (standards) do not effectively exist and are just now being considered and created. The first step is recognition, and then collaboration. In many cases the EAs of all levels are not mature enough for the collaborations to meaningfully occur. In any case, mapping these inheritances and interface standards among the hierarchical levels is an important function that must be emphasized and will help focus the efforts to ensure the relationships are properly defined and captured.

To summarize, the careful scoping of an EA can enable it to be created more quickly with less redundancy and with a greater amount of leveraged parts. As EA is matured across the entirety of the public sector, there should be increasing linkages of EAs at the various levels, integrating Government horizontally and vertically. Scoping can enable great leveragability and, combined with proper framing of the EA effort, enable rapid completion and earlier impacts and returns on EA investments.

Framing the EA The framing and bounding of the EA Program and EA development efforts are significant to making progress. Many people consider this just a step in the overall scoping process for the EA and that is one reason why it is presented here, following that section. Whether a separate topic or within the scoping steps, the questions of how wide organizationally, how deep and detailed, and how fast the EA should be developed are all germane to framing the EA Program efforts. These answers make great differences to funding, staffing, and amount of progress and traction. In some instances, EAs fail because they are framed to tackle too much, too fast. In these cases, the EAs (teams) cannot cover all the things that need to be done. In a similar case, where too few resources chase too much work, they fall behind schedule and generally begin to flounder. Too often these efforts are sabotaged because there is a hidden agenda to make the EA fail, so an all-or-nothing mandate is sponsored. “Either we do it all or it isn’t worth doing” is often the statement from a nemesis of an EA approach.

Too often the framing of the EA development and the EA Program is oversold as to its potential impacts, which do not match the realities of support, structure, resources, or time frames. It is not an uncommon error to sell the benefits of EA based on its ability to provide immediate enterprise-wide benefits. Unless an agency is small, adequately funded, and has a unified chain of command, the ability to deliver on the promise in the near term is limited. The breadth and complexity of the issues facing EA are significant enough to ensure that progress will be slow and measured on the enterprise level. This leaves EA managers taking such an approach hard-pressed to answer the question of business managers: “What have you done for me today?”

One agency established a goal of saving $100 million dollars over 5 years and gets criticized every year by the IG because it has never established any mechanisms to measure the purported savings, direct or indirect, actual savings, or cost avoidances. This same agency was seriously under-funding its EA Program and therefore had no realistic chance at actual savings of this magnitude. It was rumored the Chief Architect slipped this metric into the strategic plan when no one was watching in hopes that it would support obtaining the proper funding necessary for the EA to start having a greater impact. The IG audits did result in more funding but not significant enough to conduct the real efforts for these levels of

The real impact of the EA is solely in its utilization by business managers, who expect measured results that match realities and expectations.

It is best not to oversell the EA program and its long-term benefits; instead, careful measurements need to be taken to evaluate the direct or indirect savings.

19

results. There have to be realistic targets that are incremental and attributable to the EA and, as with all programs, an EA Program must be supported to achieve results.

This can be mitigated by selling EA “retail” by seeking out business managers who have business needs that can be addressed with some immediacy by a vigorous EA program. EA can grow and over time become increasingly effective, helping make progress on various initiatives that without architecture would not be as well defined or integrated. It can be effective, for example, to bind the EA efforts to common functions across an enterprise or agency as a partial framing to make concrete progress. One major cabinet agency did precisely this to define its corporate EA, which was then inherited by most of its component programs (except for those who were by law semi-autonomous). Framing the EA on a smaller target to show traction and to educate, as well as make concrete progress towards the overall EA, can be an effective approach. There are even ways that parts of an EA can be done as portions of actual project implementations. An infrastructure WAN analysis can support defining a portion of the technology architecture baseline. A security review and inventory of all major systems can support the physical server, technology, as well as applications architectures baselines.

At an EA conference recently, a major automaker’s Chief Architect explained how that corporation used a worldwide server consolidation effort to populate the information of about four cells within the Zachman framework. While this was not difficult to recognize, it does imply an important fact that seems to work in two ways. First, the information in the cells was important to answering a critical question on a major business decision — how and where to consolidate servers. That information, part of the architecture baseline, could be captured as a part of an analysis required to meet a business need, saving operational dollars. It also showed that even partial population of the EA can help support real decisions (which was a point also made above about the purpose and focus of the EA). Often there is enough detail to produce results and support decisions without populating all cells, models, artifacts, or parts of the EA to the nth degree before impacting decisions.

4.3.1.3 Pitfalls to Avoid There are a number of pitfalls to be avoided in establishing the EA purpose and in scoping and framing. These include:

Making the purpose of the EA Program so narrowly focused that it cannot mature to be an enterprise architecture but remains a technology plan or a systems architecture.

Ignoring the necessity of developing and nurturing the appropriate governance structures among all of the hierarchical EA stakeholders required to ensure compliance with the common processes, data models, applications, and technology capabilities.

Trying to scope the EA too widely or across to disparate business units with not much in common or, conversely, trying to implement a full-blown EA approach on an organization that is too small. It is important to find the reasoned level of EA scope and to properly nest EA efforts effectively.

Trying to frame an EA as a “do all,” “be all,” and “achieve all” mechanism that will accomplish unrealistic goals that wouldn’t be achievable even if the EA were world-class. The framing and maturity of the EA Program and resultant plans need to grow and not try to exceed reasonable expectations given funding and support.

The proper and innovative purpose, scope, and framing of the agency’s EA Program and its resultant EA(s) can impact the achievement of maturity and will be critical in gaining support, attention, and

20

traction required to make progress towards the EA becoming fully used and impacting management practice.

4.3.2 Establishing an Approach to Enterprise Architecture Establishing an approach to enterprise architecture used to mean that an agency was going to attempt an EA, without much in the way of pre-planning, awareness, or organizational preparedness. This is no longer the case, and now there are a number of considerations that bear on the approach used to formulate and implement an EA Program in an agency. As noted by the GAO in its Enterprise Architecture Management Maturity Framework1 (EAMMF):

“At Stage 1, either an organization does not have plans to develop and use an architecture, or it has plans that do not demonstrate an awareness of the value of having and using an architecture. While Stage 1 agencies may have initiated some EA activity, these agencies’ efforts are ad hoc and unstructured, lack institutional leadership and direction, and do not provide the management foundation necessary for successful EA development as defined in Stage 2.”

The following considerations for establishing an approach to EA can greatly assist in addressing the EAMMF Stage 1 elements, in providing a structured approach that garners executive leadership, and in getting a successful EA Program in place. These include:

Developing a Marketing and Communications Plan

Developing EA and Business Metrics Early.

4.3.2.1 Develop a Marketing and Communications Plan The Practical Guide2, used by the GAO as the basis for its EAMMF, describes the purpose of the marketing strategy and communications plan to “... keep senior executives and business units continually informed and to disseminate EA information to management teams.” A successful Marketing and Communications Plan can go beyond disseminating information; it can provide the agency with a powerful two-way communications vehicle for soliciting and disseminating feedback from, and fostering the development of, a unified, agency-wide EA team with a strong sense of ownership. This can go a long way towards reinforcing the commitment of program participants and stakeholders, thereby enhancing the likelihood of success.

4.3.2.1.1 Applicable EAMMF Elements Stage 1, “Creating EA Awareness.”

4.3.2.1.2 Successful Practices Successful Communications and Marketing plans include the following practices.

1 GAO Executive Guide, INFORMATION TECHNOLOGY, A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1), GAO-03-584G, April 2003 2 Practical Guide to Federal Enterprise Architecture, Volume 1.0, CIO Council, February 2001

A successful marketing plan can provide a two-way communications vehicle for fostering the development of a unified message from the EA team.

21

Promote and Publish EA Success Stories Plans should emphasize promoting and publishing EA success stories throughout the organization. This is particularly important during the startup phase of an EA Program, when participants struggle to find direction, make progress, and, above all, see results. Early successes build team confidence in the EA Program and accelerate buy-in and support by team members. It is also important to use team members who are the recipients of these early successes to serve as your advocates to sell the value of EA to their colleagues. Outcomes such as achieving upper management sponsorship and/or approval and support, as well as getting the team formed and holding the initial meetings, should be recognized and promoted as successes. Each event along the detailed EA Program Management Plan schedule should be scrutinized as to its value towards communicating progress.

Solicit Feedback and Act on Recommendations EA team members who are actually doing the work develop excellent insights into what is working and what is not. Soliciting feedback from team members allows the EA Program’s management to tap their reservoirs of insights. Furthermore, team morale and enthusiasm increase when management responds to the feedback and publishes it with their response in communications vehicles such as an EA newsletter. Often this approach works equally well for other agency staff outside the EA team, at least in the form of questions and answers.

Many staff in the agency will be curious about what the actual outcomes or results of the EA could, should, or may be and how it could affect them. Allowing these kinds of questions up front, and directly addressing them, helps to ensure that the EA is not seen as something other than what it is. Most importantly, the CIO, the Chief Architect, and or/the EA Program Management Office need to carefully consider and make decisions on recommendations and EA governance issues, and communicate them consistently.

Set Realistic Expectations and Manage Them Through the EA Life Cycle Since the need for developing an EA is still a relatively recent requirement in the Federal Government, the purpose for it and the outcomes and impact of an EA are not usually well understood within most agencies. As a result, stakeholder expectations can vary widely across the organization. Successful communications and marketing plans can help set realistic stakeholder expectations, and ensure that their expectations are managed. This can be particularly true with respect to the potential EA impact on individual business units. For example, agencies with labor unions need to ensure that the union officials realize that the EA is not a mechanism focused on downsizing or outsourcing outcomes per se, although these are management considerations that are often in play, irrespective of the EA and its transition plans.

Tie EA to Impact on Employee Opportunities An EA Program may result in many changes to an agency, including new or optimized processes and/or implementation of enabling technologies. Often these changes can translate into career opportunities for employees. EA management can energize employees by publishing articles on the expected changes and the opportunities that are opened up, particularly when coupled to training opportunities. For example, the implementation of physical plant security cameras may require a new function to manage the processes associated with indexing and storage of the various recordings and their collation to and cross-checking with other security records. This could be a new position created as a byproduct of the EA process, something like “video guard.” Another example is in the area of computer security enhancement, where

22

significant numbers of system administrator roles and opportunities have opened. It should be cautioned that not every EA initiative would have such easily identified new opportunities. It must be understood that some employee dislocations may occur that cannot be mitigated and that more damage will be done in the end by denying their potential effects.

Review and Update the Marketing and Communications Plan The communications needs of an EA Program evolve and change throughout the life of the program. During the startup phase, EA messages are aimed at explaining the program purpose and scope, outlining the expected outcomes, providing examples of EA Programs at other agencies, and, above all, answering questions. As the program evolves, EA marketing and communications focuses increasingly on progress achieved and issues encountered. Also, the focus will be on soliciting feedback from participants, reporting on positive impacts on business units, and discussing process and technology changes as well as associated training opportunities. Marketing and Communications Plans should evolve to provide for changing requirements and use appropriate media to disseminate the resulting messages. Media can include:

Hard and softcopy newsletters

An EA portal

Various EA Program roadmaps and drawings

Focused awareness briefings

Awareness sections in process training for new employees and managers.

4.3.2.1.3 Pitfalls to Avoid There are two major pitfalls in developing and deploying Marketing and Communications Plans:

The first pitfall is using new communications media that employees do not know well, or do not use commonly, and/or the use of media that require employees to find (“pull”) information on their own, e.g., by visiting a Web site, instead of being sent a pointer to the information (e.g., a URL) in a weekly e-mail.

A second common pitfall is over-dependence on written messages, without adequate face-to-face communications from the executive sponsor, the champions, and the EA team leader, EA Program Manager, or Chief Architect. This has the effect of allowing questions that, if not answered in a timely manner, begin to fester and often create a counter current or drag of rumors and false assumptions about the EA and its potential impacts.

4.3.2.2 Develop EA and Business Metrics Early The importance of identifying specific EA and business-related metrics early on cannot be overstated. As the EA progresses there will be a need to quantify the impacts and results. Establishing the formulae for attribution of various cost savings, avoidances, and various levels of business results to the EA and its implementation is critical to the long-term success and ability of the EA to actually transform the agency’s business.

Linked EA business metrics and IT metrics established in a PRM line-of-sight manner are critical to showing EA Maturity and impacts.

23

4.3.2.2.1 Applicable EAMMF Elements Stage 2, Attribute 4, “Verifies Satisfaction of Commitment.”

4.3.2.2.2 Successful Practices In the area of establishing value propositions for an EA, there is a long way to go in terms of research and capturing of actual use cases and associated value models and metrics. While there are success stories in both Government and industry, in particular the manufacturing arena is where many innovations in cost benefits of EAs and their resultant impacts on things like common standards, tools, infrastructure, and methods have been substantial. Automobile manufacturers, package shipping companies, banks and financial institutions, and retail services and sales business areas are all full of EA success stories. From some of these come tips that should help guide the establishment of EA metrics. In these business areas the line-of-sight tracking from EA enabled IT solution metrics to business outcome metrics is well understood. The OMB FEA PRM has explained how this mapping should be done in the Federal sector. Figure 4.3.2.2-1 below gives an example of how this can be done and how it relates to the EA layers or sub-architectures.

Line of Sight — FEAProcess Linkage to EA

Valu

e

Secure the Homeland

OutcomesOutputsInputsCause

and Effect

Cause and

Effect

StrategicOutcomes

Less crime and violence

What How

Business Results

Individuals wishing to

enter U.S. at Border

Inspection Station

Who How

Customer Results

Background checks

Number of background

checks

What How

Processes and Activities

Automated Commercial Environment

What How

Technology

ATLAS

NICS

Firearms Integrated

Technology

Percentage of attempted

systems penetrations

avertedMaintenance

costs as percentage

of total costs

Food inspections

Vehicle searchesWeapons

checks

Number of food

inspectionsIndividuals subject to weapons checks

Individuals subject to

background checks

Percent satisfied with

border inspections

Number of complaints

about border inspections

Safer food

Percent of health

incidents attributable to illegally imported

food substances

Percent of internal users

satisfiedPercent of

system downtime

Number of vehicle

searchesNumber of weapons checks

Percent of crimes

committed using

illegally imported weapons

Average wait time at Border

Inspection Station

Technology Architecture

Service Components (Applications) Architecture

Data and Information Architectures

Business andPerformance Architectures

Line of

Sight

Line of Sight — FEAProcess Linkage to EA

Valu

e

Secure the Homeland

OutcomesOutputsInputsCause

and Effect

Cause and

Effect

StrategicOutcomes

Less crime and violence

What How

Business ResultsBusiness Results

Individuals wishing to

enter U.S. at Border

Inspection Station

Who How

Customer ResultsCustomer Results

Background checks

Number of background

checks

What How

Processes and ActivitiesProcesses and Activities

Automated Commercial Environment

What How

TechnologyTechnology

ATLAS

NICS

Firearms Integrated

Technology

Percentage of attempted

systems penetrations

avertedMaintenance

costs as percentage

of total costs

Food inspections

Vehicle searchesWeapons

checks

Number of food

inspectionsIndividuals subject to weapons checks

Individuals subject to

background checks

Percent satisfied with

border inspections

Number of complaints

about border inspections

Safer food

Percent of health

incidents attributable to illegally imported

food substances

Percent of internal users

satisfiedPercent of

system downtime

Number of vehicle

searchesNumber of weapons checks

Percent of crimes

committed using

illegally imported weapons

Average wait time at Border

Inspection Station

Technology Architecture

Service Components (Applications) Architecture

Data and Information Architectures

Business andPerformance Architectures

Line of

Sight

PC2000-3915-005c 10/14/04

Figure 4.3.2.2-1. The Line-of-Sight PRM Mapping of Metrics from the Technology to the Business Outcomes

24

Establish Complementary IT and Business Metrics The EA will begin to spin off specific transition plans and projects aimed at consolidating, improving. or making various business functions more efficient or effective. It is critical that the metrics related to both the IT and the business process are established early on and that the relationships between the two are understood. This will enable the tracking and recording of the data required to report results and that later will be used to determine if the ROI or cost/benefits have, are, or will soon be achieved. It is too late to start thinking about establishing metrics after the investment has been made, the technology has been installed, and it is being tested or is in production. Examples of this are found in many transaction-based implementations where the relationships between transaction efficiencies and frequencies are directly translatable to bottom line calculations. While these are typically found in private sector models, similar situations can be established in the public sector to demonstrate cost avoidance or new efficiencies or capabilities. The IRS implementation of online forms is such an example. The development of online applications for many processes, approvals, licenses, grants and subscriptions would also be similar. The Performance Reference Model3 is a valuable source of information and guidance that will aid greatly in the formulation of closely linked EA, IT, and Business metrics.

Establish EA Program Impact Metrics The impacts of the EA Program and the direct utilization of the EA itself should have metrics for the various components and parts. For example, the Architecture information repository should track the actual utilization of the information, by whom and when. These uses can be translated into outcomes such as lowered opportunity costs and cost avoidances. The reuse of the functional business model for reorganizations and various management analyses is another example. The data model and its planned reuse of data objects and the consolidations associated with reuse is another feature of the architecture where direct cost avoidance can be measured and established. The ability to produce these metrics may prove critical to maintain EA Program momentum and substantiate progress and impacts. This is especially true for IG audits and GAO reviews. It is also required input into the EA Program Exhibit 300 business case. Establishing a set of criteria for capturing this kind of data and routinely capturing it will assist with formulation of a good set of inputs to be used in ROI and cost benefit calculations. It will also assist with net present value assessments and as inputs to EA Project Management Earned Value Calculations, as required.

EA and EA Program Maturity Measurement Both the GAO and the OMB have put forth mechanisms over the past months that are very useful in assessment of an agency’s EA and EA Program. The GAO EA Management Maturity Framework (EAMMF), described in greater detail in Appendix A, is a fairly comprehensive measurement for the relative maturity of the core elements that compose an EA Program at an agency. While there are issues with how the scoring is done and whether missing one criterion should reduce an entire level of maturity scores, the specific criteria and their relative sequence still offer a good set of checkpoints for assessment of the capability of an agency to produce and use and EA.

3 Performance Reference Model (PRM) Version 1.0 Release Document Volume I and Performance Reference Model (PRM) Version 1.0 Release Document Volume II, FEAPMO, Office of Management and Budget, September 2003

It is important to conduct self-assessments of the EA maturity level of your organization on a periodic basis as it relates to the agency’s IT and business decision-making.

25

On the other hand, the OMB EA Assessment Framework (EAAF) for an agency’s self-assessments offers a different focus, looking at the agency’s EA itself and how the agency is or is not utilizing it in the context of IT and other decision-making. The self-assessment scoring is fairer, in some ways, than the GAO EAMMF, but also has its flaws. The means of complying with the various criteria in the self-assessment are not always clear and specific. There are certain criteria that are relatively new and how to relate or judge them is not a straightforward task. In certain areas the self-assessment depends greatly on individual understanding and subjective decisions as to compliance. It takes a relatively experienced and knowledgeable expert to do the assessment and have it accurately reflect the agencies actual maturity. Both of these maturity frameworks are useful in measurement of the EA Program or EA and no doubt they will be further evolved to clarify and resolve previous issues or perceived flaws.

Define Quality Metrics EAMMF 1.1 has added requirement for measuring and reporting quality metrics as a Stage 4 element. The following types of metrics using a balanced scorecard approach can be used as candidates for measuring the quality of an EA:

Business value added (to/by organization) by the EA

Completeness of the EA

Correctness of the EA (Note: This is not very clear and can generate major debate)

Usage of the EA (by the elements of the organization).

These metrics, as well as suggested measurement techniques, are discussed below.

Business Value Added by the EA These metrics measure the benefits accruing to the organization by using the EA, and answer the basic question; “Is the business case being validated?” Examples of benefits resulting from an EA include:

Reduction in total cost of ownership (TCO)

Improved or increased services to citizens

Greater efficiencies and effectiveness in processes

Lowered cycle times

Increased quality of information, products or services

Other areas, including using it for human resource planning (such as in attracting and retaining competent personnel), for strategic planning, and /or for performance and process improvement and re-engineering.

A challenge in establishing these metrics is capturing the benefits resulting from the use of the EA, versus, the way that changes would have been made in the absence of the EA. One approach is to track the costs/benefits of EA implementation plan projects that transition the organization to target architecture, and to compare this against the estimated costs/benefits for changes made without exploiting EA identified features.

26

Completeness of the EA Suggested completeness metrics include such factors as the degree to which the EA covers each business area within an organization (e.g., Management and Administration, mission-critical areas), as well as the degree to which the EA covers all of the required EA views (e.g., business, data, applications, technology, and security). The following approaches could be used for establishing these metrics:

Coverage of business areas

− Identify business areas, select scoring criteria, attributing level of mission criticality of each business area

− Score degree to which EA addresses needs of each business area (e.g., 1 to 10) and calculate composite score

− Use the BRM, with its Lines of Business and Sub-functions, to map the organization’s business area and identify the completeness of the BRM’s coverage, as a minimum.

Coverage of required views

− Identify required views/sub-views

(e.g., cells in the Zachman matrix, FEAF views)

Select scoring criteria

− Score degree to which EA addresses each required view, calculate composite score

− Compare against perfect score, assign grade.

Correctness of the EA This metric measures the number of “substantive” errors/deficiencies found after EA has been released. In order to measure this metric, track the number and type of change requests applied to the EA, and classify them into technical versus editorial change requests. Measure the number of technical deficiencies that require fixes to the EA, and compute the weighted sum based on assigning severity levels to deficiencies (e.g., High severity = 10, Low severity = 1). It should be noted that this is a rather controversial approach, as it often requires subjective interpretation as to what is an error or deficiency. For example, is an agreed upon revision to a data category an error or deficiency? If it changes again in a month is that another error or deficiency?

Usage of the EA by the Business Units of the Organization These measures include two factors: (1) the degree to which business units are using the EA for IT planning and procurements, and (2) the accessibility of EA data/artifacts. Suggested measurement techniques for these two factors include:

Usage

− Track business units using EA information in the organization to make management decisions regarding the business unit and the IT portfolio supporting it operations

− Define usage scores from Excellent = 10 through None = 0

− Assess usage of the EA by each business area, calculate weighted score.

27

Accessibility

− Track and score the ease with which users can find and apply current, up-to-date EA data/artifacts (e.g., online access in a repository = 3, distribution of physical storage media = 2, hardcopy distribution = 1)

− Hits in various areas of the online repository to support daily operations.

In terms of the EA being utilized by the business units, it is of paramount importance that the relationship of the EA in support of strategic vision, linked to and measured as contributions to meeting specific business objectives and mission goals is explicitly demonstrated and documented.

4.3.2.2.3 Pitfalls to Avoid It is important to avoid the following EA measurement and metrics pitfalls:

Failing to identify and collect the data that can substantiate the impact of the EA on the enterprise and its business processes.

Collecting cycle time and statistics relative to the supporting technologies but not making it relevant to the business improvements (line-of-sight linkage). Establishing relevancy may take some translation and often the relationships are not explicit. This is particularly true with IT infrastructure and the associated metrics. Use of the PRM will help.

Not providing anecdotal evidence required ensuring the proper understanding and translation of various IT metrics. For example, network outages on a weekend may go unnoticed until that happens during the mass transfer of timesheet data to a pay service provider who cannot cut the checks because of the outage. The fact that often this transfer happens on weekends during non peak times makes the network outage statistics for 7 days a week relevant.

Not making sure that all metrics are understood, translatable to the business and appropriate for showing the effects of the EA.

Establishing cost savings before an analysis is done to appropriately establish reasoned and achievable targets, over reasonable time frames.

4.3.3 Plan the EA Program The development of a formalized program plan for the EA is a demonstrated key success factor. The November GAO report stated:

“For fiscal year 2003, OMB required department and major agencies that are CIO Council members to address how IT investment decision making incorporated architecture alignment and, for agencies that do not have architectures, to provide a plan for developing one.”

Planning an Enterprise Architecture program requires building a foundation that focuses on implementation of roles and responsibilities, defining the scope of the architecture effort, and providing the necessary resources to effectively develop the architecture products. Activities for planning an Enterprise Architecture program are discussed in detail in the Practical Guide (Section 3, Initiate Enterprise Architecture Program; and Section 4, Define an Architecture Process and Approach). There are also means of getting copies of other agencies’ program plans that can be very helpful in planning EA.

28

The Chief Architect’s Forum has discussed starting a repository that could be tapped to find sample EA Program Plans. Also, a number of the former U.S. Customs Services EA Program planning artifacts are highlighted in the Architecture Alignment and Assessment Guide (AAAG), as Revised, August 2001.4

4.3.3.1 Applicable EAMMF Elements Stage 2, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.3.3.2 Successful Practices Four important planning activities are discussed here, with examples of successful practices from active Enterprise Architecture programs. The planning activities are:

Establish the Management Structure

Specify Enterprise Architecture Scope.

Establish the Management Structure A key to having an effective and business-aligned EA effort is to provide an EA management and governance structure that ensures and maintains visibility into the EA process across leadership and management functions. Business area management oversight of the EA process ensures alignment with the mission, vision, and business strategy of the agency. If an appropriate governance structure does not exist, then oversight boards and steering committees, with executive participation, must be implemented as the first, and highest priority for the EA effort. Without proper oversight and support, all subsequent EA efforts are doomed to failure. Stakeholders must see from the beginning that support for the EA has buy-in from the highest levels and that structures are being put in place to ensure their voice is heard on issues impacting them.

This approach was used at the DOE sub-agency level, resulting in ongoing sponsorship throughout the organization for the EA process. The approach to establishment of the governance bodies as implemented at the U.S. Customs Service is also described, as an example, in the AAAG. Figure 4.3.3-1 depicts the governance structure for the EA recently approved at a Cabinet Department. It shows both the organizational components as well as the committees and the focus areas and roles of the five subcommittees in the shaded areas at the bottom (from left to right, shaded as and in the order that they appear in the chart).

In Figure 4.3.3-1, the MRB is the senior executive assistant secretary level management review board which more often than not just validates the decisions made by the TRB, or the technical review board. In turn the TRB most often endorses the efforts or decisions made within the various subcommittees. The various roles are also identified for each of these subcommittees. In this particular agency, the Assistant Secretary for Administration and Management (ASAM) retains the additional role as the agency’s CIO.

4 Architecture Alignment and Assessment Guide, CIO Council, Revised August 2001

29

Validates Business casesEstablishes Integration across Processes Monitors Quarterly ReviewsEarned Value Mgmt.

New and Enterprise-wide Systems

Conceptual DesignPolicy Planning Business ModernizationEA Configuration Mgmt. and Approval

Technical StandardsTRM Change Mgmt.Baseline MaintenanceVersion ControlTechnical Review

Security Integration across all levelsReview Security StandardsSelect or Approve Security Technologies

Enterprise Architecture

Subcommittee

IT Architecture

Subcommittee

EA Program Office

Deputy CIO

ASAM and CIO

Security Office

CapitalPlanning

Office

Advice, Counsel, and Support

IT SecuritySubcommittee

Capital Planning

Subcommittee

TRB

Configuration Control

Subcommittee

MRB

PC2000-3915-007b, 1/17/05

Figure 4.3.3-1. Example Governance Structure

Specify Enterprise Architecture Scope Although overall goals and objectives of the Enterprise Architecture effort are typically established very early in the program, some additional scoping is often important as part of the planning phase. Specifically, scope definition considerations should cover the following:

Relative emphasis and balance between business and technology aspects

Relationship between business and technology drivers

Scope and depth of “As-Is” architecture definition

Scope and breadth of “To-Be” architecture definition

Scope and depth of architecture transition plans and how they will be translated into the CPIC portfolio

Relationship of the EA Program to the other major processes (CPIC, SDLC, and Security).

Depending on an organization’s unique requirements, different emphasis may be needed between business and technology (data, applications, or service components and infrastructure) aspects of the architecture. For example, focus on technology considerations may hinder progress in an organization requiring significant business transformation (e.g., it may not be necessary to develop a fully attributed logical data model to adequately describe the business model for the enterprise, or to develop a physical data model where significant system architecture effort

Develop the “As-Is” architecture baseline only to the level necessary to determine which areas of the EA need further definition to address agency goals.

30

is required in a later life-cycle phase). Similarly, the effort required for documenting the “As-Is” systems must be considered in terms of its value in a business-transformation driven architecture effort.

In this example, it may be more appropriate to defer extensive “As-Is” documentation to a transition phase to ensure appropriate emphasis and resources are applied to the transformed business definition in the Enterprise Architecture development phase.

As an example of a successful practice, DoD has consistently emphasized the business transformation focus of their architecture, with technology being an enabling component. DoD has also explicitly required definition of the Business Enterprise Architecture (BEA) business and technology views in terms of “As-Is,” “To-be,” and the supporting transition process. To avoid excessive resource commitment to the “As-Is” analysis, the DoD required the Enterprise Architecture contractor to develop a recommendation of the level of detail required for the “As-Is” product specification. If much of the installed base of technology will be replaced as an end result of an EA, then documentation of it in excruciating detail is certainly a waste. A rule of thumb is to develop the “As-Is” as necessary for transition planning, but no more.

4.3.3.3 Pitfalls to Avoid Some of the pitfalls associated with planning the EA Program are:

Failing to include the business units in the formulation of the management structure or not negotiating the various roles so that there are clear areas of responsibility and focus. If the various governance groups do not understand their roles they will compete and potentially contradict each other.

Not recognizing the needed contribution of all of the business areas and their respective contributions to the agency (or higher level) architectures in terms of the program plan. It is important that the requisite resources, training, staffing and tools for them be recognized within the consolidated EA Program plan, irrespective of what model the agency is following to achieve its EA (federated, confederated, or centrally managed top-down).

Allocation of too much emphasis on the baseline architecture up front and not allowing some degree of completeness of the EA because of it, even if shallow in some areas. It is important that the target and transition plans for the EA get done and that the agency doesn’t get wrapped around the axle on its codification of the baseline in excruciating detail. This means the program plan should provide for cycles of architecture development and update.

No program plan ever completed was perfect, so make your plan and work on it, revising it as you learn from its use.

4.4 Develop the Enterprise Architecture and Sequencing Plan

4.4.1 Recognize and Leverage Thought Leadership Developing an EA is greatly facilitated by a “thought leader.” This is a person or people with the vision to understand the overall purpose and needs of the enterprise and who can envision a way to embody it in a practical, working architecture.

31

4.4.1.1 Applicable EAMMF Elements Stage 3, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.4.1.2 Successful Practices Successful EA (development and implementation) programs have used the following thought leadership practices.

Identify the Thought Leader(s) The thought leader may be the CIO, or organizational head, but often those people are not able to devote the amount of time and attention required. The thought leader may be the project manager, technical team lead, or the chief architect on the project. Or, a thought leader may emerge from unexpected places within the project. Since this is not an appointed position by that title, an agency should be prepared to recognize and nurture a thought leader (or leaders) when they emerge.

A thought leader is someone who is respected throughout the organization for their leadership abilities, and who becomes the “go-to” person for explanations or problems. Thought leaders are able to explain the vision and purpose of the EA to all levels of stakeholders and “sell” the concept. Ideally, a thought leader should be someone with a background in organizational development. A successful thought leader will understand the technical as well as business needs of all elements of the organization, often through years of experience within the agency. This person or these people have the ability to keep track of the myriad details that a comprehensive EA incorporates, without losing track of the big picture. EA thought leaders are often created or identified by products of a previous architecture effort either at a lower level within the agency or at another agency.

Identifying a thought leader is not always a simple task or a matter of deciding to appoint someone to the position; it may require allowing one to emerge. Developing an EA can succeed without a thought leader, but the presence of one will often greatly increase the chance of success.

Provide Appropriate Training Thought leadership is not something that is easily taught. However, training can be provided that helps recognize emerging thought leaders, nurture their development, and use their talents. This may be included as part of project management training, personnel leadership training, or other suitable forums. Currently, there is no formal certification for thought leaders, so mangers may need to be given other tools to identify them. There are a number of tests, like the Myers–Briggs, that may help identify thought leaders that typically come from a few selected sets of personality types and profiles. Also, the recent emphasis by the OMB regarding the qualification of Project and Program Managers and their being certified should not be lost when considering leadership for developing the EA.

4.4.1.3 Pitfalls to Avoid Some of the common pitfalls related to thought leadership that should be considered and avoided if possible include:

Assuming that the thought leadership must or will come from the CIO or agency head. Often it will come from someone more fully involved with the project or even someone from an involved business unit.

32

Failing to recognize a thought leader when one begins to emerge. Often the thought leader is not a vocal or aggressive person, and must be encouraged and nurtured.

Discouraging thought leadership from more than one person, if necessary. When a group or committee is developing a common vision, then no individual leader may be required.

Initially trying to assign a thought leader as a role to anyone who will take it or whom is available. Unless someone has previous experience and has previously shown visionary skills, asking or assigning them to act as a thought leader or lead architect may not produce the desired result.

Believing that thought leadership is too nebulous to define or recognize and ignoring the value it can or could bring to the EA efforts.

4.4.2 Developing the Enterprise Architecture This section focuses on the development of EA within an agency and provides examples of successful practices that have worked well to raise the agency’s EA maturity.

4.4.2.1 Development of EA Requirements The development of a full set of EA requirements is a large task and can be a difficult undertaking depending on the size and scope of the effort. The general consensus is to develop a core set of products that is guided by external legislative and regulatory requirements and then incrementally improve these products over time. A key regulatory driver for the EA is compliance with the OMB Circular A-130. This document provides specific guidance as to how an EA Program should be set up and each of the EA deliverables created over time.

As a general guidance, the requirements for the EA Program within an agency should address the following issues:

Align technology investments for systems and infrastructure to the agency’s mission and goals

Systematically engineer systems to integrate and interoperate within the internal and external environment

Efficiently manage the implementation of emerging technologies

Provide a comprehensive reference list of the information technology assets throughout the enterprise

Provide ongoing knowledge management and information sharing to ensure that applications and communication mechanisms are kept current.

4.4.2.1.1 Applicable EAMMF Elements Stage 2, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.4.2.1.2 Description of Successful Practices To ensure that the EA is planned with a fully compliant approach that encompasses all legal and regulatory requirements, it is important to review and fully understand the significance of existing

Abiding by Federal guidance documents such as the OMB Circular A-130 helps in structuring EA requirements to external agency mandates.

33

legislation and regulatory requirements, which are extensive. It should be understood that while they all are important, not all can be implemented at once. An agency’s implementation strategy will depend upon business need, and resource availability. A successful practice would be for each agency to codify the following core set of elements in their EA requirements for both the “As-Is” and “To-Be”:

Business Processes — Identify each of the key business processes that support the agency mission and objectives and codify it in a structured manner.

Information Flows — Organize in a structured manner, information that is utilized by the agency, the information flows that indicate where it is needed and how it is being shared.

Applications — Identify systems and applications that are resident within the Agency that automate and manage the business processes and information activities.

Data Descriptions and Relationships — Organize common data elements that are used throughout the agency and identify how the data is created, maintained, accessed and stored.

Technology Infrastructure — Organize and store in a visual manner, the agency technology infrastructure that includes the network and communications, and hardware and software of each system.

Technical Reference Model — Provides a general framework on how technology is used throughout the agency, a strategy for technology refreshment and how new technology is inserted into existing programs.

System Standards Profiles — Align each technology investment within an agency to make sure that common technology standards are being implemented throughout the organization.

Information Assurance — Describe the information security controls and services within the EA products and deliverables.

4.4.2.1.3 Pitfalls to Avoid Since collecting EA requirements is an ongoing activity, a number of agencies have incurred the growing pains of trying to collect a massive amount of information from each of their departments. Pitfalls to avoid include:

Each department using its own set of tools with no commonality in transferring information from one repository to another. This can be avoided through better coordination and a plan towards aggregating the information in a common repository.

Anticipating legislation or new regulations and building them into the EA planning before they are “officially” released. Many agencies considered including various aspects of the Data Reference Model in its earliest version, which has been significantly revised and has still to be “officially” released in any form. This can be messy because the finally released regulation can be different enough to cause significant issues.

4.4.2.2 Development of “As-Is” Architecture The development of an EA requires the agency to explicitly describe and document the current and desired relationships between the business process and information technology. By

If the current or “As-Is” state of the organization’s EA is documented thoroughly, then the vision for the target or “To-Be” state is easier to achieve.

34

documenting the current “As-Is” state, the EA helps define the organization’s principles and goals on such issues as interoperability with external systems, compliance with Government mandates, and traceability to end user needs. When the current state is defined, the EA then provides a strategy on how the agency can develop a roadmap that will support its current state and allow effective transition to the target environment. The transition process includes the agency’s capital planning and investment control processes, agency EA planning processes and the agency systems life-cycle methodologies.

Figure 4.4.2.2-1. The FEAF Depicts the Major Generic Components of the EA That Are Required

The Federal Enterprise Architecture Framework (FEAF) depicted in Figure 4.4.2.2-1 shows the major parts of the EA including the “As-Is” state and the other parts mentioned above.

4.4.2.2.1 Applicable EAMMF Elements Stage 3 and 4, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.4.2.2.2 Description of Successful Practices It is understood that it is difficult to fully grasp and document an agency’s current “As-Is” architecture. Certain agencies such as the Department of Defense have been engaged in this activity for a long time. A successful practice that has emerged is to adopt elements of the Federal Enterprise Architecture and mold it towards each of the agency’s mission and information requirements.

The “As-Is” architecture documentation can be separated into the four areas: business architecture, data architecture, applications architecture and technology architecture. These four elements then need to be evaluated based on the current OMB Federal Enterprise Architecture Reference Models (See Figure 4.4.2.2-2): the Business Reference Model (BRM), the Performance Reference Model (PRM), the Services Reference Model (SRM), the Technical Reference Model (TRM), and the new Data Reference Model (DRM).

35

Regulatory Management

Support Deliveryof Services

Policy and Guidance Devel.Public Comment TrackingRegulatory DevelopmentRule Publication

Knowledge MgmtCRMContent MgmtCollaborationSearchPortalPersonalization

BusinessReference Model

( BRM )

Rule Publication

Service ComponentReference Model

( SRM )

Technologies

PlatformsJ2EE.NETWindows NT

Data MgmtODBCJDBC

Business Logic

TechnicalReference Model

( TRM )

Performance Reference Model (PRM)Outcomes, Measurements, Metrics

Business lines and functions

Supporting technologyand standards

Enabling capabilities, components, and services

Component-Based ArchitectureService Layers Service Types Service Components

Data and Information Reference Model (DRM)Classification, Categorization, XML, Sharing

Regulatory Management

Support Deliveryof Services

Policy and Guidance Devel.Public Comment TrackingRegulatory DevelopmentRule Publication

Knowledge MgmtCRMContent MgmtCollaborationSearchPortalPersonalization

BusinessReference Model

( BRM )

Rule Publication

Service ComponentReference Model

( SRM )

Technologies

PlatformsJ2EE.NETWindows NT

Data MgmtODBCJDBC

Business Logic

TechnicalReference Model

( TRM )

Performance Reference Model (PRM)Outcomes, Measurements, Metrics

Business lines and functions

Supporting technologyand standards

Enabling capabilities, components, and services

Component-Based ArchitectureService Layers Service Types Service Components

Data and Information Reference Model (DRM)Classification, Categorization, XML, Sharing

Figure 4.4.2.2-2. The FEA Reference Models and How They Work Together in an EA Context

Alignment with the BRM — The OMB BRM illustrates an overall set of business functions that is applicable for all Federal agencies based on their services to citizens. However, at the sub-agency and department level, it is important for each agency stakeholder to codify their business missions and goals and extrapolate how it fits into the overall agency and Federal business functions. The BRM can be used to streamline existing agency business processes and identify critical business information flows. It is important to create a visual guide of this information to ensure that process diagrams and business relationships can be easily retrieved and disseminated.

Alignment with the PRM — The PRM creates a framework for performance measurement that provides common outcome and output measures throughout the Federal agencies. Agencies should create their own set of performance measures for how the “As-Is” architecture should be documented. This “As-Is” architecture model should allow agencies to directly link their internal business components to business and customer-centric outcomes. As the “As-Is” architecture model is better defined, the set of common performance measures can then be related to progress in the enterprise planning and budget process.

Alignment with the SRM — The SRM makes it simpler for agencies to organize their current operations into tangible components or services. The agency-wide IT investments and assets can be leveraged based on the SRM into reusable applications, application capabilities, components, and business services. The “As-Is” architecture can document the information systems and data repositories in a component-based model that provides linkages in an inter-nodal and intra-nodal basis.

Alignment with the TRM — It is important for each agency to keep step with the marching progress of technology and determine how technology within their IT assets should be refreshed. It is also

36

important to understand how to insert new technology on an as-needed basis. Each agency should formulate its own TRM (populated within the context of the FEA TRM) that provides technology directions, specifies the selected technology standards, and builds on the network and communications infrastructure (and the consolidation efforts required to be underway in most agencies). It should be understood that work in completing the TRM is labor-intensive. A balance must be maintained between completeness and granularity.

4.4.2.2.3 Pitfalls to Avoid Pitfalls in assessing and documenting the “As-Is” architecture include:

Failing to deal with updating the “As-Is” and effectively dealing with the constantly changing technology baseline environment. Agencies need to be concerned with proper configuration management of their IT assets, and with the long software development life cycle of their existing programs. One method that has been successful in certain agencies is to create an overall master schedule and target the updates. This master schedule tracks the progress of all systems that are in development and determines a current state based on proper version management of each major program or application.

Failing to recognize that operational updates feed the creation of the “As-Is” EA state and that once a baseline set of documents or a tool with models have been created operational updates need to be controlled via a rigorous configuration mechanism for later development and continuing operational maintenance use.

4.4.2.3 Development of “To-Be” Architecture The target architecture that formulates the “To-Be” vision needs to have the agreement of the key stakeholders within the agency. A well-developed plan needs to be put in place that incorporates information from the strategy sessions held within the organization. A complete and institutionalized EA Program that codifies the target architecture consists of a sustainable governance framework and optimized business processes supported by appropriately configured data, applications, systems and technology infrastructures.

4.4.2.3.1 Applicable EAMMF Elements Stage 3 and 4, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.4.2.3.2 Description of Successful Practices

Developing a Common Vision The development of a common “To-Be” vision for the enterprise has to be completed in the earliest phase of the EA development life cycle. A successful practice is to create a mission or vision statement that fully documents the vision of the agency stakeholders and aligns the vision to the agency core mission and goals. An architecture strategy document then articulates this agency vision into a concept of operations (CONOPS). The next steps are to examine the existing business definitions and processes and to analyze how the processes will change to accommodate the new “To-Be” state. The

The development of a target or “To-Be” vision needs to include all of the key stakeholders within the organization along with thought leadership that describes the future state.

37

definitions and processes are then vetted against existing regulations such as the OMB Circulars, E-Gov and Clinger-Cohen Acts.

Administering Traceability between the “As-Is” and “To-Be” State The process of tracing differences between the “As-Is” and the “To-Be” state is usually one of the most difficult steps in the entire EA life-cycle process. Agencies are expending a significant amount of time and resources in the activity of tracing enterprise requirements from the current to the target state. The Department of Defense (DoD) Business Enterprise Architecture (BEA) has developed an architecture development methodology that provides details on how to take the existing set of architecture products and update it for the “To-Be” environment. The steps for this activity are the following:

Update EA Work Products — Review and document required changes within each of the architecture views.

Integrate EA Views and Products — Maintain linkages between each of the architecture views internal and external to the enterprise domain.

Verify EA Product Updates — Conduct peer reviews and cross-review audits to determine if changes have been properly propagated.

Update Traceability to Requirements —Requirements traceability should be codified in a repository that maintains the two-way linkages.

Update Business Scenarios — Business scenarios used within the agency are updated based on change in architecture requirements.

Verify and Validate Architecture — Analyze the “To-Be” model to ensure that changes administered by upcoming development programs have been incorporated.

Publish/Communicate to Stakeholders — This activity covers tasks needed to easily disseminate the new architecture to all of the enterprise domains.

Determining Time Frame for “To-Be” Architecture When the architecture strategy is developed that communicates the target architecture, most departments within agencies have a difficult time in validating how long it will take to adopt a reasonable time frame for developing its “To-Be” architecture. Since most agencies have spent a significant amount of time and resources in their existing IT systems, it is difficult to shift to a new state where these existing systems are marked as legacy. It is also difficult to remove all of the old business processes and start from scratch guided by a fully developed, target architecture.

A 5-year time frame is a rule of thumb that is commonly used in this context. The time frame has to be far enough into the future so that it is not dependent upon the yearly Federal budget process. And yet, the time frame cannot be too distant since technology changes on a rapid basis. Five years allows the IT systems within an agency to be exposed to a whole new variety of capabilities. However, since EA is an ongoing activity and the architecture models are a moving target, it is best to communicate a common set of calendar year dates that is easily understandable by all of the agency stakeholders and the major IT development programs.

It is difficult to project the IT and business needs of an organization for the future budget years; so, a 5-year time frame is a good rule-of-thumb gauge for the target or “To-Be” state.

38

4.4.2.3.3 Pitfalls to Avoid The pitfalls inherent in this activity include:

Changing personnel such as the ranking senior leadership or key stakeholders. This change can affect the common vision for the target architectural state. Since the “To-Be” state presents a common vision for the future, this vision must then be modified in mid-stream to reflect the new agency reality.

Failing to update the architecture strategy documents yearly to reflect the changes in agency perspectives.

Failing to ensure that any new target visions for the mission/business are communicated throughout the organization so that, for example, the current IT assets and software development programs work in concert with the EA Program life cycle.

4.4.2.4 Integrating Agency EAs and the Federal Enterprise Architecture An important factor in OMB’s evaluation of Exhibit 300 submissions described above is the compliance of the proposed investment with the Federal Enterprise Architecture (FEA). The FEA Reference Models and their use in evaluation of the “As-Is” architecture are described earlier in Section 4.4.2.2. This section focuses on the integrating the agency “To-Be” architecture with the FEA.

4.4.2.4.1 Applicable EAMMF Elements Stages 3 and 4, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.4.2.4.2 Description of Successful Practices Successful integration of the FEA with an agency EA is characterized by several practices, given below.

Refine the FEA at the Agency Level To be truly useful, FEA model elements need to be augmented by agency-specific elements that are linked to the FEA. For example, the definitions of business functions within the FEA Business Reference Model need to be “drilled down” into more specific business process model elements unique to an agency, which then link back to the BRM. In some cases, the FEA explicitly provides for this. For example, the Performance and Data Reference Models both describe common, high-level abstractions while leaving it to the agencies to describe specific performance objectives or data objects.

Augment the Agency EA with Additional Model Object Types It is important to recognize that the FEA describes at most 15 – 20 percent of all the relevant types of EA-related information an agency may wish to model. The FEA does not touch upon important perspectives such as workforce, strategy, facilities, and any number of domain-specific areas that will be important to a given agency.

Don’t Treat the FEA as Fixed and Finite The development of the FEA is an iterative and incremental process and it is dependent on the feedback and participation of agencies through bodies such as the Federal CIO Council. The FEA Program Management Office has spawned numerous auxiliary initiatives such as the Federal Health Architecture to further refine the FEA to accommodate the specific needs of Government business domains. Agency

39

leaders such as the Chief Enterprise Architects through the Chief Architects Forum need to collaborate closely with the FEA PMO so that subsequent versions will more closely meet their specific needs. This very collaborative approach is being advocated by the FEA Program Management Office.

The FEA Reference Models Only Partially Cover the Zachman Framework The FEA Reference Models do not constitute a comprehensive EA methodology or approach by themselves. For instance, the information identified in the FEA Reference Models maps to only a subset of coverage of the Zachman Framework. (See Figure 4.4.2.4-1 below.) Others have stated that this mapping is incorrect and that the actual mapping is by columns. Viewed from each perspective or row in the Zachman framework the models could be associated with columns, i.e., BRM and SRM in the “How” column; DRM in the “What” column; PRM in the “Why” column; and TRM in the “Where” as well as perhaps “How” columns. In either case. it can be shown that population of the information as required in these models does not cover the entire set of cells in each column.

While it is now openly debated by proponents of the Zachman Framework whether all of the cells must be populated, recognition of the distinction between the FEA and Zachman should serve to underscore that these FEA Reference Models, as populated, specifically serve mainly as mechanisms for identifying and coding initiatives via a common taxonomy and as checklists for coverage in an EA. There is nothing wrong with this, and, in fact, it is critical to the congealment of an EA at the entire Government enterprise level. On the other hand, the population of just the reference models and “mapping to them” does not constitute what is generally accepted as a complete EA.

4.4.2.4.3 Pitfalls to Avoid The single greatest pitfall when aligning an agency EA to the FEA is to treat the FEA as a comprehensive EA framework, which it is not. The FEA does not have the ambitious scope of the earlier Federal Enterprise Architecture Framework (FEAF), which described process and phase-oriented activities such as baseline and target architectures and transition planning. When designing the overall agency EA framework, consider augmenting the FEA with constructs from other frameworks such FEAF, C4ISR/DoDAF, Zachman, or others.

40

e .g . D A TA

E N T E R P R I S E A R C H I T E C T U R E - A F R A M E W O R K

B u i l d e r

S C O P E

( C O N T E X T U A L )

M O D E L

( C O N C E P T U A L )

E N T E R P R IS E

D e s i gn e r

S Y S T E M

M O D E L

( L O G IC A L )

T E C H N O L O G Y

M O D E L

( P H Y S I C A L )

D E T A IL E D

R E P R E S EN -

T AT I O N S

( O U T - O F -

C O N T EX T )

S u b -

C on t ra c to r

F U N C T I O N I N G

E N T E R P R IS E

D A T A F U N C T I O N N E T W O R K

e . g. D a t a D e f i n it i o n

E n t = F ie l d

R e ln = A dd res s

e .g . P h y s i c al D a t a M o de l

E n t = S e g m e n t/T ab l e /e t c .

R e ln = P o i n te r / K e y/e t c.

e .g . L o g ic a l D a t a M o d e l

E n t = D a ta E n t i ty

R e ln = D a ta R el a ti o n sh i p

e . g. S e m an t i c M o d e l

E n t = B u s i n es s E n t i ty

R e ln = B us i n es s Re l a ti o n sh ip

L is t o f T h i n g s I m p o r t an t

t o t h e B u s in e ss

E N T I T Y = C l as s o f

B u si n e ss T h i ng

L is t o f P r o ce ss es t h e

B u s i n e ss P e r f o r m s

F u n c t ion = C las s o f

B u s i n e ss P ro c es s

e .g . " A p p l ic a ti o n A r c h i te c tu r e "

I / O = U se r Vi e w s

P ro c . = A p p l ic a ti o n F u n ct io n

e .g . " Sy s t e m D e s ig n "

I /O = S c r ee n / D ev ic e F o r m a ts

P r o c .= C om p u t er F un c t i on

e .g . " Pr o g r a m "

I / O = C o n t r o l B l o c k

P r o c .= L a n g u ag e S tm t

e .g . F U N C T I O N

e .g . B u s in e ss P ro c e s s M o d e l

P r o c . = B u si n e ss P r o c es s

I /O = B us i n es s R e so u r c e s

L is t o f L o c at io n s i n w hi ch

th e B u s in e ss O p e r a te s

No de = M aj o r B u s in ess

L o ca t io n

e .g . L og i s ti cs N e t w o r k

N o d e = B u s in e ss L o c at i o n

L in k = B u s i n es s L i n k a g e

e .g . " D i s t r i b u te d S y s t e m

N o d e = I / S F u nc ti o n

( P r o c e sso r , S t o r a g e, e t c)

L in k = L i n e C h a r a ct e r is ti c s

e .g . " S y s t e m A r ch i t ec t u r e "

No d e = H a r d w ar e / S ys t e m

S o f t w a re

L in k = L i n e S p ec i f i ca t io n s

e .g . "N e t w o r k A r c h i t ec t u r e"

N o d e = A d d r e ss es

L in k = P r o t o co l s

e .g . N E T W O R K

A r c h i te c tu r e "

P l a n n e r

O w n er

B u i ld e r

EN T E R P R IS E

M O D E L

(C O N C E P T U A L )

D es i gn e r

S Y S T E M

M O D E L

(L O G I C A L )

T E C H N O L O G Y

C O N S T R A IN E D

M O D E L

( P H Y S I C A L )

DE TA I L ED

R E P R E S E N -

T A T I O N S

( O U T -O F

C O N T E X T )

S u b -

C o n t ra c t or

F U N C T IO N IN G

M O T IV A T IO NT IM EP E O P L E

e .g . R u l e S p e c if i ca ti o n

E n d = S u b -c o n d iti o n

M e a n s = S te p

e .g. R u l e De s i g n

En d = C o n d it i o n

M e a n s = A c t io n

e .g . , B us i n es s R u le M o d el

E n d = St r uc tu ra l A ss er t io nM e a n s = A c ti o n A ss e r t io n

E n d = B u s i ne ss O b j e ct i v e

M e a n s = B u s in e ss S t r a t eg y

L is t o f B u s in e ss G o a ls / S t r a t

E n ds / Me an s =M a j o r B us . G o al /

C r it i c al S u cc e ss Fa c to r

L is t o f E v e n ts Si g n i f ic a n t

T i m e = M a jo r B u s i n e ss E v en t

e .g . P ro c e ss i n g S t r u ct u r e

C y c l e = P r o c e s s in g C y c leT im e = S y s t em E v en t

e .g. C on tr ol S t r u c tu re

C y cle = C om p o n e nt C yc l e

T im e = E x e cu t e

e . g . Ti mi n g D e f i n i ti on

C y cl e = M a c h in e C yc l eT i m e = I n t er r u p t

e .g . S C H E D U L E

e .g . M a s t e r S ch e d u l e

Ti m e = B us i ne ss E v e n t

C y c le = B u s in e s s C y c l e

L i s t o f O r gan i z at i o n s

P e o p l e = M a jo r O r g a n iz a ti o n s

e. g . W o r k F lo w M o d el

P eo p l e = O r g a ni z at io n U n it

W o r k = W o r k P r o d u c t

e . g . H u m an I n t e r f ac e

Pe o pl e = R ole

W o r k = D e li v e r a b l e

e .g . P re se n t at i o n A r c h i te c tu r e

P e o p l e = U se r

W o r k = S c re e n F o r m a t

e .g . S e c ur it y A r c h it e ct u r e

P e op l e = I d en t i tyW o rk = J o b

e .g . O R G A N I Z A TI O N

Pl a n n e r

O w n e r

to th e B u s in e s sI m p o r ta n t t o t h e B u s i n e ss

W h a t H o w W h e r e W h o W h e n W h y

C o p y ri g h t - Jo h n A . Z a c h m a n , Z a c h m a n In t e r n a t i o n a l

S C O P E

(C O N T E X T U A L )

A r ch i t ec t ur e

e .g . S T R AT E G YE N T E R P R IS E

e .g . B u s in e ss P l a n

T M

Z a c h m a n I n s t i t u t e f o r F r a m e w o r k A d v a n c e m e n t - ( 8 1 0 ) 2 3 1 - 0 5 3 1

BRMDRM

TRMNode = I/S FunctionLink = Line Character istic

Arch itecture”

E.g . “Presentation Architecture” E.g. “Control Structure”

Cycle = Pro cessing Cycle

En ds/Means + Major BuPRM

SRMProc. = Application FunctionI /O = User Views

Process = Class ofV. 2.0Entity = Class ofBusiness Thing

Processes and ActivitiesProcesses and Activities

PeoplePeople TechnologyTechnology

CustomerResults

CustomerResults

BusinessResults

BusinessResults

Strategic Outcomes

Other Fixed AssetsOther Fixed Assets

Value

Support Delivery of Services

Internal Operations/Infrastructure

Legislativ e Management

Busin ess Man ag ement of Information

IT Man agement

Planning and R esource Al location

Regulatory M anagement

Controls and Oversight

Public Affairs

Internal Risk Management and M itigation

Federal Financial Assistan ce

Human R esources Finan cial Management

Ad min Supply Chain Man agement

Human R esources Financial Management

Ad min Supply Chain Man agement

Inter - Agency Intra - Agency

WebServices

Telephone- Voice- Interactive

E-systemto System

Public/PrivatePartnerships Fax Kiosk

Face toFace Mai l

Program Admin ComplianceServices to Citizens

Public Asset Man ag ement

Marketab le Asset M anag em ent

Defense & Nat’l Securit y Ops

Diplomacy & Foreign R elations

Disaster Man ag em ent

Domestic EconomyEducation

Energ y M anag ement

Insurance

Public Health

Recreation & N ational R esou rces

Social Services

R&D & Science

Regulated Activity Approval

Consumer Safet y

Environmental ManagementLaw Enforcement

Legal

Revenue Collection

Trad e (Import/Export)

Transportation

W orkforce M anag em ent

WebServices

Telephone- Voice- Interactive

E-systemto System

Public/PrivatePartnerships Fax Kiosk

Face toFace Mail

Support Delivery of Services

Internal Operations/Infrastructure

Legislativ e Management

Busin ess Man ag ement of Information

IT Man agement

Planning and R esource Al location

Regulatory M anagement

Controls and Oversight

Public Affairs

Internal Risk Management and M itigation

Federal Financial Assistan ce

Human R esources Finan cial Management

Ad min Supply Chain Man agement

Human R esources Financial Management

Ad min Supply Chain Man agement

Inter - Agency Intra - Agency

WebServices

Telephone- Voice- Interactive

E-systemto System

Public/PrivatePartnerships Fax Kiosk

Face toFace Mai l

WebServices

Telephone- Voice- Interactive

E-systemto System

Public/PrivatePartnerships Fax Kiosk

Face toFace Mai l

Program Admin ComplianceServices to Citizens

Public Asset Man ag ement

Marketab le Asset M anag em ent

Defense & Nat’l Securit y Ops

Diplomacy & Foreign R elations

Disaster Man ag em ent

Domestic EconomyEducation

Energ y M anag ement

Insurance

Public Health

Recreation & N ational R esou rces

Social Services

R&D & Science

Regulated Activity Approval

Consumer Safet y

Environmental ManagementLaw Enforcement

Legal

Revenue Collection

Trad e (Import/Export)

Transportation

W orkforce M anag em ent

WebServices

Telephone- Voice- Interactive

E-systemto System

Public/PrivatePartnerships Fax Kiosk

Face toFace Mail

WebServices

Telephone- Voice- Interactive

E-systemto System

Public/PrivatePartnerships Fax Kiosk

Face toFace Mail

Service Platforms

Serv

ice

Inte

grat

ion

/ In

tero

pera

bilit

y

Security

Presentation / Interface

Business Logic

Data Management

Data Interchange

Component Architecture

Serv

ice

Tran

spor

t

Service Requirements

Service Delivery Channels

Access Channels

Service Platforms

Serv

ice

Inte

grat

ion

/ In

tero

pera

bilit

y

Security

Presentation / Interface

Business Logic

Data Management

Data Interchange

Component Architecture

Serv

ice

Tran

spor

t

Service Requirements

Service Delivery Channels

Access Channels

Data Category

Data Topics

Data Classes

Data Elements

Storage Devices

Agency A Agency B Agency C

Data Category

Data Topics

Data Classes

Data Elements

Storage Devices

Agency A Agency B Agency C

Customer Services

Process Automation Services

Business Management Services

Digital Asset Services

Business Analytical Services

Back Office Services

Com

mon

Ser

vice

s

Cros

s-Cu

ttin

g Se

rvice

Are

as(i.

e.,

Sear

ch,

Secu

rity)

ServiceTypes

Service Layers

Service Components

PerformanceMeasures

BusinessProcess

Access and Delivery Channels

Customer Services

Process Automation Services

Business Management Services

Digital Asset Services

Business Analytical Services

Back Office Services

Com

mon

Ser

vice

s

Cros

s-Cu

ttin

g Se

rvice

Are

as(i.

e.,

Sear

ch,

Secu

rity)

ServiceTypes

Service Layers

Service Components

PerformanceMeasures

BusinessProcess

Access and Delivery Channels

Mapping the Federal Reference ModelsAnd their logical use to the ZACHMAN

FRAMEWORK TM

Figure 4.4.2.4-1. Mapping of the FEA Reference Models to the Zachman Framework

(Note: the DRM shown above is from a previous draft of the DRM.)

4.4.2.5 Managing the EA Program Life Cycle The strategy for developing an EA Program revolves around a common and enforceable life cycle. Key project management principles must be abided by, to ensure that EA work products are created and managed according to budgetary costs and schedules. Each agency has to accommodate its ongoing EA life-cycle development and maintenance processes to its agency-wide level life cycles. In many instances, they have been independent of one and another, putting EA at a disadvantage in terms of maximizing its value-added input to the agency life cycle. This EA life-cycle process necessitates the commitment and buy-in of senior leadership within the organization such that the processes are complementary to the other life-cycles and are enforced. It should be understood that the EA process is a long-term commitment that requires a dedicated focus. Figure 4.4.2.5-1 depicts the relationship between process life cycles at a major department as recently approved in its governance process.

The EA life cycle should not be confused with the Software Development Life Cycle (SDLC) of a program within the organization — even though there may be common paths.

41

Systems Development Life Cycle PhasesConceptual

PlanningConceptual

PlanningPlanning &

Rqmts. DefinitionPlanning &

Rqmts. DefinitionDesignDesign Development

& TestDevelopment

& TestImplementImplement DispositionDispositionOperations

& Maint.Operations

& Maint.

Capital Planning Process PhasesSelectSelect

PortfolioOf Invest.

ControlControlProjectReviews

EVMS, ROI& Perform.

EvaluateEvaluateBusinessProposal PIRSs

Security Process PhasesInitiationInitiation

Development or AcquisitionDevelopment or Acquisition ImplementationImplementationDispositionDispositionOperations &

MaintenanceOperations & Maintenance

PIA RiskAssessment

ATOCertification &Accreditation

Annual Review

TechnicalEA AssessmentCertification

1Enterprise Architecture Phases

Business, Strategic & Performance

Components Use & Technical Alignment

Business AlignmentBusiness Alignment Technical AlignmentTechnical Alignment Compliance AssessmentCompliance Assessment

Compliance, Update & Changes

1 2 3 4

Systems Development Life Cycle PhasesConceptual

PlanningConceptual

PlanningPlanning &

Rqmts. DefinitionPlanning &

Rqmts. DefinitionDesignDesign Development

& TestDevelopment

& TestImplementImplement DispositionDispositionOperations

& Maint.Operations

& Maint.

Systems Development Life Cycle PhasesConceptual

PlanningConceptual

PlanningPlanning &

Rqmts. DefinitionPlanning &

Rqmts. DefinitionDesignDesign Development

& TestDevelopment

& TestImplementImplement DispositionDispositionOperations

& Maint.Operations

& Maint.

Capital Planning Process PhasesSelectSelect

PortfolioOf Invest.

ControlControlProjectReviews

EVMS, ROI& Perform.

EvaluateEvaluateBusinessProposal PIRSs

Capital Planning Process PhasesSelectSelect

PortfolioOf Invest.

ControlControlProjectReviews

EVMS, ROI& Perform.

EvaluateEvaluateBusinessProposal PIRSs

Security Process PhasesInitiationInitiation

Development or AcquisitionDevelopment or Acquisition ImplementationImplementationDispositionDispositionOperations &

MaintenanceOperations & Maintenance

PIA RiskAssessment

ATOCertification &Accreditation

Annual Review

Security Process PhasesInitiationInitiation

Development or AcquisitionDevelopment or Acquisition ImplementationImplementationDispositionDispositionOperations &

MaintenanceOperations & Maintenance

PIA RiskAssessment

ATOCertification &Accreditation

Annual Review

TechnicalEA AssessmentCertification

1Enterprise Architecture Phases

Business, Strategic & Performance

Components Use & Technical Alignment

Business AlignmentBusiness Alignment Technical AlignmentTechnical Alignment Compliance AssessmentCompliance Assessment

Compliance, Update & Changes

1 2 3 4TechnicalEA AssessmentCertification

1Enterprise Architecture Phases

Business, Strategic & Performance

Components Use & Technical Alignment

Business AlignmentBusiness Alignment Technical AlignmentTechnical Alignment Compliance AssessmentCompliance Assessment

Compliance, Update & Changes

1 2 3 4

Figure 4.4.2.5-1. Example Relationship between Process Life Cycles

4.4.2.5.1 Applicable EAMMF Elements Stage 5, Attribute 2, “Provides Capability to Meet Commitment.”

4.4.2.5.2 Successful Practices It is important to provide an example of a successful EA life cycle that incorporates a number of the elements of the planning and governance process. Table 4.4.2.5-1 provides a representative stepwise life cycle of many of the items necessary for a successful, formalized EA development program. This information is provided in outline form, since the content of each deliverable has to be customized to the exact needs of the agency. The activities may differ based on the EA Framework that is used by the agency, and the EA work products that are derived from it. The activities in the development phase provide specific guidance and should be coordinated based on the overall EA Program life cycle across each of the various departments within an agency. The following EA Program life cycle has been proposed for use by the U.S. Peace Corps.

42

Phase 1: Initiation

Get Commitment Identify Critical Success Factors Develop Principles Build Road Map Plan Governance Charter EAPMO and Configuration

Control Board Develop Policies Identify Processes.

Phase 2: Planning

Plan EAPMO Work Breakdown Structure Develop Budget, Schedule, Reporting

Structure Build Controlling Mechanism Configuration Management Address Security/Information

Assurance Prepare Communications Plan Assess Certification and Training Assess Operations and Maintenance

Phase 3: Development

Collect Artifacts Develop Procedures and Tools Develop Products Plan Transition and Sequencing of “As-

Is” State and “To-Be” State Verify EA Processes and Products.

Phase 4: Certification

Adopt EA Internally Certify EA Externally.

Phase 5: Using the EA

Align Projects with the EA Throughout the Project Life Cycle Build Business Cases Assess Project Compliance Determine Waiver Disposition.

Phase 6: Evolving the EA

Submit EA Change Acquire Funding Decisions Process Waivers Align Project Charters Maintain EA Change Requests.

Table 4.4.2.5-1. Representative EA Life Cycle

4.4.2.5.3 Pitfalls to Avoid A number of departments and their individual agencies are currently putting in place a coordinated EA life cycle that would work throughout the enterprise. A common pitfall, in this case, is the inability to make this process flexible enough to be able to work with the existing software development life cycle for each IT development program within the organization.

The EA life cycle needs to be created as a distinct activity that is not swayed or affected by the major or important IT programs within the department. Development projects have their own set of milestones and deliverables that are determined by the agency sponsors and follow the budgetary calendar year cycle. Agencies have to make sure that the EA products that are created by the stakeholders present the correct “As-Is” and “To-Be” architecture and the most recent information from each of the department’s development programs are reflected within the architecture plans and models.

43

4.4.2.6 EA Modeling and Integration Enterprise modeling is an expression of concepts, which allow each part of an agency to understand and contribute to its own evolution. Since Government agencies are not monolithic organizations, each agency has had the difficult task of integrating its information within each of its departments and within other Federal agencies. This section points out successful modeling techniques that have been used within agencies, and how the information has been stored in common repositories.

4.4.2.6.1 Applicable EAMMF Elements Stages 3 and 4, Attribute 3, “Demonstrating Satisfaction of Commitment.”

4.4.2.6.2 Successful Practices A successful practice within an enterprise is the use of models and integration tools that bring all parts of an organization together to create rich knowledge and information bases for all to use. A good model can communicate much of an agency’s purpose to its stakeholders, whether they are the employees, contractors, or public citizens. Enterprise modeling methods usually fall into four separate categories: Business Process Models, Data Models, Structured Models, and Object-Oriented Models.

Business Process Models — Business process modeling provides a methodology for representing business processes that describes activities and their interdependencies in order to reveal inefficiencies and areas for improvement. Most business process models are very time-consuming to produce. They tend to spark reengineering throughout the business unit and they require extensive diagramming, data storage, data retrieval and reporting. However, now that alignment to the OMB BRM has become a priority for each agency, it is becoming more important for each organization to organize their functional business matrix in a structured and automated manner.

Data Models — They are used to support the classification of data and information in respect to how it supports business processes. All agencies have been creating data models for a long time and the issue is not that data models do not exist — it is that the format may not be acceptable to the rest of the organization. Currently, for example, XML is being widely used for sending and receiving data messages. Agencies usually create data flow diagrams, logical data models, and physical data models.

Structured Models — They are used to codify business and systems processes and architecture for the environment. The idea is to codify one-to-one and one-to-many relationships in the use of text, graphics, and media files. Structured modeling includes, for example, information engineering techniques described by James Martin, Yourdon/De Marco, or Gane/Sarson.

Object-Oriented Models — In the Object-Oriented (OO) data modeling paradigm, the data and how to manipulate the data, is combined into a single entity to form a class or object. OO is described through the use of the Unified Modeling Language (UML) that explains the instantiated data objects and their information relationships within the enterprise. OO data modeling techniques have been prevalent for some time.

Agencies are currently using a host of commercially developed tools to aid in the process of documenting their EA. Since a comprehensive listing of all tools is not possible, herein, we have chosen to include some primary considerations regarding tool selection (and fit to purposes) that should be considered. Characteristics to be considered include:

44

The tool flexibility required to configuring it to meet a variety of modeling techniques and uses is important. Are there available templates for the tool or are there a variety of integral models that are required or useful for the organization?

Does the tool integrate with other tools and the Web? Can the tool be used through the agency’s intranet?

Is there a user group that helps the vendor define, select and test future modifications and fixes for the toolset and does it contain or accommodate relevant FEA and Federal requirements?

Does it produce diagrams using standardized notations like XML and UML?

4.4.2.6.3 Pitfalls to Avoid Pitfalls in creating EA documentation (hard copy or electronic) that is easily understandable to all parties include:

Collecting information for which there is not a clearly defined use.

Keeping an overload of electronic information stored within their agency LAN or intranets such that current or relevant information cannot be easily found.

Having data embedded in an old toolset that is not compatible with newer versions or other current tools.

Not having the ability to easily disseminate, retrieve, and navigate within the tool to find and extract needed information.

Lack of integration of EA products. This can usually be a complex activity and many agencies are coping with the results by pursuing changes on an ongoing basis.

Failing to “speak the language” of the end-users of the models. Not all people will understand the models because of lack of training and appropriate experience and knowledge. It is imperative to use EA models in an unambiguous way of representing enterprise knowledge so that technical and non-technical people alike can understand it.

Failing to expend time and resources into configuration management of EA documents. Careful attention needs to be paid to document version management and maintaining access controls. This in turn will allow stakeholders to retrieve the correct EA information electronically on an ongoing basis, as needed.

4.4.2.7 Developing the Sequencing Plan Once an agency has completed documenting the “As-Is” current state and “To-Be” target state, the question is then “How do we get there from here?” A number of agencies are now creating transition plans or sequencing plans as part of their architecture efforts. Transition plans and sequencing plans are usually synonymous, except that a sequencing plan admits that a large transition is actually a sequence of ordered transitions.

Transition plans and sequencing plans are usually synonymous — except that a sequencing plan admits that a large transition is actually a sequence of small transitions.

45

Most sequencing plans are associated with capital and budgetary planning at the agency level that asks for future funding based on the agency capabilities. However, as enterprise architecture becomes more established within the organizations, management is realizing that it is important to align the architecture products to support the ongoing planning of projects and initiatives.

In short, a sequencing plan is a “roadmap” that administers traceability for all of the agency-level initiatives that have been delineated within the “To-Be” target state. This level of traceability can only be achieved if the activities are split into “bite-sized” chunks that trace the business and technology elements through the future years. The successful sequencing plan incorporates traceability based on the following aspects: the high-level EA life cycle, business and IT budget planning on a yearly basis, external inputs from Federal mandates, and workflow automation that allows automated information systems to incrementally incorporate business functions based on the latest technology tools.

The successful practices section provides a core set of activities that should be placed within a sequencing plan in a stepwise manner. Because transition and sequence plans can vary widely within different agencies, these set of steps provide a minimum set of elements that should be included. The pitfalls-to-avoid section then outlines some of the difficulties that departments and agencies have faced.

4.4.2.7.1 Applicable EAMMF Elements Stages 3 and 4, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.4.2.7.2 Description of Successful Practices Creating an agency-wide sequencing plan is a difficult activity and often gets incorporated with a number of different deliverables within the departments of an agency. A successful practice would be to consider the following set of elements:

Start with a Documented Current “As-Is” State — Agencies have been hard at work trying to define their current business and IT processes that include EA products and deliverables.

Put in Place a Target “To-Be” Vision — This has been the goal for all agencies involved with EA, to document their target vision and state.

Develop a Technology Alignment Plan — Based on the current and target states, a technology alignment plan is necessary to define how current and future technology should be inserted within the transition plan to allow agency departments to incorporate new technology within upcoming projects. The technology alignment should also be based on documented architecture products that provide system hardware, software, network, and communications infrastructure details for the current state and the future direction. This often requires specialized assessments and expertise. For example, decisions to migrate to all digital communications networks and instituting technologies such as all digital phone service, while sometimes economically attractive, often have other implications and impacts to analog phone voice based systems that must be considered.

Develop a Business Alignment Plan — All of the business functions and capabilities that are documented within the current state need to be analyzed and evaluated on how they are transitioned to the target state. The business alignment includes architecture products that illustrate the business processes, functional entities and data definitions, and workflow relationships between different agency capabilities.

46

Develop a Security Alignment Plan — A plan needs to be developed for how security risks are identified within an agency’s business process models and the security safeguards in place mapped against those risks to identify areas in need of security remediation.

Alignment with the CPIC Process — The information technology Capital Planning and Investment Control (CPIC) process is founded on the principles of IT portfolio management, which provide an integrated approach to the selection, control, and evaluation of technology investments. Each agency has to align its business and IT needs to its respective CPIC portfolio activities before they are submitted to the OMB. It is important for the business and technology alignment processes to then be aligned to the CPIC portfolios.

Develop a Master Schedule — An agency-wide sequencing plan requires a master input from each of the department-level projects that then sequences the proper transition to the target state. This master schedule can be at a high-level and it is up to agency management to hone in on the level of scrutiny required. Within the DoD, the job of creating a sequencing plan falls within the purview of the department Chief Architect, while the Program Executive Officer (PEO) has the responsibility for conducting the acquisition life cycle for the IT programs. This means that alignment of department-level IT projects to the sequencing plan requires the PEO and Chief Architect to work together to meet the common goals of the “To-Be” target state.

Develop Dependency Chart — The purpose of a sequencing plan is to ensure that the dependencies between all of the projects within the various departments have been coordinated properly. This dependency chart needs to consider the information and data exchange between each of the IT systems and the schedule dependencies of IT systems under development.

Aggregate Master Schedule and Dependency Chart — For reporting purposes, it is important to aggregate all of the pieces of the sequencing plan into a consolidated activity so that this information can be communicated on a regular basis. A set of metrics can also be developed on how often these elements are presented as a report, and how progress is tracked to transition from the current state to the target state.

Modify Master Sequencing Plan As You Go Along — Once a consolidated sequencing plan is created, it is important to keep in mind that the activities need to be flexible to change based on management input and Government regulations. For example, at one agency, two levels of sequencing plans are maintained, the strategic and tactical. As budgetary changes and project completion schedules affect the tactical sequencing plan, the changes are reflected in the strategic sequencing plan to maintain consistency between them.

4.4.2.7.3 Pitfalls to Avoid Here are some of the issues that agencies have been grappling with that are difficult to address and resolve:

Not Dealing with Legacy Systems and Systems in Maintenance — When a sequencing plan describes where the agency’s programs are moving toward, it is always difficult to decide what to do with existing legacy systems. This is where a sequence plan has to document when legacy systems are to be turned off and how other existing systems will be technically refreshed instead of being dismantled. The agency Technical Reference Model (TRM) and technical standards profile should aid in this process, identifying how existing systems in maintenance should be overhauled. There are many

47

examples of how new middleware is applied to allow access to data stored in old mainframe legacy systems without having to overhaul or extract it. In fact middleware has become a new software market niche full of vendors with amazing capabilities.

Using the “To-Be” Life Cycle of the Agency to Guide the Project Life Cycle of Large IT Systems — In a number of instances, agency personnel have allowed the project life cycle for the large IT systems within the department to control the target or “To-Be” state for the organization. This is an easy trap to fall into, but it should be curtailed so that the target state is aligned with the overall goals of the organization and not swayed by individual entities or business units or processes.

Not Creating a Detailed Configuration Control Process — This is obviously an important pitfall to avoid that is part of the larger organizational and architectural process. A sound configuration control process allows each entity within the department an understanding of the information that is being exchanged back and forth between IT systems, and documents the data and information needs of the organization. For example, this is an area where the use of standards like XML have caused great gains, simplifying interface management and configuration control.

Not Creating a Governance Structure to Support the Activity — The success of a sequencing plan is dependent on the understanding that there is a well-formed governance structure. Each step of a sequencing plan has to be carried out in a coordinated manner and this requires active decision-making, management, and oversight. For example, the Chief Enterprise Architect of the agency needs to organize this activity using an overall project life cycle to implement the sequencing plan.

Not Making Changes to the Sequencing Plan Based on Changes to the Target Vision — Often, it is understandable that the “To-Be” vision of the target state is modified to meet the changing needs of the agency. In this case, the sequencing plan needs to be carefully reconstructed so that it has agreement from all of the major stakeholders within the organization. Changes in the transition planning need to be coordinated based on the subsequent changes to the architecture products. It is also important to redo the business and technology alignment processes so that it meets the new target vision.

Assuming That Developing a Sequencing Plan Requires Merely a Complete Set of Architecture Products — At this time, when all of the agencies are expending a great deal of effort in producing agency-level EA products, it should not be assumed that, as soon as all of these EA products are completed, the agency can move ahead to the target state. Transition planning requires a great deal of time and effort, and separate tasking needs to be addressed in the case of implementing a sequencing plan especially if the agency transition and related technology infusion is large, of high dollar value, and extensive.

4.4.3 Facilitating Reuse Identifying and leveraging opportunities for reuse is one of the core benefits of an effective and mature enterprise architecture initiative. True enterprise-scale reuse can provide direct and tangible returns on an agency’s EA investment. Reuse can include systems, technologies and data. This section discusses various forms of reuse and strategies for leveraging them.

4.4.3.1 Applicable EAMMF Elements Stages 3 and 4, Attribute 3, “Demonstrates Satisfaction of Commitment.”

48

4.4.3.2 Description of Successful Practices Several important practices have been identified for identifying reuse opportunities when developing an EA, including:

Utilize CORE.GOV CORE.GOV (Component Organization and Registration Environment) is an FEA initiative designed to catalog reusable components within the Federal Government. The CORE.GOV registry includes reusable business and technology components, and electronic forms. Components and services that have been tested and adapted for reuse can be searched and downloaded from the site.

Align to the FEA Reference Models In order to achieve reuse, the assets of an enterprise must first be classified according to a standardized taxonomy in order to identify similarities. This is precisely what the FEA models provide. For example, after an agency identifies the business sub-function (BRM) and service area (SRM) that it thinks can be enhanced through use of reusable components, it is possible to query CORE.GOV or internal agency EA repositories to find corresponding components that could provide those capabilities.

Model Key EA Components Using Standardized Notations and Languages Successful reuse, like the devil, is in the details. If enterprise data or applications are to be reused, their semantics must be well defined. For example, consider developing XML schemas to describe data exchange formats, as shown in Figure 4.4.3-1. Also, consider using UML to document enterprise system and data interfaces.

Facilitated by Standards, Components, and Practices – EA and consistent CPIC and security integration.

XML Schema-based Data Exchange Standards

City County State Federal

PC2000-3915-003a, 8/26/04

Figure 4.4.3-1. Use of XML to Specify Data Exchange Standards

4.4.3.3 Pitfalls to Avoid One of the most common pitfalls in attempting to identify reuse opportunities is neglecting to identify dependencies within the EA. For example, it is not sufficient simply to identify the services an application provides; that application may be dependent on specific technologies, security policies, data sources and

49

other applications to provide its capabilities. All of these may constrain the reuse capabilities of an enterprise resource.

Second, a mature reuse strategy focuses on shared interfaces instead of duplication. If there is data or applications that could potentially be shared across multiple business units, for example, it is usually more constructive to provide shared access to that resource through a common interface, rather than “copying and pasting” to create a second instance of that resource, which would create redundancy and synchronization concerns.

4.4.4 Establishing Agency-to-Agency Integration It is worth recalling that one of the original objectives of the Federal Enterprise Architecture was to identify redundant capabilities across agencies and promote interoperability between systems. A mature enterprise architecture does not simply document interactions within the agency, but looks outward to incorporate transactions and participants that extend beyond the agency’s boundaries. Figure 4.4.4-1 depicts the intent of the FEA in doing precisely this across the Government.

Figure 4.4.4-1. Depiction of the Sharing and Reuse Concept of the FEA

4.4.4.1 Applicable EAMMF Elements Stages 3 and 4, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.4.4.2 Description of Successful Practices We recommend the following successful practices when identifying cross-agency integration opportunities in the agency enterprise architecture.

Cross-agency initiatives are especially useful when similar business data is captured in multiple agencies. For example, DoD and VA are currently sharing the Electronic Health Record of military personnel as they transition from active duty to veteran status.

50

Look Beyond Systems Agency to agency integration practices should be driven by business needs. It is imperative that an agency identify external stakeholders and processes that impact them, not just existing external systems. In some cases, the appropriate systems to support a shared or complementary business process may not exist at either agency, and a new, shared system could be developed collaboratively.

Leverage FEAMS The FEA PMO maintains the Federal Enterprise Architecture Management System (FEAMS), a Government-wide repository that permits agency EA personnel to search and browse for initiatives aligned to the FEA. Once an agency has identified how its own proposed initiatives link to the FEA reference models, it is straightforward to query FEAMS to locate initiatives in other agencies that align to the same lines of business or service components.

4.4.4.3 Pitfalls to Avoid The primary pitfall that has been observed in agency to agency integration is often a focus on technical implementation issues rather than on business and data perspectives. Selecting a common file format or network protocol for cross-agency information exchange is often the least difficult task. Attention must be paid to larger issues, such as:

Who “owns” the data and is responsible for validating its accuracy?

What are the governance processes to manage the initiative?

What redundancy mechanisms exist if the integration mechanism fails periodically?

Can multiple systems be consolidated instead of simply exchanging data, or could they share a common database?

4.4.5 Conduct Independent Verification and Validation (IV&V) An EA, when implemented properly to satisfy e-Government and other core mission initiatives, will create a foundation of organizational processes, procedures, best practices, technology deployments, and working standards that will guide the agency programs and leverage technology to satisfy ever-expanding complex business imperatives. The completed EA should guide and govern the design, development and implementation of technology components to enable the agency to effectively and efficiently integrate technical functions or capabilities with business requirements. In order to implement these design objectives properly, a quality assurance program including independent verification and validation (IV&V) processes must be incorporated into the EA model as early as the initial planning stage. The criteria for integrity and quality should be understood as well as the targeted deliverables, models, repositories and artifacts. Reviewing these ultimately will be the means for IV&V of the architecture.

4.4.5.1 Applicable EAMMF Elements Stage 4, Attribute 2, “Provides Capability to Meet Commitment.”

Since it is difficult to perform IV&V on the agency’s own EA activities, it may be best to employ a disinterested third party to conduct a fair and objective review and communicate the outcome.

51

4.4.5.2 Description of Successful Practices Just as a quality IT applications system design and development program under a repeatable standards program depends upon a quality information assurance capability, the concept is also critical for an enterprise information management model like EA. It provides checkpoints to ensure that desired requirements are actually modeled and fully tested according to a repeatable process guaranteeing to the organization that what is implemented is indeed the model desired. For example, within the Immigration and Naturalization Services/IRM organization under a systems management and integration program, this process is carried out most efficiently. Design criteria and business function specifications for the EA model were carefully assembled, coordinated among service organizations and agreed upon before implementation began. Contractors in a formal quality assurance role utilized these requirements to ensure that the EA models incorporated all design objectives. The effort initially consumed more development time and resources than anticipated. Results now recognize this IV&V approach as a successful practice.

4.4.5.3 Pitfalls to Avoid The following pitfalls should be avoided:

The tendency to develop a common technology infrastructure, but not to pursue common data, business, or applications requirements. This is true particularly for those agencies that adapt a model structure developed by another Federal agency or industry organization. Such efforts are prone to design failures and initial model faults unless the implementing EA architect completes an agency focused requirements design, incorporates that set of requirements into the IV&V effort and tests the model against the agreed upon design criteria. Repeatable quality assurance reviews are essential for quality business modeling and proper information sharing across all concerned elements within the agency.

Not conducting an IV&V by a qualified entity that has no specific vested interest in the outcome and can thereby remain independent and objective. The results of the IV&V should be made public and an immediate action plan prepared for addressing any weaknesses found.

Allowing the results of an IV&V to be internally reviewed by agency personnel and changed according to their needs. This compromises the objectivity and ultimate independence of the IV&V. For example, an agency conducted a review by hiring an expert contractor with significant EA experience and demonstrated capabilities and then took the report and distributed it internally for comment and changes. This report at that point lost its applicability as an independent IV&V.

4.5 Use the Enterprise Architecture

4.5.1 Tie EA Sequencing Plan into the CPIC Process An outstanding characteristic of a mature EA is that it does not exist in isolation. An effective EA cannot become multi-volume “shelfware” that is rarely consulted. Instead, it is a critical pivot point that guides investment decisions and informs the IT processes of the organization.

Capital Planning and Investment Control (CPIC) can be thought of as a way in which the EA “rubber hits the road.” To use an analogy from the National Performance Review, EA “steers” by showing the path forward and CPIC “rows” by implementing initiatives that align with that path. The hard decisions that

52

ultimately determine whether or not an organization progresses toward its vision of a target architecture are enforced as part of the CPIC process.

4.5.1.1 Applicable EAMMF Elements Stage 5, Attribute 2, “Provides Capability to Meet Commitment.”

4.5.1.2 Description of Successful Practices In Federal agencies, the heart of the CPIC process is the creation and evaluation of a business case for an IT investment. For major investments that require OMB approval, this business case is documented as an OMB Exhibit 300 submission. Smaller investments may be documented using internal agency processes with varying degrees of formality. Optimally leveraging the EA to manage an IT portfolio incorporates several best practices:

The EA Must Be Widely Understood and Disseminated The best way to minimize redundant or non-standard investments is to make the EA “self-policing.” Program managers and architects should understand the EA well enough (including the baseline and target architectures and the transition plan) to determine whether or not their proposed investment conforms before they ever draft the business case. Consider developing EA user guides that describe key concepts of the target architecture and provide distilled, concrete guidance on important issues such as technical standards and opportunities for component reuse. Communication of the transition plan is critical to the EA taking hold and making a real difference. For example, some corporations had their EA teams do videos that explained the essential aspects and attributes of the EA and how that would affect their businesses. Often they used comedy and analogies with movies or other popular media events/occurrences to get attention and build interest. These videos were then widely disseminated and shown throughout the organization. It was not unusual to hear at the water cooler “Have you seen the EA video yet? It’s hilarious, and it really explains the changes that will be coming with the new technologies, in a way that even I can see.”

Integrate the Agency EA and Portfolio Management Repositories Most EA modeling and portfolio management tools provide at least rudimentary data import/export capabilities, and some provide sophisticated scripting and integration interfaces. When integrating the tools, however, it is important to remember that they usually have different audiences. Generally speaking, the EA model content is likely to be more widely disseminated, and is often visible to less senior stakeholders. Thus, you may wish to exclude sensitive budget or security data from the description of an investment in the EA model while retaining it in the portfolio management repository.

4.5.1.3 Pitfalls to Avoid The most important pitfalls to avoid are the absence of clear transition plans and governance policies before attempting to align investments against the EA. To be effective, the EA must be enforced — but program managers have a right to know what standards they are being measured against and how the enforcement process will be applied. A transition plan/modernization blueprint should clearly state when standards are to be phased in and when legacy systems and technologies are to be retired. Moreover, the governance plans should make it clear when it is appropriate to grant waivers for non-conforming investments, how certification of EA alignment is to be performed, and the roles of all the participating

53

investment evaluators, such as the Chief Enterprise Architect, the IT Investment Review Board, the CIO Council, the CPIC group, and others.

4.5.2 Utilize the EA for Operational Decision Making The EA, if kept current, provides a comprehensive view of an agency’s IT assets and, as such, provides invaluable information for operational decision making. Examples of decisions include:

An agency wants to do a server consolidation. It can use the architecture as a starting point to determine where all the servers are and the applications and functionality that they support.

An agency decides to move to a performance-based contract. It can use the EA as a specification in terms of the services to be delivered and the requirements for service levels. The EA can be used to set the critical function areas and tight specifications for performance.

An agency has just had a disaster in one of its major data centers and it needs to redesign a new one quickly. It uses the EA repository to find the detailed specifications for all of the systems that are required and their respective interfaces. It then uses this information as a starting point to design a new facility as well as a check point to ensure nothing important was overlooked.

4.5.2.1 Applicable EAMMF Elements Stage 5, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.5.2.2 Successful Practices Key successful practices include the following:

Maintain consistency between the EA and deployed IT projects by publishing periodic updates to the “As-Is” EA.

Provide a set of report generation tools to enable decision makers to rapidly specify and extract information of interest to decision makers.

Above all, providing decision makers with easy access to the EA repository so that they are motivated to use the EA as a planning and decision-making tool.

4.5.2.3 Pitfalls to be Avoided The major pitfall to be avoided is not educating agency personnel about the potential uses of the EA and documenting the variety of ways people can invent to tap and use the information contained with the EA documentation and tools.

4.6 Maintain the Enterprise Architecture Once completed and verified, the EA represents a comprehensive source of information about the entire organization. That structure should be protected by adequate security and change management controls so that it continues as a valued source of agency business, mission, application, data, and technology information. Proposed changes to the verified, EA structure should be reviewed and approved by a formal agency committee to ensure continued value. It must be recognized that, once the EA is functional, it represents a cross-functional picture of the entire agency and is not the responsibility of a single

54

organizational element, even though it may be under the stewardship of the CIO, CTO, or the Office of the Chief Architect.

4.6.1 Applicable EAMMF Elements Stage 5, Attribute 3, “Demonstrates Satisfaction of Commitment.”

4.6.2 Description of Successful Practices An underlying component for governance, budgetary, and technical control in any properly managed repeatable process is a functioning change management program. A formalized change management committee must represent all the affected technical program and management levels within the organization as well as headquarters and field organizations. It is the responsibility of the committee to review and either approve or reject proposed EA modifications. The implications and process steps associated with either of these outcomes should be integrated into the overall CPIC process.

An essential function of the organization is to respond quickly and efficiently to changes in the four layers of the EA — Business, Data, Application, and Technology. The committee should be considered the focal point for technology consequence, standardization, and integration. This committee could be the investment and management control board that makes technical decisions as well as sets capital planning strategies. However, in larger agencies, it has often proven wise to segregate these governance steps and views. However, it is also important to ensure that they are coordinated and that information flows between these functions. Again, the Architecture Alignment and Assessment Guide and the Practical Guide both speak to the EA governance body issues and requirements.

There also needs to be recognition that there are at least two levels of change — the tactical level and the strategic level. The tactical level addresses routine changes resulting from change requests to fix errors, inaccuracies, and omissions, and to address incremental changes in business needs. The strategic level addresses major changes either in business needs or technology that necessitate significant structural changes to the EA. This is a major requirement of the governance processes. The NASCIO Toolkit, v2.0 (page 107) [Reference 8], recognizes the need for ensuring the vitality of an EA. The document states: “To ensure vitality, the Enterprise Architecture Framework must be reviewed from a perspective of business strategic elements, IT strategic elements and recommendations for enhancements. Advisors should provide input for the business strategy and the IT strategy. Any time business strategies or IT strategies make a noticeable shift, an architectural framework review may be required. Enterprise Architectural Framework reviews should occur every one to two years at a minimum.”

4.6.3 Pitfalls to Avoid All too often, organizational elements do not formally meet to discuss or integrate critical programmatic changes. IT support elements independently initiate infrastructure or technology improvement initiatives without coordinating directions with program or business concerns. Conversely, program/business elements tend to implement major application requirements without proper consideration for associated impacts on supporting IT applications or technology support structures. As a result IT structures tend to be independently designed and segmented rather than integrated and comprehensive systems. This is the model for the distributed IT approaches of the past and is not compatible with an Enterprise Architecture approach.

55

5. Summary and Recommendations With EAMMF Version 1.1, GAO has raised the bar for determining the maturity of Federal EA programs. Many agencies continue to struggle with developing EAs that demonstrate progress against the EAMMF and with meeting the needs to drive their business cases and IT investments. The slow progress made by many agencies in advancing their maturity levels using either model indicates the need for providing agencies with guidance and/or assistance in developing their EAs. This paper has attempted to provide unofficial guidance in several areas where agencies appear to be struggling, without trying to become a new or comprehensive guide. It is focused on the results of GAO’s EA assessment presented in Information Technology: Leadership Remains Key to Agencies Making Progress on Enterprise Architecture Efforts, which was published in November 2003.

While efforts such as the creation of this White Paper should help, the IAC EA SIG sees that more needs to be done. The paragraphs below provide five recommendations for achieving additional and significant progress in EA development, deployment, and performance.

1. Strengthened and Continued Executive Sponsorship and Involvement The lack of strong executive sponsorship and ongoing leadership was identified as a major hurdle in agency EA development efforts. This appears to be a widespread problem; EA development is generally delegated to the CIO, and, in many cases, there is very little continued involvement in its development by agency heads and senior executives after the initial kickoff.

Recommendation: IAC recommends that OMB require agencies and departments to document their plans for continued executive involvement and sponsorship (e.g., as part of an EA Executive Review Board that meets periodically) to monitor progress, and to ensure that resources are provided to enable the required momentum to be maintained on EA development.

2. EA Development Planning It appears that many agencies/organizations lack up-to-date, realistic EA development plans that are adequately funded.

Recommendation: IAC recommends that OMB prepare detailed guidelines on preparing and funding EA Program Plans to assist agencies with developing/updating their EA development, governance, and program activities.

3. Need to Share Lessons Learned and Best Practices Across the Federal Enterprise While some departments and agencies have mature EA programs, the majority of the organizations are struggling in their EA development efforts. EA programs in most departments and agencies would benefit from sharing of lessons learned, successful/best practices and artifacts relating to best practices, and pitfalls to be avoided in order to enhance the pace and the quality of EAs being developed.

Recommendation: IAC recommends that the CIO Council Architecture and Infrastructure Committee, through the Chief Architects Forum or other Subcommittees, facilitate this knowledge sharing. In

56

particular, specific steps that could be taken by the Committees and with the IAC as partners include the following:

Developing a process and a set of quality criteria (and/or template) for documenting, collecting, and vetting EA lessons learned across Federal Enterprise, and making them available in either a repository or a directory of links that serves as an organizing framework for use by all agencies

Developing a process for identifying, evaluating, selecting, collecting, and vetting examples of high-quality EA documents, models, artifacts, and work products, and making them available in a repository for use by all agencies.

4. Lack of Clear and Consistent EA Guidelines The GAO used the FEAF and other previous CIO Council EA guides and addressed the overall methods, capabilities, and approach to developing an EA. These EAs are at varying levels both at the department-wide and at the component levels of agencies (as well as at smaller agencies and independent boards and commissions). Currently, no guidance or policy exists that defines the comprehensive coordination of the development of component agency level EAs ( as articulated by the GAO), or how to distill and integrate the agency-level architectures into departmental EAs (or departmental EAs into a Federal EA — including the Lines-of-Business and e-Gov initiatives). It is believed that this lack of clarity has hampered EA maturity across the Government.

Recommendation: IAC recommends that a coordinated presentation on the recommended approaches to developing departmental EAs, ensuring alignment of each constituent agency’s architecture with the department-level EA, be developed and broadly disseminated, including briefing agency heads and senior department and agency managers. Key areas of the approach might be collaborative governance, development of business cases across multiple agencies (lines-of-business), and identification of common/shared services to be implemented at the department level, among others. This could ultimately mean revising all of the past and current guidance into a comprehensive set of EA guides. It would also articulate the compatibility and complementary aspects of the current set of FEA reference models with previous EA methods and frameworks recommended and used. The guides could also address gaps in current guidance, such as how agencies can apply Model Driven Architectures and Service Oriented Architectures.

5. Need for Consistent and Complementary Maturity Models Multiple EA maturity models that overlap and do not consistently measure the goodness, the impact, and the completeness of EAs can be confusing and very frustrating to the staffs of agencies and departments that are trying to use them to improve EA maturity. The OMB and GAO EA Maturity Frameworks could be tuned to ensure they are consistent and complementary, if not mutually exclusive in their measured assessments.

Recommendation: IAC recommends that the GAO (EAMMF) and OMB (EAAF) maturity models be reviewed and normalized such that together they form a consistent yet non-redundant set of maturity metrics that measure the goodness of the EA methods and practices as well as the EA impact and traction toward agency modernization and transformation.

A-1

Appendix A — Description of the GAO EAMMF and the OMB EAAF

A.1 Overview of the GAO EAMMF To contribute to the evolution and maturity of the enterprise architecture discipline, in 2002, the GAO published version 1.0 of its Enterprise Architecture Management Maturity Framework (EAMMF) as an extension of A Practical Guide to Federal Enterprise Architecture, Version 1.0, published by the CIO Council. By arranging core elements from the practical guide into a matrix of five hierarchical stages and four critical success attributes, this framework provides a common benchmarking tool for planning and measuring enterprise architecture efforts. EAMMF Version 1.0 is made up of five stages of maturity, each of which includes an associated set of elements along with all the elements of the previous stages. In addition to the maturity stages, each core element is associated with attributes that are critical to the successful performance of any management function.

The same general structure was carried forward to Version 1.1 with additional criteria added and specifics as to achievement of levels of maturity. In April 2003, GAO published Version 1.15 of this framework, which reflected changes and additions that were based on comments they received on the initial version, as well as on their experiences in reviewing enterprise architecture programs at a number of Federal agencies in the interim. Version 1.1 reflecting the recommended changes and additions is shown in Figure A-1-1.

5 U.S. General Accounting Office, Information Technology: A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1), GAO-03-584G (Washington, D.C.: April 2003)

A-2

Figure A-1-1. EAMMF Version 1.1

Overall, Version 1.1 is more demanding (i.e., sets a higher standard) than Version 1.0 because Version 1.1 adds content and links the framework to related IT management guidance, such as our IT investment management framework. Key differences in Version 1.1 of the framework appear first in stage 2 and affect later stages either explicitly or implicitly. That is, some planning elements associated with stage 2 now propagate explicitly through later stages as plans are executed and architecture products are developed, completed, and implemented. For example:

Version 1.1 includes “performance” among the models that are needed to describe the “As-Is” and “To-Be” environments; these models are introduced into the planning elements in stage 2 and built upon as plans are executed; that is, as architecture products are developed and completed in stages 3 and 4, respectively.

A-3

Version 1.1 explicitly recognizes the need to address security in the descriptions of the “As-Is” and “To-Be” environments; this element is introduced in stage 2 and reiterated in stages 3 and 4.

Version 1.1 introduces the need to plan for metrics in stage 2 and to measure different aspects of enterprise architecture development.

Quality and use in stages 3, 4, and 5.

The next section summarizes and describes the OMB EAAF.

A.2 OMB EAAF Overview The OMB EA Assessment Framework (EAAF) was created to take a look at how the EAs at agencies are being utilized and are impacting the deployment of e-Government solutions and technologies to support citizen centric services. More so than the GAO EAMMF the self-assessment allows for some flexibility in the interpretation of the evaluation criteria. This is both a plus and a minus. It encourages the agencies to read between the lines in their assessments and allows some degree of inflation of the results. Overall, if the criteria are tightly applied to the letter of the intent, it is actually more difficult to achieve the higher maturity levels using the OMB Framework than using GAO’s. The plus is that it generally reinforces the progress made with higher average scores that don’t penalize the agency’s maturity a whole level if a single criterion is not achieved.

The OMB EA self assessment was designed to help each agency assess the capability of its EA Program and that it compliments the GAO EAMMF which assesses EA Program capacity.

The OMB EA Assessment Framework (EAAF) looks at the following two capability facets of an Agency’s EA Program:

Maturity of the Agencies EA, including the work product development and the capability of the Agency’s EA Program to provide specific investment recommendations as a part of the CPIC process

Integration of the Agency’s EA with the FEA, including the reflection of the reference models and good EA principles and the potentials for inter-Governmental collaboration on information technology solutions.

The OMB assessment framework primarily seeks to identify the extent to which the agency has developed an EA that supports agency program performance by influencing IT planning and investment decisions, rather than on the structure and products within and agency’s EA Program as is the case with the GAO EAMMF.

The EAAF contains four capability areas: Change, Integration, Convergence, and Business Alignment. There are several sub-areas within in each of the capability areas, and each is rated on its level of achievement. The levels are assessed at values of zero to five, where zero is “no evidence provided” and five is “IT planning is optimized through the EA.”

A-4

Business Value of Enhancing EA Maturity The best way for an EA Program to deliver a meaningful impact on the business/mission of the agency is to enhance the EA Program’s maturity level. To raise the maturity level, the EA Program must develop close collaboration with agency’s business partners, efficiently leverage the IT portfolio for focused results based on agency mission, and adopt best practices and prevailing Government guidance. Neither of these EA maturity frameworks would have been developed if there were not at least a very prominent relationship between the EA and EA Program maturity and the resultant impacts to the business/mission functions. The relationship may be somewhat delayed in that the impacts of an increase in EA maturity are generally delayed by one or more budget cycles after the improvements in the maturity level are achieved, but that is not unreasonable give the amount of work that may be required to achieve greater maturity. Again, the issue of metrics is important. It is important to try to determine in advance areas that EA is intended to impact in order to establish the criterion for measuring the relationships of increased maturity on programs and business initiatives.

Emphasis on Benefits at Each Level It is also important to track the achievement of benefits at each successive maturity level. In particular, as the maturity levels increase, using either framework, the returns and the impacts should be clearer and increasingly easy to articulate. If the benefits derived from increasing levels of maturity seem to level off or cause a higher cost/benefit ratio, then careful review of the EA Program may be in order. There are some organizations where the level of EA maturity may not need ever to reach a stable level 5 or the incremental cost of doing so is not justified in terms of potential impacts or results. It is not a given that every agency should continue to strive to achieve the highest levels on either framework, especially if it is only for the sake of having achieved it. Again, it must be emphasized that, in general, the higher the maturity level, especially for very large enterprises with large IT investment budgets, the greater the potential for benefits.

B-1

Appendix B — References 1. A Practical Guide to Federal Enterprise Architecture, Chief Information Officer

Council, Version 1.0, February 2001. (http://www.cio.gov/Documents/bpeaguide.pdf)

2. GAO-04-40, Information Technology: Leadership Remains Key to Agencies Making Progress on Enterprise Architecture Efforts, General Accounting Office, November 2003.

3. Information Technology: Enterprise Architecture Use Across the Federal Government Can Be Improved, United States General Accounting Office, Report to Congressional Committees, GAO-02-6, February 2002. (http://www.gao.gov/new.items/d026.pdf)

4. The Federal Enterprise Architecture Framework, Chief Information Officers Council, Version 1.1, September 1999. (http://www.cio.gov/Documents/fedarch1.pdf)

5. DoD Architecture Framework Version 1.0, DoD Architecture Framework Working Group, February 2004.

6. Architecture Alignment and Assessment Guide, Chief Information Officers Council, Version 1.0, October 2000. (http://www.cio.gov/documents/arch_align_assess_oct_2000.pdf)

7. E-Gov Enterprise Architecture Guidance (Common Reference Models), Chief Information Officers Council, Version 2.0, July 2002. (http://www.cio.gov/documents/EGov_ Guidance_July_25_Final_Draft_2_0a.pdf)

8. NASCIO Enterprise Architecture Development Toolkit v2.0.

9. Boar, Bernard, Constructing Blueprints for Enterprise IT Architectures, John Wiley & Sons, New York.

10. Spewak, Steven. Enterprise Architecture Planning, John Wiley & Sons, New York, 1992.

11. Cook, Melissa A. Building Enterprise Information Architectures: Reengineering Information Systems. Prentice Hall PTR, Upper Saddle River, NJ, 1996.

12. Zachman, John A. Zachman Framework For Enterprise Architecture, CD Rom, http://www.zachmaninternational.com