A Practical Guide to Federal Enterprise ArchitectureA Practical Guide to Federal Enterprise ArchitectureFEAPG_bfd707b3-3735-4e9a-aabb-a90cb4fd26eaTo achieve Agency missions through optimal performance of their core business processes within an efficient information technology (IT) environment _241fd166-6e91-42b3-afac-0209f1f69560To provide guidance to Federal Agencies in initiating, developing, using, and maintaining an enterprise architecture (EA). _2aa41323-27e3-4a21-bc15-a92b3cf12dafInitiationInitiate Enterprise Architecture Program_38ebf6c1-9f9f-422b-87ec-24659bedf9603The enterprise architecture is a corporate asset that should be managed as a formal program. Successful execution of the EA process is an Agency-wide endeavor requiring management, allocation of resources, continuity, and coordination. Agency business line executives should work closely with the Agency architecture team to produce a description of the Agency's operations, a vision of the future, and an investment and technology strategy for accomplishing defined goals. Experience shows that obtaining the needed cooperation among Agency executives is not an easy task. Creating an EA program calls for sustained leadership and strong commitment. This degree of sponsorship and commitment needs the buy-in of the Agency Head, leadership by the CIO, and early designation of a Chief Architect. Executive SupportObtain Executive Buy-in and Support _57f662d4-7000-4469-bb24-d595611f9c963.1Gaining executive commitment to any new initiative requires the development of a strong business case and a communications approach to effectively convey that business case. Since the concept of an EA is not intuitively understood outside the CIO organization, the CIO should create a marketing strategy to communicate the strategic and tactical value for EA development to the Agency Head, other senior Agency executives, and business units. Tasks: 3.1.1. Ensure Agency Head Buy-in and Support 3.1.2. Issue an Executive Enterprise Architecture Policy 3.1.3. Obtain Support from Senior Executives and Business UnitsManagement and ControlEstablish Management Structure and Control _28e61d13-be9d-42ca-b71a-ecb6bb6f5d9a3.2The organization structure should facilitate and advance the performance of EA roles and responsibilities. The roles of the EAESC, Technical Review Committee (TRC), and the EA Program Management Office are unique to the introduction of the EA process. Other roles, such as Quality Assurance (QA), Configuration Management (CM), Risk Management (RM), Security, and Evaluation are customary IT support roles. These roles are expanded to explicitly include EA-related responsibilities. EA roles should be evaluated based on the size of the organization, the complexity of the business and architecture, and other factors to effectively determine the correlation of roles assigned to personnel. In a large organization with complex business processes, an individual may be responsible for one specific role. In smaller Agencies or organizations, an individual may be assigned several roles and responsibilities. Tasks: 3.2.1. Establish a Technical Review Committee 3.2.2. Establish a Capital Investment Council 3.2.3. Establish an EA Executive Steering Committee 3.2.4. Appoint Chief Architect 3.2.5. Establish an Enterprise Architecture Program Management Office Activities and Products[Conduct] Enterprise Architecture Program Activities and [Develop] Products_e0e517c4-eeea-4e24-bb92-e5d19059369f3.3 Tasks: 3.3.1. Develop an EA Marketing Strategy and Communications Plan 3.3.2. Develop an EA Program Management Plan 3.3.3. Initiate Development of the Enterprise Architecture Process and Approach Define an Architecture Process and Approach _a214edcb-e05b-4798-a71e-efe14ff58d624The next step in the EA process is establishing an EA process and approach. The EA will be used as a tool to facilitate and manage change within the Agency organization. The scope and nature of the Agency and the changes to be made will dictate the scope and nature of the architecture to be developed. While the EA is an excellent tool to manage large and complex environments, the depth and detail of the EA needs to be tailored to the individual enterprise… Regardless, the scope of the enterprise architecture for the strategic planner and business owner views (as defined by the architecture framework selected) needs to encompass the entire enterprise. The agency will understand the relationships and dependencies among its lines-of-business and thus position itself to make informed decisions on how to approach defining EA depth and detail for these lines-of-business. Define an Architecture Process and Approach The first activity in this process is to determine the intended use of the architecture. It drives the rest of the EA development process. The subsequent activities describe how to scope, characterize, select EA products, build, and use the EA. Before actually developing the EA, an Agency needs to evaluate and select an architectural framework as guidance. This section describes several candidate frameworks currently used within the Federal community. The selection of a framework is contingent on the purpose of the EA and the products to be developed. Additionally, a toolset or repository for the EA development and use should be employed. The chosen tool should be commensurate with the products to be generated.PurposeDefine the Intended Use of the Architecture _c11fd62d-8d7b-4b5f-9aa2-7ca7fe189cc54.1Architectures should be built with a specific purpose in mind. It could be business process reengineering, systems acquisition, system-of-systems migration or integration, user training, interoperability evaluation, or any other intent. The purpose of the architecture is closely tied to the organization's Strategic Plan(s), legislation such as GPRA and Clinger-Cohen, and support of the capital investment process. Before an architect begins to describe an architecture, the organization determines the changes the architecture is intended to facilitate, the issue(s) the architecture is intended to explore, the questions the architecture is expected to help answer, and the interests and perspectives of the audience and users. One important practical consideration is determining the types of analyses that will be performed; i.e., knowing that the architecture may be used as input to specific models or simulations can affect what to include and how to structure the products. The purpose of the EA may, and likely will, evolve over time to meet new requirements. The Chief Architect should ensure that any such EA evolution does, in fact, meet the newly determined requirements. This will increase the efficiency of the architecture development and create greater balance in the resulting architecture. ScopeDefine the Scope of the Architecture_e6d82371-01b3-46b8-a690-431e9b39e8974.2It is critically important that EA development be approached in a top-down, incremental manner, consistent with the hierarchical architectural views that are the building blocks of proven EA frameworks, including the ones discussed later in this guide. In doing so, it is equally important that the scope of the higher level business views of the EA span the entire enterprise or agency. By developing this enterprise-wide understanding of business processes and rules, and information needs, flows, and locations, the agency will be positioned to make good decisions about whether the enterprise, and thus the EA, can be appropriately compartmentalized. Without doing so, scoping decisions about the EA run the risk of promoting "stove-piped" operations and systems environments, and ultimately sub-optimizing enterprise performance and accountability. Other considerations relevant to defining the scope of the EA include, but are not limited to: • Relevance of activities, functions, organizations, timeframes, etc. • Enterprise scope (intra-and inter-Agency domains) • Operational scenarios, situations, and geographical areas to be considered • Projected economic benefits • Projected business and technical risk areas • Projected availability and capabilities of specific technologies during the target timeframe (applies to target architecture only). Defining the scope leads the planners to project management factors that will contribute to these determinations, including the resources available for building the architecture as well as the resources and level of expertise available for analysis and design tasks. DepthDetermine the Depth of the Architecture_da1d0a11-8db1-4729-93fb-0155a2a823434.3Care should be taken to judge the appropriate level of detail to be captured based on the intended use and scope of the EA and executive decisions to be made using the EA. It is important that a consistent and equal level of depth be completed in each view and perspective. If pertinent characteristics are omitted, the architecture may not be useful. If unnecessary characteristics are included, the architecture effort may prove infeasible given the time and resources available, or the architecture may be confusing and/or cluttered with details that are superfluous. EA characteristics are influenced by the focus: whether primarily capturing the baseline vs. the target and vice-versa. It is equally important to predict the future uses of the architecture so that, within resource limitations, the architecture can be structured to accommodate future tailoring, extension, or reuse. The depth and detail of the EA needs to be sufficient for its purpose. ProductsSelect Appropriate EA Products_bd439129-a5ea-4282-97f6-1788a977d9014.4Essential products are those required for all architectures, while supporting products may be necessary to fulfill specific informational needs. Only those supporting products that portray the desired characteristics should be built. The required products should help formulate the selection of a framework and associated toolset. It is essential that the Chief Architect guide the construction of the technical content to meet the needs of the EA, especially in the desired level of detail needed in the work products. If the content is at too high a level of abstraction, it may not be sufficiently useful to guide projects and reviews. If the content is too detailed, it may be difficult to manage. Tasks: 4.4.1. Select Products that Represent the Business of the Enterprise 4.4.2. Select Products that Represent Agency Technical Assets FrameworkEvaluate and Select a Framework_05d72b43-da5d-4150-ae00-5c90a81729e74.5As each Federal Agency embarks on this stage of the architecture process, it must select an appropriate architectural framework. A number of well-established frameworks are successfully used throughout the Federal sector. Alternatively, an Agency may choose to develop its own framework, although the costs, benefits, and risks of doing so should be weighed against the risks of adopting or tailoring an existing framework. While Federal Agencies vary widely in their approach to architecture development and implementation, established frameworks permit comparisons and analyses across Agencies. Therefore, it is recommended that before an Agency develops a new framework (if an Agency has a mandated framework, it must be employed), it should investigate the use of other existing Federally developed frameworks. Three Federally sponsored (and commonly accepted) architectural frameworks are used as candidate frameworks and for descriptive purposes within this EA guide. These contain essential and supporting products, and promote development of architectures that are complete, understandable, and integratable. The organizations that developed these frameworks continue to tailor them to ensure parallel precepts, principles, and methodologies. The frameworks are: • Federal Enterprise Architecture Framework (FEAF) • Department of Defense (DoD) Command, Control, Communications, Computer, Intelligence, Surveillance and Reconnaissance (C4ISR) Architecture Framework • Treasury Enterprise Architecture Framework (TEAF). Other EA frameworks exist and have been used in Government programs (e.g., Department of Agriculture's framework and the National Institute of Standards and Technology [NIST] framework). This guide does not address these other frameworks because most organizations have standardized on the FEAF, C4ISR, and TEAF for EA development. In addition to EA frameworks, many processes exist that can be used to support framework development, such as the Department of Energy's corporate systems information architecture roadmap for IT systems implementation. Since a notional process is described in this guide, other Federal Agency EA processes are not discussed. The use of an EA framework ensures uniformity and standardization when migrating and integrating information systems. The selected framework will depend on the intended use, scope, and characteristics of the architecture to be developed. ToolsetSelect an EA Toolset _47a24a7a-fc50-4296-9a4d-b9489855c1f44.6To increase the usefulness of any architecture, it is important to maintain the EA within an interactive architectural tool. Fortunately, there are many automated architecture tools available on the market today. The choice of tool should be predicated upon the organization's needs based on the size and complexity of its architecture. The Chief Architect and architecture core team may use the Office suite of tools (e.g., Microsoft's PowerPoint and Word) and/or modeling tools (e.g., Rational Rose by Rational Corporation, Systems Architect by Popkin, or Framework by Ptech). There are toolsets available from leading vendors that can provide alignment with the chosen framework and recommended products. Tool criteria should be determined based on the intended use of the architecture, scope, levels of integration desired, and other factors. Table 3 lists candidate topics to aid in the selection of tools. The list can be tailored to a specific set of requirements for tool selection. One tool will probably not meet all requirements. Therefore, a tool suite or combination of tools will be needed. The work products should be maintained in several different types of media such as hardcopy documentation (briefings and reports), electronic files on CD-ROM, HTML documents on the web, and other EA Computer Aided Software Engineering (CASE) tools and development tools that provide a relational database management system. DevelopmentDevelop the Enterprise Architecture _83881665-2597-4e2e-a47f-def52d71f1205The next step is to build the architecture products based on the purpose of the architecture and the chosen framework. This consists of the essential products, supporting products (if needed), and individually defined products (e.g., briefing charts, interview notes) driven by architecture-specific needs and processes. To facilitate integration with other architectures, it is crucial to include all depictions of relationships with applicable external components, that is, entities outside the Agency. It may be useful, resources permitting, to conduct some proof-of-principle analyses at various stages of architecture development. For example, one could conduct trial runs of the EA development process using carefully selected subsets of the areas to be analyzed. The architecture core team should ensure that the products are consistent and properly interrelated. If the products are not applied and populated uniformly, the Chief Architect and architecture core team will be unable to compare or contrast the products or perform thorough analyses. Regardless of the scope and complexity of the views to be developed, the architecture core team should apply a consistent approach to developing the baseline and target architectures. The selected approach should include (1) a data collection phase, (2) preliminary product generation, (3) review and revision stages, and (4) publication and delivery of the architecture products to an appropriate repository. Information CollectionCollect Information _fda8c917-0b61-435a-a867-e51a82d1d1475.1The first step in the build approach is to identify and collect existing products that describe the enterprise as it exists today and as it is intended to look and operate in the future. Data collection is the crucial, initial effort involving review of documentation, staging of training sessions, and interviewing SMEs and domain owners. All appropriate collected information and products should be placed in a centralized electronic EA repository. In the case of the baseline architecture, sample products to be collected include: • Current business functions and information flows • Data models • External interface descriptions • Existing application and systems documentation • Technical designs, specifications, and equipment inventories. In the case of the target architecture, sample products to be collected include: • Proposed business processes and information flow • Strategic plans • Modernization plans • Requirements documents. Many of these products may not exist or may not accurately represent the current baseline or proposed target environments. If documentation is missing, the architecture core team should develop a strategy to create the needed documentation or decide whether to make the investment. In this case, the interviewers will have to rely on business or system SMEs concerning the purpose and scope of the activity and the expectations for their participation. After collecting a sufficient amount of this data, work can begin on creating the EA products and populating the EA repository. Ideally, preliminary, draft architectural products can be generated at this time without in-depth SME involvement. With the development of strawman products, the architects can then conduct a series of stakeholder brainstorming sessions and in-depth SME interviews to solidify the products. The Chief Architect should review and validate the proposed interview list and ensure SME participation via communications with the domain owners. The marketing and buy-in process described in Section 3 should have set the stage for this participation. It may be useful to record these interviews for future reference. Always follow up to ensure that interview information is interpreted correctly. Once the initial interviews are completed, the architecture core team extracts information from the interviews and then refines the existing products within the EA repository. Populate RepositoryGenerate Products and Populate EA Repository_c4bd376a-cdfd-40b6-a8c4-5a44be710d5a5.2Some products may be created during the first iteration of the EA development process while others may be created during later iterations depending on the framework, process, and chosen methods. In addition, depending on whether the baseline or the target is being created, various factors will affect the approach taken, the focus of the products, and the order in which products are generated. The information contained in the EA is usually expressed as a collection of interdependent products. The volume of information, as well as the presentation style of that information is often too great for a user to quickly comprehend. Also, users often focus on their particular area of concern and can easily overlook critical dependencies that their processes or assets may have on other processes and organizations in the enterprise. Therefore, providing electronic links among the interdependent information can highlight the interdependencies and greatly improve the understandability of the information. Change control is also significantly streamlined -- by establishing the links among information at its origin, impact analysis is facilitated and change proposals can be evaluated more readily. Some agencies document and distribute their EAs in the form of web sites and CD-ROMs, thus easing readability, access, and distribution. The process of getting the enterprise from where it is today to where it wants to be in the future needs formal thought and that focuses on optimizing enterprise-wide performance and accountability. This thought process is documented with the Agency's strategic plan. This document defines the mission and long-range objectives of the Agency and relates to plans for business reengineering and systems modernization. Together these products should drive the top-down sequence of EA product development. Tasks: 5.2.1. Build the Baseline Architecture 5.2.2. Build the Target Architecture 5.2.3. Review, Validate, and Refine Models Sequencing PlanDevelop the Sequencing Plan_9987d844-c2c2-4e5d-85b5-159aa758a49a5.3The changes needed to transition from the current state of the enterprise to the goals and conditions expressed by the target architecture cannot be achieved in a single quantum step. Evolving the enterprise from its baseline to the target architecture needs multiple concurrent interdependent activities and incremental builds. The best way to understand and control this complex evolutionary process is by developing and maintaining a systems migration roadmap or sequencing plan. The sequencing plan should provide a step-by-step process for moving from the baseline architecture to the target architecture. The sequencing plan may be supported by a set of architecture products, similar to the baseline and target architecture products, generated for several intermediate points in time between the baseline and target environments. The succession from one point in time to the next, and on to the target timeframe, establishes a migration sequence. Because the sequencing plan represents the current environment, as well as the development programs that are both planned and under way, it becomes a primary tool for program management and investment decisions. To remain current and to support continued coordinated improvements across the enterprise, the sequencing plan should be maintained and updated as time and circumstances dictate. In addition to specific development requirements for the new components in the target architecture, development of the sequencing plan should consider a wide variety of inputs, including: • Sustainment of operations during transition • Existing technical assets and contractual agreements • Development programs currently underway • Anticipated management and organizational changes • Business goals and operational priorities (including legislation and executive directives) • Budget priorities and constraints. Tasks: 5.3.1. Identify Gaps 5.3.2. Define and Differentiate Legacy, Migration, and New Systems 5.3.3. Planning the Migration Finalize ProductsApprove, Publish, and Disseminate the EA Products_5dd8b1fc-595d-46d6-9d0f-e8837c7b3c725.4Upon verification and validation of the architectural products, the Agency's management should approve the overall architecture. This step includes approval by the EAESC, the CIO, Chief Architect, and Agency executives up to and including the Agency Head (e.g., Secretary, Commissioner, or Directors). Each Agency incorporates its own approval processes for this cycle. The Agency executives, managers, and architects should have ready access to the information in the EA. By distributing the information in electronic Read-Only format, executives and managers can use the information directly while the controlled baseline is maintained. Executives and managers should use the information for more than just reference purposes√ incorporating it into communications, briefings, and directives. Application architects use the information to analyze artifacts against their own reality and identifying opportunities for improvements. Enterprise architects use the information to apply "what-if" analysis against the baseline. In addition, Read-Only format versions of the EA limit the number of staff able to make changes and modifications to the products, easing the burden of change management on the enterprise as a whole. The EA documents extensive information about the Agency. Careful consideration must be made to the distribution of that information. Although it is possible that an EA may not have any confidential information, the aggregation of the information may comprise a security risk. In the wrong hands, the compilation of enterprise information in the EA could create a vulnerability to the Agency by providing sufficient information for infiltration and disruption. Some of the information (or combinations thereof) may need to be controlled and accessed on a "need-to-know" basis (e.g., network models, critical performance factors, system interfaces, etc.). The architecture core team considers what classes of EA users will need what information: contractors, management, and Agency staff typically focus on particular areas of the enterprise, and thus may only need particular subsets of the EA. An EA that includes a comprehensive view of the details of the Agency systems and infrastructure could be organized in levels of detail and distributed in a tiered format corresponding to security clearances and the need to know. Architecting is an ongoing, iterative process requiring regular modification and maintenance. Whenever the EA changes, it is imperative to update the architecture models. UsageUse the Enterprise Architecture_a189b589-5c66-4aa4-a6e8-12cb699658746Using the EA to implement new projects provides a positive impact on the enterprise. If the EA is not successfully used, the entire development effort to this point is for naught. In this section, the emphasis shifts to integrating use of the EA across multiple activities and organizational groups. Success depends on active management, proactive architects, and receptive project personnel. It also depends on integrating the EA process with other enterprise life cycle processes, particularly the CPIC process. Establishing the EA captures the state of the enterprise and the plan for its future -- literally a snapshot of the enterprise and its plans for improvement. For the EA to provide the strategic information asset base as intended, it should become a crucial tool for decision support and communication in the mainstream of daily business operations. Accepting and applying this asset in the Agency's operational paradigm is a technical and cultural challenge. The EA is managed as a program that facilitates systematic agency change by continuously aligning technology investments and projects with agency mission needs. The EA is updated continuously to reflect changes in operational and investment priorities that may arise due to legislation, budget constraints, or other business drivers. It is a primary tool for baseline control of complex, interdependent enterprise decisions and communication of those decisions to agency stakeholders. The sequencing plan provides a strong guide for agency decision-makers to use as they consider proposed projects. If a project is not represented in the sequencing plan, it should either be denied funding, since it is not aligned with the agency strategy as embodied in the EA, or it should be granted a waiver if it is a legitimate deviation driven by valid changes in the agency's environment which have not yet been reflected in the EA. It should be noted that it is crucial that the EA represent the current agency strategies and imperatives as closely as possible, since any lag in the EA may constrain the agency's ability to effectively execute its mission until a waiver is issued or the EA is adapted. In cases where a waiver is granted, the cause of the waiver should be examined and appropriate changes to the EA considered if the cause represents a valid and ongoing gap in the EA. IntegrationIntegrate the EA with CPIC and SLC Processes_80f8d4c3-4645-4d91-a1f2-eccc83adedb56.1Investment management and systems development/acquisition are closely linked with the EA processes. The agency should only make investments that move the agency toward the target architecture and these investment decisions should comply with the sequencing plan. The EA, CPIC, and SLC (systems life cycle) processes are integrated to best suit the agency's particular organization, culture, and internal management practices. Certain basic relationships exist between these functions and they have a common focus: the effective and efficient management of IT investments. The dialogue across CPIC, SLC, and EA processes is continuous, cooperative, and facilitated by agency commitment to an integrated process. Details of this relationship between management processes and the capital planning and investment control process are discussed in the Architecture Alignment and Assessment Guide and the Smart Practices in Capital Planning document. GAO«s Information Technology Investment Management Tasks: 6.1.1. Train Personnel 6.1.2. Establish Enforcement Processes and Procedures Framework provides a structured approach to IT investment management that is consistent and integrated with the principles of good EA and system life cycle practices. Each agency designs its own CPIC process for structuring budget formulation and execution to ensure that investments consistently support strategic goals. All IT projects should align with the agency mission and support agency business needs while minimizing risks and maximizing returns throughout the investment's life cycle. The target architecture and the sequencing plan provide information for the three phases of the CPIC process. In the Select Phase, the agency determines if the proposed investment meets business decision criteria. To assess the business alignment of the proposed investment, decision makers use, for example, the business case, acquisition plan, and the project plan to determine whether the proposed investment aligns with the sequencing plan and target architecture. In the Control Phase, decision makers monitor business and technical compliance as demonstrated in, for example, the updated business case, system architecture, systems design, and test program. In addition, the investment should be monitored to ensure continuing alignment with the agency's strategic and business goals, which may shift over time. In the Evaluate Phase, the decision makers perform a final assessment to determine technical and strategic compliance with the EA. The results, including findings of noncompliance, should influence strategic planning for new business and IT projects, which could then lead to changes in the EA. ExecutionExecute the Integrated Process_1923b79f-aec1-4383-8240-7ad9e63c540e6.2Progress toward the target architecture is accomplished through programs and projects. New and follow-on projects are (1) initiated and selected, (2) executed and controlled, and (3) completed and evaluated. The following sections show the information flow for each of these three CPIC phases with emphasis on how the EA supports the whole process. Tasks: 6.2.1. Initiate New and Follow-on 6.2.2. Execute the Projects 6.2.3. Complete the ProjectOther Uses[Develop] Other Uses of the EA _52b2f97a-d904-42d5-8fe0-7bebc46e354d6.3The EA provides guidance and source information for requirements analysts, designers, engineers, and test planners to reference and build upon material executing their responsibilities. The following are examples of uses of the EA outside the normal project cycle: • Even if an agency is not involved in a major IT upgrade, the EA is a resource for managing inventory, routine maintenance, and queries. Analysis of the baseline architecture can identify opportunities for consolidating network services, floating or site software licenses, and economies of scale for equipment and services. • The agency can use the EA as a training aid, drawing on its graphics and descriptive material for instruction in the business of the agency or in the technology that is in use or planned. • Investigative initiatives and proofs-of-concepts should be performed using the EA as a reference. The criteria for EA compliance should be considered, but not mandated, in such efforts. Non-enforcement allows pursuit of innovations that could change the EA, but alignment and impacts of architecture deviations should be included with the results of the experiments. • Agencies may fund small, low risk projects outside of the CPIC. Program/project managers should still rely on the EA for guidance for the business solution, architectures, requirements, and design of their effort. Compliance with the EA will facilitate integration into the enterprise, and the baseline architecture should be kept current with their products. • O&M projects rely on the baseline architecture for context. The O&M priorities and decisions may be influenced by the sequencing plan and target architectures. For example, a planner may conclude that soon-to-be-retired IT systems are more economical with minimal O&M support. MaintenanceMaintain the Enterprise Architecture_4cf79d0c-c85a-490a-b15d-8edae473790b7The EA is, by definition, a set of models that collectively describe the enterprise and its future. Its value to the business operations is more than just IT investment decision management. The EA is the primary tool to reduce the response time for impact assessment, tradeoff analysis, strategic plan redirection, and tactical reaction. Consequently, the EA must remain current and reflect the reality of the organization's enterprise. In turn, the EA needs regular upkeep and maintenance -- a process as important as its original development. Maintaining the EA should be accomplished within the enforcement structure and configuration control mechanisms of the organization. EA maintenance is the responsibility of the CIO, Chief Architect, and the EAPMO. Using a system of oversight processes and independent verification, the architecture core team periodically assesses and aligns the EA to the ever-changing business practices, funding profiles, and technology insertion. The EA should remain aligned to the organization's modernization projects and vice versa. The management controls to accomplish EA maintenance are the same ones established to initiate the program and to develop the EA. EvolutionMaintain the Enterprise Architecture as the Enterprise Evolves_78416d6f-a97e-406f-b70b-f5da10aa4fee7.1If the EA is not kept current, it will quickly become "shelfware" -- yet another well-intentioned plan for improving the enterprise. Perhaps even more damaging, if the EA fails to embody the agency's most current strategy it may limit the organization's ability to meet its goals and achieve its mission. The EA necessitates a specific organizational and process structure that will ensure the currency of EA content over time. The EA should reflect the impact of ongoing changes in business function and technology on the enterprise, and in turn, support capital planning and investment management in keeping up with those changes. Consequently, each component of the EA -- baseline architecture, target architecture, sequencing plan, and all the products that constitute them --need to be maintained and kept accurate and current. Tasks: 7.1.1. Reassess the Enterprise Architecture Periodically 7.1.2. Manage Products to Reflect RealityModificationsContinue to Consider Proposals for EA Modifications _0e3cd7cd-2ac0-4927-bfeb-1d86a777002c7.2While the enforcement process helps to ensure that the EA guidance is followed, it is unreasonable to assume that new business priorities and technologies, funding issues, or project challenges will not require modification to the plans, baselines, and products incorporated in the EA. Emerging technologies continue to necessitate changes to the enterprise. Many of the considerations for changes to the EA are the same considerations that needed to be addressed during its development. Also, the architectural principles need to be continuously addressed. Proposals for modifying the architecture should address the following questions among others: • How does the proposed modification support the organization in exploiting IT to increase the effectiveness of its organizational components? • How does it impact information sharing and interoperability among organizational components? • What are the security implications? For example, will the modifications need certification of enhanced systems? • Does the proposed modification use proven technologies and conforming COTS products to satisfy requirements and deliver IT services? Are these technologies and related standards in the industry mainstream, thereby reducing the risk of premature obsolescence? • Does the acceptance of this proposal position other standards or products for obsolescence? If so, identify them. • What is the impact on the organization and sub-organizations if the proposal is not accepted? What is the result of the cost-benefit analysis? • What external organizations or systems will be affected? What action will they have to take? • What is the estimated overall programmatic cost of the proposed changes including changes to the EA and/or redirection of dependent projects? • What alternatives have been considered and why were they not recommended? • What testing, and by whom, should be completed for implementations that will result from acceptance of the proposal? • What is the recommendation of the enterprise change control board? Proposals requesting modifications to the EA need to explicitly address these issues. The proposal should be presented to and reviewed by the TRC (for review by architectural team and SMEs) and passed to the EAESC with a recommendation. In cases where the EAESC cannot reach a consensus, a working group may be tasked to investigate and propose recommended actions. Control and OversightContinuously Control and Oversee the Enterprise Architecture Program_94583d76-4f24-4841-90f7-252b03e1130d8The purpose of EA control and oversight is to ensure that the EA development, implementation, and maintenance practices defined in this practical guide and the related EA guidance referenced in this guide (e.g., EA frameworks) are being followed, and to remedy any situations or circumstances where they are not and action is warranted. Control and oversight is a continuous, ongoing function performed throughout the EA life cycle process. Effective control and oversight is a key to ensuring EA program success. Through it, information is gathered for accountable decision makers to permit awareness of whether effective EA development, implementation, and maintenance activities are being performed and EA program goals are being met on schedule and within budgets. To do so, the EAESC, the CIO, and the Chief Architect should be vigilant in measuring and validating that the EA process and product standards defined and referenced in this guide are being performed. To do less, diminishes the probability of program success. Total participation makes continuous improvement everyone's responsibility. The EA's central role in enterprise evolution provides an excellent opportunity to solicit feedback. Lessons learned should be collected from the operational business owners, EA teams, project development teams, and investment management teams. Once the baseline EA has been developed, the architecture team should take stock of the lessons learned and communicate them to their colleagues and participating senior management in order to utilize them in improving the process or the EA itself. In addition, feedback and lessons learned should be sought from other Agencies, professional organizations, commercial corporations, and consultants.Management Controls Ensure Necessary EA Program Management Controls Are In Place and Functioning_a823db35-ca3c-4ebe-a11a-62d31b96e7288.1In Section 3 of this guide, accountability for the EA program was assigned to the EAESC, the CIO, and the Chief Architect. Also, throughout this guide, EA process and product standards or controls that should be used to produce a complete, well-defined, and useful EA have either been defined or referenced. (For example, the guide specified the need for a program management plan to detail what will be done, when, and at what cost, as well as the need to establish management support functions, such as configuration management, risk management, quality assurance, change control, etc. Also, the guide references EA frameworks and tools that help define the content of the EA.) Knowing the extent to which these controls are being implemented on a continuous basis is crucial to keeping the program on track. To do this, EAESC, the CIO, and the Chief Architect will respectively seek reports (oral and written, routine and ad hoc, formal and informal) and conduct first hand reviews to obtain the appropriate level of visibility into what is occurring on the program vis-à-vis what is expected. It is the responsibility of these accountable entities to define what information they need, when and how often they need it, what the form and content of the information should be, whether it should independently validated or not, etc. Through such information, the EAESC, the CIO, and the Chief Architect can position themselves to know whether established program management controls are in place and functioning. Unmet ExpectationsIdentify Where EA Program Expectations Are Not Being Met_4c3172e4-11e5-47ab-bcb5-10ccdab1b1b08.2Through their respective reports and review activities, the EAESC, the CIO, and the Chief Architect will be able to identify what, if any, EA program expectations are not being met. For example, if risk management has been effectively implemented, program risk lists should be regularly generated that assign a risk level based on impact and probability, define risk mitigation strategies, report on progress in implementing these strategies, and whether the progress being made is successfully addressing the risk item. Also, periodic configuration audits should be conducted to ensure that EA configuration items are being defined, controlled, and reported. The EAESC, CIO, and Chief Architect can also rely on independent reviews by the quality assurance function or a verification and validation agent to advise them of deviations from expectations. These deviations may be program management plan-related, such as omission of work tasks, delays in the completion of work tasks, or additional costs to complete work tasks; or they may be management function-related, such as not following change control procedures, not adhering to the selected EA framework, or not engaging SMEs and domain owners within business and technical areas. DeviationsTake Appropriate Actions to Address Deviations_cf288d05-feb3-4ae9-bd34-94c3b8ed09c48.3Management should take quick and decisive actions to correct problems in light of established priorities. Examples of actions include infusion of additional resources (people, tools, or money), establishment of contingency plans, and redefinition of EA purpose and scope, introduction of missing or strengthening of existing control mechanisms, and increased oversight. Any changes to the plans, projects, and/or architecture content to address deviations should be captured in an appropriate documentation trail, and should be justified on the basis of costs, benefits, and risks. Changes should be processed through established change control processes and board authority. The change documentation should characterize the problem, solution, and alternatives chosen and rejected in light of established priorities. Improvement Ensure Continuous Improvement _94a7d34e-c197-4af2-9aeb-c2c796006f7b8.4[T]he key success factors of Total Quality Management (TQM) [are] the same key success factors for enterprise architecting: • The EA process should be a key support element of the operations of the Agency, and should assist the operations function in performance of its customer-focused mission. • Successful enterprise architecting is not simply a function of the IT organization, but needs the total enterprise participation. • Effective enterprise architecting needs "societal networking," that is, internal and external communication and sharing of lessons learned. The optimum EA process is not a single, one-time event, but is continuous and thus offers the opportunity for continuous improvement. This necessitates ongoing control with monitoring, reassessment, and refinement. As the discipline of enterprise architecting enters the mainstream of Agency operations, lessons can be learned from processes that worked and those that did not work, and from external organizations. 2001-02-292010-02-08http://www.cio.gov/Documents/bpeaguide.pdfArthurColman (www.drybridge.com)colman@drybridge.com