• Main

• Training Policy Handbook

  • Site Map

  • Introduction

  • Summary of the Legal Foundation of Training

  • Legal Foundation for Training

  • Legal References by Subject Area

• Training Information

• Policy Guidance

• Publications

• Information Technology Exchange Program

  • Background

  • Program Highlights

  • General Requirements

  • Eligibility

  • Agency Plans

  • Termination of Details

  • Written Agreements

  • Assignments to Small Business Concerns

  • Agency Reporting Requirements to OPM

  • Other Reporting

  • Links

• Individual Learning Accounts

• HR Community Links

• Contact Us

• Help

Table of Contents - Appendices

Report On The Establishment Of A Governmentwide Information Technology Training Program

APPENDIX A - THE FEDERAL CIO COUNCIL'S UPDATE TO THE CLINGER-COHEN CORE COMPETENCIES

Updating the Clinger-Cohen Competencies for
Enterprise Architecture

Executive Summary

The Federal Chief Information Officers (CIO) Council has been empowered to regularly update the Clinger-Cohen competencies with refreshed views of industry and federal IT practices. In recent years, the success of the Federal Enterprise Architecture Framework (FEAF) and the Federal Enterprise Architecture Program Management Office (FEAPMO) in promoting the pervasiveness of enterprise architecture initiatives clearly demonstrates that Enterprise Architecture (EA) is one of the most critical forces driving Government-wide interoperability, shaping initiatives, and fostering consolidation and reuse of business processes, systems, and technology across the federal IT landscape. The primary purpose of this document is to provide sufficient justification and detail for adding a new competency, Enterprise Architecture, to the Clinger-Cohen competencies that will reflect critical skills and definitions of the components of Enterprise Architectures, identify key working relationships, and describe how EA projects are typically structured and staffed across the Federal Government. The content of this paper also proposes competencies and associated learning objectives for EA across federal agencies in Appendix A.

A streamlined Federal Government with more federal-wide solutions and systems, and reduced IT acquisition and maintenance costs, is contingent upon a well-trained IT federal workforce capable of managing the design, integration, and fielding of IT technology. The roles played by each agency's Enterprise and Solutions Architects will be key to the successful implementation of the Federal IT and E-Gov Initiatives. Enterprise Architects design the information and technology frameworks to implement the agency's IT strategic vision and therefore must possess both the technical and managerial expertise required to achieve the target architecture. Standardization of terminology and establishment of baseline federal EA competencies will facilitate Enterprise Architecture efforts across the Federal Government.

Background

What is Enterprise Architecture?

Enterprise Architecture (EA) links the business mission, strategy, and processes of an organization to its IT strategy. It is documented using multiple architectural models or views that show how the current and future needs of an organization will be met. By focusing on strategic differentiators and working across the enterprise, there is a unique opportunity to create leverage and synergies and avoid duplication and inconsistencies across the enterprise. The key components of the EA are:

• Accurate representation of the business environment, strategy and critical success factors
• Comprehensive documentation of business units and key processes
• Views of the systems and data that support these processes
• A set of technology standards that define what technologies and products are approved to be used within an organization, complemented by prescriptive enterprise-wide guidelines on how to best apply these technology standards in creating business applications.

In essence, the EA defines the target architecture at a given point in the future that is necessary to support the business mission and strategy of an organization. The box below provides two definitions of an EA by the Federal CIO Council and the Meta Group, an IT consulting firm.

"Enterprise Architecture is a strategic information asset base, which defines the business mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs." Federal CIO Council "Enterprise Architecture is the holistic expression of an organization's key business, information, application and technology strategies and their impact on business functions and processes. The approach looks at business processes, the structure of the organization, and what type of technology is used to conduct these business processes." Meta Group, Inc.

Enterprise Architectures typically includes a baseline architecture, a target architecture, and a transition plan for moving from the baseline to the target. The target architecture components may be justified using business cases developed by the enterprise architecture team. At a minimum, EA is documented using the following architectural models:

Business architecture - addresses the business mission, strategy, line of businesses, organization structure, business process models, business functions, etc.
Information architecture (also known as data architecture) - defines what information needs to be made available to accomplish the mission, to whom, and how.
Application architecture (also known as functional architecture) - focuses on the application portfolio required to support the business mission and information needs of the organization. At the next level of detail, it addresses the common business components and business services that can be leveraged by multiple applications.
Technology architecture - defines the technology services needed to support the application portfolio of the business. It also documents the software, hardware, and network product standards.

John Zachman is the world's leading expert on Enterprise Architecture, and author of the internationally renowned "Framework for Enterprise Architecture", which has set the standard on how an organization should develop, implement, and maintain an Enterprise Architecture. Additional work by Steven Spewak and others, as well as the Federal CIO Council itself, has resulted in ever increasing maturity of enterprise architecture efforts across the commercial sector and the federal government.

EA Across the Federal Government

Executive Order 13011, Federal Information Technology, established the Federal Chief Information Officers (CIO) Council as the principal inter-Agency forum for improving practices in the design, modernization, use, sharing, and performance of Federal information resources. The Clinger-Cohen Act of 1996 assigned the CIOs with the responsibility to develop information technology architectures (ITAs). The Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, November 28, 2000, requires agencies to ensure consistency with Federal, agency, and bureau Enterprise Architectures and to demonstrate consistency through compliance with agency business requirements and standards.

In support of these mandates, the Federal CIO Council developed and published the Federal Enterprise Architecture Framework (FEAF) in September 1999, to promote shared development for common Federal processes, interoperability, and sharing of information among the Agencies of the Federal Government and other Governmental entities. In serving the strategic needs and direction of the Federal Government, the Federal CIO Council seeks to develop, maintain, and facilitate the implementation of the top-level Enterprise Architecture for the Federal Enterprise. The Framework consists of various approaches, models, and definitions for communicating the overall organization and relationships of architecture components required for developing and maintaining a Federal Enterprise Architecture.

In response to the Clinger-Cohen Act of 1996, and the FEAF, most federal agencies have initiated efforts to create EA awareness or to build an EA management foundation. The scope of these EA projects has ranged from functional area or sub-agency architectures (Zachman verticals) to agency-wide definitions (Zachman horizontals) that extensively leverage process and technology commonality within an agency.

In 2001, The President's E-Government Taskforce identified 24 Presidential Priority E-Gov initiatives that are potentially transformational in nature and offer the opportunity to simplify, unify and consolidate processes used by the Federal Government. These Initiatives will enable the Federal Government to better serve the public, promote interactions across governmental organizations, and perform business activities while continuously improving internal efficiency and effectiveness. The OMB's Federal Enterprise Architecture Program Management Office (FEAPMO) has continuing stewardship responsibilities for these E-Gov Initiatives, as they become the first real instantiation of the Federal Enterprise Architecture (FEA). Whereas the Federal CIO Council defined a framework for the FEA in 1999, the FEAPMO, with the support of the Federal CIO Council, is now in the process of developing a Federal Enterprise Architecture.

FEAPMO is developing five reference models: performance, data, services components, technical, and business. Working jointly, these models will drive standardization and cross agency collaboration opportunities. They will also provide a structured approach to analyze overlapping functions, identify similarities across agencies, and provide a means by which agencies can leverage best practices from each other - promoting reuse in the government.

The FEA is intended to provide a consistent, industry-aligned approach for defining and communicating the components needed to cost and plan E-Gov programs - both the 24 Presidential Priority E-Gov Initiatives and other IT initiatives across the Federal Government. It is based on the business requirements derived from the priority initiatives as well as system engineering design best practices. Such an approach is essential if the Federal Government is to 1) leverage information technology investments and avoid unnecessary duplication of infrastructure and major components, 2) link business processes through shared, yet sufficiently protected information systems, and 3) leverage disparate business processes, services and activities that are located outside Agency boundaries.

Enterprise Architects and Solutions Architects

At its core, Enterprise Architecture and Solutions Architecture (SA) differ primarily in business scope and the breadth of business and technical issues analyzed. While the Enterprise Architect studies and defines solutions for the entire enterprise or agency, the Solutions Architect is generally concerned primarily with studying and defining solutions for a single system, department or solution area within an agency. Both Enterprise and Solutions Architects deal with the same fundamental business and technology issues: alignment with core agency business strategies, business process simplification and the implementation of information technology that enables the realization of key business objectives. However, the Enterprise Architect is concerned with business issues, process optimization and technology standardization at an agency level or, in the case of the FEAPMO, across the Federal Government at large. The Solutions Architect is concerned with these same issues, but on a smaller scale and within the scope of a single project or system.

Enterprise Architects and Solutions Architects most often do not operate independently, however. Enterprise Architects often help guide the implementation of EA standards in the development and deployment of targeted solutions and Solutions Architects often play key focused technical and business roles on EA projects and ongoing initiatives. Solutions Architects often seek the guidance of Enterprise Architects to help interpret EA components and Enterprise Architects may act as internal consultants to the Solutions Architecture team. This interdependence and dynamic role shifting occurs normally in the life cycle of EA and solution development.

Historically, Solutions Architects have been classified in a variety of ways in the commercial and government sectors. Most typically, a System Architect would lead the design of a system or solution. In turn, the system architect would be responsible for a group of specialized architects such as the data, software, network, security and hardware architects. Some projects created a role called Chief Solutions Architect, supported by architects classified as business, application, systems management, infrastructure, and network architects. Many other variations on architect and architecture classification and nomenclature exist to this day. Standardization of the classification of Solutions Architects across the Federal Government would reduce much of the current confusion and facilitate both enterprise architecture and solutions architecture efforts.

Organizational Relationships of a Typical Enterprise Architecture

The actual staffing and management within a public or private organization would be based on the complexity of its IT projects and the fluidity of its subject matter experts collaborating on multiple projects. It is acknowledged that there are no "hard core" standards today regarding the organization and execution of EA projects. However, a review of EA initiatives across the Federal Government and private industry will overwhelmingly support the working relationships shown below. EA projects need to leverage the best agency talent available for each role, so multiple roles can be filled by a single architect and, conversely, a single role can be performed by multiple architects.

At the Enterprise Architect level, roles and responsibilities generally remain static; however, the Solutions/Project Architects' roles change, depending on the scope and complexity of a particular project. A Chief Solutions Architect and various subordinate Solutions Architects may be called upon to provide specialized expertise for larger scaled projects. On the other hand, when implementing a small-scale solution for a particular department, Enterprise Architects may use a single Solutions Architect with specialized knowledge in the toolset to be implemented.

Although Enterprise Architects guide the overall architecture and Solutions/Project Architects implement the solutions, both groups work collaboratively to share direction, knowledge, and resources.

Each of the major roles and responsibilities is described below:

Chief Enterprise Architect. The Chief Enterprise Architect has overall responsibility for all of the enterprise architectures and their ability to meet agency needs. This is an architectural design role, rather than a management responsibility. Key responsibilities include:

• Define an enterprise-wide documentation standard for architectures.
• Define an enterprise-wide set of policies and principles for architectures.
• Keeps appraised of emerging technologies to evolve enterprise IT architecture with more efficient and effective standards.

Enterprise Architect. The Enterprise Architect is responsible for the definition and use of one of the enterprise architectures (Business, Information, Applications, or Technology). The Enterprise Architect must have a broad view of the entire organization/agency. This person is a leader in business strategy, vision, and overall information technology systems and architecture. Key responsibilities include:

• Develop and maintain the architecture, working with the other enterprise architects to ensure consistency and completeness, and seeking approval for changes from the Chief Enterprise Architect, if not the same person/office.
• Document the enterprise architecture using approved documentation standards.
• Define and maintain policies and principles relevant to their specific architecture.
• Perform vitality process to ensure architecture continues to reflect agency needs and technical opportunities.

Chief Solutions Architect. The Chief Solutions Architect provides the overall technical leadership throughout the lifecycle of a single project or business solution in the areas of data, application and technology. While the Chief Solutions Architect is not generally part of the permanent Enterprise Architecture team, the Chief Solutions Architect plays a vital role in the success of the Enterprise Architecture, ensuring adherence to EA standards, seeking the guidance of EA team members and providing feedback to the EA process. The Chief Solutions Architect may also participate in one or more project tracks of the EA program as a technical or business area specialist. Key responsibilities include:

• Establish the overall solutions architecture framework to guide the design of a business application and the implementation of selected infrastructures such as technologies, platforms, databases, data communications, data discovery and modeling strategy, data access strategy, standards, procedures, processes, quality assurance, training, and other components needed to support the architecture and make it functional.
• Create the high-level technical design and detail technical design.
• Participate in development environment setup, production environment setup, programming, unit testing, final delivery to the Integration Test Team and installation in the production environment.
• Assist with the resolution of design-related issues during system development.

Solutions Architect. The Solutions Architect provides services in support of the Chief Solutions Architect, generally for the implementation of a single business solution or project. Whereas the EA Team prescribes standards and direction, the Solutions Architecture teams actually implement solutions in the context of a focused project or program. Solutions Architects generally have an area of specialization such as presentation, platforms, databases, business logic, security or messaging. Like the Chief Solutions Architect, Solutions Architects generally do not participate directly in the formulation of enterprise architectures but often seek the guidance of the EA team to clarify standards and to better understand how to implement the stated business direction. Solutions Architects who are the leading subject matter or business experts within an agency may also be called upon to participate in the EA process on a temporary or long-term basis in the role of a Consulting Solutions Architect. Solutions Architects also are an important part of the EA feedback loop, providing updated business, data and system views as well as refinements to important EA standards.

Proposed Clinger-Cohen EA Competencies

Based on the normative approach to EA projects across the federal and private sector, the following are the key areas of responsibility for which competencies and learning objectives will be added to the Clinger-Cohen competencies:

• Chief Enterprise/Enterprise Architects
• Chief Solutions/Consulting Solutions Architects

These areas of responsibility are not intended to constrain the manner in which individual agencies conduct EA efforts, but rather are provided only as a framework for the definition of EA competencies and learning objectives.

Chief Enterprise Architect
The Chief Enterprise Architect is a highly experienced IT architect who has a broad and deep understanding of the agency's overall business strategy and general IT trends and directions. A summary of key competencies includes:

• Strong grasp of the value of IT investment in terms of costs, benefits and strategic value
• Extensive knowledge of the agency, its drivers, issues, and strategic directions and plans
• Extensive knowledge of IT capabilities, covering current and emerging technologies
• Able to define an architectural evolution towards the technical strategy in achievable stages
• Experience in a variety of complex architecture projects, able to lead and direct architects
• Highly visible across the agency, opinions and decisions are respected
• Able to lead the development of complex business cases
• Must have depth and breadth of the overall organization, its business needs and objectives
• Is a facilitator of change
• Must be a great communicator

Enterprise Architect
The Enterprise Architect is an experienced architect, with additional specialized skills in his or her specific Enterprise Architecture area. A summary of key competencies includes:

• A basic grounding in the agency's environment, strategy and priorities
• Extensive knowledge of IT capabilities, covering current and emerging technologies
• Good knowledge of how similar agencies use or plan to use technology
• Ability to rationalize technology opportunities and business drivers optimizing return on investmentFamiliar with agency's architectural principles and policies, able to interpret and apply
• "Hands on" experience in architecture, able to perform a number of architectural tasks
• Must have a mixture of BPR, business processes, and meeting facility
• Strong in capability modeling
• Can define and understand component capabilities and apply solutions
• Ability to look at technology trends and effectively apply to business/project needs
• Ability to look at and define target architecture for speciality projects
• Ability to manage a repository - repository modeling and analysis
• Competency in several tool sets
• Ability to manage a project portal to identify concepts, work in progress, etc.Able to identify redundancies among existing and proposed IT efforts
• Ability to bring together an overall Enterprise Architecture from several individual EA efforts
• Ability to develop the crux functional integration services that can be implemented in patterns

Consulting Solutions Architect
The Consulting Solutions Architect is a Solutions Architect or Chief Solutions Architect that provides "specialist" architectural services to an EA effort when required on a temporary or advisory basis. Specialist areas may include a particular application or business area, or a specific technical skill such as middleware, security, systems management, and so on, indeed the complete spectrum of Solutions Architect capabilities. Most often, the Consulting Solutions Architect is an agency resource, although contractors are often used in this role. A summary of key competencies includes:

• Well grounded in the agency's architectural principles and policies
• Good grounding in the basic capabilities of a given technology or product
• Familiar with agency's enterprise architecture, able to interpret and apply
• System and technical Architecture skills, strong both on theory and on practical implementation
• "Hands on" experience in architecture, able to perform a number of architectural tasks
• Strong technical expertise in one or more technology areas
• Ability to identify and be aware of different levels of EA Ability to perform capability model scenario

---

Table of Contents - Appendices