HHS Policy for Enterprise Architecture (EA) (2023)

Table of Contents
Table of Contents 1. Nature of Changes 2. Purpose 3. Background 4. Scope 5. Policy 5.1. Unitary, Federated HHS Enterprise Architecture Development and Maintenance 5.2. Collaborative Oversight of the HHS Enterprise Architecture 5.3. Delegated Responsibility to OPDIVs for OPDIV Enterprise Architecture 5.4. Collaborative Investment Review and Approval Process 5.5. Single, Shared, Federated EA Repository Development and Maintenance 5.6. Collaborative Data Architecture and Stewardship of HHS Enterprise Architecture Information 6. Roles and Responsibilities-Department 6.1. Secretary of Health and Human Services 6.2. National Coordinator for Health Information Technology 6.3. Assistant Secretary for Administration and Management 6.4. Assistant Secretary for Resources and Technology 6.5. Deputy Assistant Secretary for Information Technology and HHS Chief Information Officer 6.6. HHS Chief Enterprise Architect 6.7. Operating Division Head (AND Other Management Executives) 6.8. Operating Division: Heads of contracting activities (HCA) 6.9. Operating Division: Chief Information Officer 6.10. Operating Division: Chief Enterprise Architect 6.11. HHS Information Technology Investment Review Board 6.12. HHS Chief Information Officers Council 6.13. HHS Enterprise Architecture Review Board 6.14. Operating Division: Information Technology Investment Review Board 6.15. Operating Division: Enterprise Architecture Review Board 6.16. OPERATING DIVISION AND ENTERPRISE: IT Project Managers 6.17. HHS Employees and Users of HHS IT Resources 6.18. HHS Contractors 7. Applicable Laws/Guidance 7.1. Laws 7.2. Regulations and Guidance 7.3. Department Policy and Guidelines 8. Information and Assistance 9. Effective Date/Implementation 10. Approved Glossary FAQs Videos

HHS Policy for Enterprise Architecture (EA)

August 07, 2008

Project: HHS OCIO Policy
Document Number: HHS-OCIO-2008-0003

Table of Contents

  1. Nature of Changes
  2. Purpose
  3. Background
  4. Scope
  5. Policy
    • 5.1. Unitary, Federated HHS Enterprise Architecture Development and Maintenance
    • 5.2. Collaborative Oversight of the HHS Enterprise Architecture
    • 5.3. Delegated Responsibility to OPDIVs for OPDIV Enterprise Architecture
    • 5.4. Collaborative Investment Review and Approval Process
    • 5.5. Single, Shared, Federated EA Repository Development and Maintenance
    • 5.6. Collaborative Data Architecture and Stewardship of HHS Enterprise Architecture Information
  6. Roles and Responsibilities-Department
    • 6.1. Secretary of Health and Humn Services
    • 6.2. National Coordinator for Health Information Technology
    • 6.3. Assistant Secretary for Administration and Management
    • 6.4. Assistant Secretary for Resources and Technology
    • 6.5. Deputy Assistant Secretary for Information Technology and HHS Chief Information Officer
    • 6.6. HHS Chief Enterprise Architect
    • 6.7. Operating Division Head (AND Other Management Executives)
    • 6.8. Operating Division: Heads of contracting activities (HCA)
    • 6.9. Operating Division: Chief Information Officer
    • 6.10. Operating Division: Chief Enterprise Architect
    • 6.11. HHS Information Technology Investment Review Board
    • 6.12. HHS Chief Information Officers Council
    • 6.13. HHS Enterprise Architecture Review Board
    • 6.14. Operating Division: Information Technology Investment Review Board
    • 6.15. Operating Division: Enterprise Architecture Review Board
    • 6.16. OPERATING DIVISION AND ENTERPRISE: IT Project Managers
    • 6.17. HHS Employees and Users of HHS IT Resources.
    • 6.18. HHS Contractors
  7. Applicable Laws/Guidance
    • 7.1. Laws
    • 7.2. Regulations and Guidance
    • 7.3. Department Policy and Guidelines
  8. Information and Assistance
  9. Effective Date/Implementation
  10. Approved

1. Nature of Changes

  1. Reformatted text to comply with the 10/22/2007 policy template.
  2. Replaced "ONCHIT" acronym with "ONC".
  3. Replaced "ASBTF" acronym with "ASRT".
  4. Replaced "Assistant Secretary for Budget, Technology and Finance"with ”Assistant Secretary for Resources and Technology".
  5. Section 4 intro paragraph: revised text to “It is HHS's Enterprise Architecture (EA) Policy that the following controls be established and enforced:”
  6. Subsection 4.1 heading: revised text to “Unitary, Federated HHS Enterprise Architecture Development and Maintenance”
  7. Subsection 4.2 heading: revised text to “Collaborative Oversight of the HHS Enterprise Architecture”
  8. Subsection 4.3 heading: revised text to “Delegated Responsibility to OPDIVs for OPDIV Enterprise Architecture”
  9. Subsection 4.4 heading: revised text to “Collaborative Investment Review and Approval Process”
  10. Subsection 4.5 heading: revised text to “Single, Shared, Federated EA Repository Development and Maintenance”
  11. Subsection 4.6 heading: revised text to “Collaborative Data Architecture and Stewardship of HHS Enterprise Architecture Information”
  12. Subsection 4.1.3: revised text to "(…) include baseline and target architectures and transition plans (…)".
  13. Subsection 4.2.2: Removed reference to Service and Supply Board of Directors.
  14. Subsection 4.3.4: revised text to "(…) baseline and target architectures, and transition plans (…)".
  15. Subsection 4.5.4: revised text to "(…) create, maintain and report on (…)".
  16. Subsection 4.6.3: added "adopt data stewardship mechanisms to".
  17. Subsection 5.5: revised bullet 6 to "(…) baseline and target architectures, and transition plans (…)".
  18. Subsection 5.5 bullet 7: Removed reference to Service and Supply Board of Directors.
  19. Subsection 5.5 bullet 13: Removed reference to Service and Supply Board of Directors.
  20. Subsection 5.6 introduction paragraph: Removed reference to Service and Supply Board of Directors.
  21. Subsection 5.10: Revised bullet 1 to "Developing and disseminating strategies, policies, standards to implement the OPDIV EA program as a complementary set of processes that contribute to the development of a federated HHS EA;".
  22. Subsection 5.10: Revised bullet 9 to " Ensuring that the OPDIV adopts data stewardship mechanisms necessary for EA data of acceptable quality to be created, captured, entered, and maintained in a timely manner in the Departmental EA Repository;".
  23. Subsection 5.11: Removed membership references.
  24. Subsection 5.12: Removed membership references.
  25. Subsection 5.12: Inserted the word "technical" in the fourth sentence, after "The HHS CIO Council is responsible for assuring the proposed investment’s…".
  26. Subsection 5.12 intro para: Removed reference to Service and Supply Board of Directors.
  27. Subsection 5.14 bullet 1: Removed reference to Service and Supply Board of Directors.
  28. Subsection 5.14 bullet 2: Removed reference to Service and Supply Board of Directors.
  29. Subsection 5.14 bullet 3: Added "Establishing EA priorities and" at the beginning of the sentence.
  30. Subsection 5.16: bullet 11 revised to "Supporting OPDIV advisory input for cross-agency initiatives".
  31. Subsection 5.13 (Service and Supply Board of Directors): Removed.
  32. Limited the list of approvers to comply with the current policy template.
  33. Removed references to Service and Supply Board of Directors from Glossary.

2. Purpose

The purpose of this Department of Health and Human Services (HHS) Policy is to

outline the roles and responsibilities for ensuring compliance with legislative and executive level guidance on Enterprise Architecture (EA). This Policy formally describes the EA Program for HHS, which is managed within the HHS Office of the Chief Information Officer (OCIO). The EA Program ensures the current and future business and technical architectures for the Department support of the HHS mission, strategic plans, and performance and outcome objectives.

This EA Policy is being revised to address new or changed requirements and this issuance supersedes the former EA policy "HHS IT Policy for Enterprise Architecture, (HHS-OCIO-2005-0003.001), dated January 10, 2006.

3. Background

The HHS EA Program enables the Department and its Operating Divisions and components to understand the relationship between and among its business operations and the information systems and resources that enable those operations. Architectural information enables the Department to achieve more effective strategic planning and capital planning and control over investments for information technology and related services. The HHS EA Program supports the Operating and Staff Divisions of HHS in meeting Department objectives by enhancing flexibility and interoperability across information systems, reducing redundancies thereby reducing inefficiencies, and improving access to accurate, timely, and consistent information.

The Department’s EA Program complies with Federal Enterprise Architecture standards, and collaborates with other pertinent government-wide initiatives. HHS’ EA Program is a Department-wide initiative that involves the active participation of all Operating and Staff Divisions. The HHS EA Program takes a “federated approach” to development and implementation of EA throughout the Department, engaging all OPDIVs and Department organizations in fulfillment of Department objectives, while enabling the Operating and Staff Divisions of HHS to meet their mission and objectives.

4. Scope

This Policy applies to all Department Operating Divisions (OPDIVs), including the Office of the Secretary, and organizations conducting business for and on behalf of the Department through contractual relationships when using HHS IT resources. This Policy does not supersede any other applicable law or higher level agency directive, or existing labor management agreement in effect as of the effective date of this Policy.

Agency officials shall apply this Policy to employees, contractor personnel, interns, and other non-government employees. All organizations collecting or maintaining information or using or operating information systems on behalf of the Department are also subject to the stipulations of this Policy. The content of and compliance with this Policy shall be incorporated into applicable contract language or memoranda of agreement under separate cover, e.g., Interim Health and Human Services Acquisition Regulations (HHSAR) Federal Information Security Management Act (FISMA) policy.

OPDIV/STAFFDIVs shall use this policy or may create a more restrictive policy, but not one that is less restrictive, less comprehensive or less compliant with this Department Policy.

Within this Policy the term OPDIV includes the Inspector General, as well as the Office of the Secretary, with all of its associated Staff Divisions (STAFFDIVs), as a combined, single entity.

The EA Policy applies to all HHS IT activities including procedures and technologies that are employed in managing these activities. Additional guidance on implementing this Policy is provided by the OCIO.

5. Policy

It is HHS's Enterprise Architecture (EA) Policy that the following controls be established and enforced:

5.1. Unitary, Federated HHS Enterprise Architecture Development and Maintenance

  • The Office of the Secretary (OS) and all OPDIVs within HHS shall contribute to the development, maintenance, and implementation of a sound and integrated business and information technology architecture (hereinafter referred to as the “enterprise architecture,” or “EA”) for the Department.
  • The Department's EA shall conform to and align with legislative mandates, Federal initiatives and oversight requirements.
  • The EA for the Department and its OPDIVs shall include baseline and target architectures and transition plans, based on input from OS, OPDIVs, and Department advisory bodies including the HHS Chief Information Officers’ (CIO) Council and the HHS Information Technology Investment Review Board (ITIRB).
  • Alignment with the HHS EA shall be incorporated into Department planning and resource allocation, control and oversight processes.
  • The HHS OCIO shall establish Department policies, procedures, and guidelines for implementation, management and governance of HHS
  • The HHS Chief Enterprise Architect (CEA) within the HHS OCIO is delegated responsibility for the Department’s EA Program.

5.2. Collaborative Oversight of the HHS Enterprise Architecture

  • The Department’s EA shall be established and monitored by the Enterprise Architecture Review Board (EARB), under the aegis of the HHS CIO Council.
  • The Department’s ITIRB shall ensure that EA alignment and compliance is required by all IT investments and projects under their purview, with the exception of those granted waivers by the CIO Council.
  • Within each OPDIV, an Enterprise Architecture Review Board (OPDIV EARB), or its equivalent, shall be responsible for assuring that the OPDIV's EA is aligned to and is compliant with the HHS EA.

5.3. Delegated Responsibility to OPDIVs for OPDIV Enterprise Architecture

  • Designate an OPDIV CEA who is responsible for EA within their organization. The OPDIV CEA is responsible for developing the OPDIV EA and for representing the OPDIV EA in Department EA advisory and collaborating groups.
  • Establish an Enterprise Architecture Review Board (OPDIV EARB) or designate an OPDIV organization designated to be responsible for fulfilling this function;
  • Establish a formal system for architectural development, and for architectural reviews and approvals that is complementary to the Department’s approved EA procedures, as adapted and approved by the OPDIV's CEA
  • Develop baseline and target architectures and transition plans based on input from its component organizations and advisory bodies.
  • Ensure that alignment with the HHS EA is incorporated into OPDIV planning and resource allocation, control and oversight processes at all levels within the OPDIV.

5.4. Collaborative Investment Review and Approval Process

  • Reviews for architectural alignment with established EA policies and standards shall be conducted at applicable phases in the life cycle of Department and OPDIV initiatives, investments and projects.
  • Waivers may be granted under exceptional circumstances, based on Department and OPDIV procedures.
  • The Department’s EA waiver process may offer temporary approval for time sensitive situations that may require interim measures. Such a waiver shall state specific conditions under which it is granted, including the timeframe.
  • Any project/initiative that is found to be out-of-conformance with the target architecture and does not have an approved waiver shall be referred to the IT governance process for determination of corrective actions.

5.5. Single, Shared, Federated EA Repository Development and Maintenance

  • The HHS OCIO shall be responsible for managing the repository. The HHS EA Repository Administrator is located within the OCIO, and is a member of the EA Team. The OCIO is the owner of the application.
  • Primary business processes shall be documented in the HHS EA Repository.
  • The HHS EA Repository shall be accessible to Department personnel and others responsible for planning, analyzing, implementing and monitoring operational and technological capabilities of the Department.
  • All HHS OPDIVs shall use the Department-approved architecture repository and specified tool(s) to create, maintain and report on applicable enterprise architecture information in accordance with the processes and procedures established by the OCIO.
  • As required, the Repository shall also support and/or interface with related federal EA initiatives in which the Department participates. Department and OPDIV EA representatives shall collaborate on Federal EA initiatives as required.
  • Each OPDIV CEA shall be responsible for the OPDIV’s use of the Repository, Repository tools and maintenance of the OPDIV’s EA data.

5.6. Collaborative Data Architecture and Stewardship of HHS Enterprise Architecture Information

  • All HHS IT projects and their responsible managers shall participate in the process of developing, acquiring, and maintaining the required elements of the HHS EA and providing the associated data for the HHS EA Repository.
  • OPDIVs shall collaborate with the HHS OCIO to ensure completeness, accuracy, and usability of architecture data.
  • OPDIVs shall adopt data stewardship mechanisms to ensure that required EA data of acceptable quality is created, captured, entered, and maintained in the Department EA Repository.
  • OPDIVs shall establish and maintain a system for configuration control of the OPDIV's data in the Department EA Repository. Such configuration control shall be consistent with the Department's EA configuration control standards.
  • The OPDIV CEA may document, within their EA, a level of detail more specific than that contained in the Department-wide EA. However, in all cases, the OPDIV EA must be consistent with and complementary to the Department EA.

6. Roles and Responsibilities-Department

HHS’ EA program is a Department-wide initiative that involves the active participation of all component organizations. HHS’ EA is developed in a cooperative, managed, and coordinated effort facilitated by the OCIO, with the participation of HHS OPDIVs. The following sections describe the roles and responsibilities for organizational entities that contribute to the development and implementation of the HHS EA, and to the selection, execution, monitoring, and review of IT projects.

6.1. Secretary of Health and Human Services

The Secretary of Health and Human Services is responsible for ensuring that the Department develops and maintains an EA that fulfills legislative, regulatory, and operational “best practices”, consistent with the Federal Enterprise Architecture (FEA) guidelines. The Secretary also ensures that Department representatives participate in and implement collaborative Federal EA initiatives to improve operational and resource management effectiveness across the Department.

The Secretary designates the HHS CIO as responsible for Department EA, ensures resources for, and Department-wide participation in, fulfillment of HHS EA mandates. The Secretary ensures Department collaboration in Federal government-wide and Federally-sponsored business or service domain initiatives.

(Video) CMS Enterprise Architecture

6.2. National Coordinator for Health Information Technology

The Office of the National Coordinator for Health Information Technology (ONC) serves as the senior advisor to the Secretary of Health and Human Services and to the President of the United States on all health IT programs and initiatives. The National Coordinator is responsible for the Federal Health Architecture (FHA), a Federal “Line of Business” initiative supported by the White House Office of Management and Budget. The FHA defines the enterprise architecture for collaboration and interoperability among Federal health efforts.

The National Coordinator is responsible for ensuring that HHS, as a key partner in ONC endeavors, is provided full opportunity to submit input to and provide evaluative feedback related to enterprise architecture impacts in the selection of ONC-led strategic priorities, identification of priority business lines, development of technical standards and target architectures, development of performance measures and outcome strategies, and determination of investment priorities.

6.3. Assistant Secretary for Administration and Management

The Assistant Secretary for Administration and Management (ASAM) provides leadership for HHS Department management, including (but not limited to) human resource policy, facilities management, acquisitions & strategic sourcing, competitive sourcing, and Program Support Center operations to fulfill Department mandates and to support the Secretary's goals and the President's Management Agenda. Within the ASAM, the Office of Acquisition Management and Policy (OAMP) provides management direction and leadership for HHS acquisition-related business practices. OAMP supports HHS’ EA program through the management of procurement activities for IT systems and infrastructure development, enhancement, and maintenance.

In partnership with OCIO/ASRT, and cognizant OPDIV contracting program offices, the ASAM is responsible for:

  • Establishing acquisition policies, procedures, guidelines, and contract clauses that ensure that information technology system acquisitions comply with HHS EA policies;
  • Ensuring all phases of acquisitions for IT projects reflect adherence to the policies, guidelines and technology standards defined by HHS’ EA Program;
  • Ensuring OPDIV-level acquisition strategies and procedures for IT investments include OPDIV CEA input and conform to Department and OPDIV EA policies and standards;
  • Ensuring OPDIV-level acquisition procedures and requirements support adherence to performance-based methodologies.

6.4. Assistant Secretary for Resources and Technology

The Assistant Secretary for Resources and Technology (ASRT) manages the Department’s budgeting, grants management, financial management, and technology management functions. The ASRT ensures fulfillment of the federal enterprise architecture mandates through the CIO, who reports to the ASRT.

The ASRT is responsible for:

  • Ensuring the establishment, policy formulation, operations management, and performance reporting for the Department-wide EA Program;
  • Ensuring that EA is incorporated throughout the Department’s budget planning, grants management, financial management, and technology operations;
  • Ensuring budget and staff resources, and for monitoring the operational performance of the Department’s EA Program;
  • Ensuring Departmental EA representation on key Departmental and federal government-wide and federally-sponsored business or service domain initiatives.

6.5. Deputy Assistant Secretary for Information Technology and HHS Chief Information Officer

The HHS Deputy Assistant Secretary for Information Technology (DASIT) is the HHS CIO. The HHS CIO is responsible for planning, budgeting, managing and performance monitoring of the Department’s enterprise IT investments. The CIO chairs the HHS CIO Council, which reviews and approves the recommendations of the EARB and related technology, security, and privacy advisory groups. The CIO oversees the implementation the EA Program for the Department and delegates responsibility for the Department’s EA mandates to the HHS CEA.

The HHS CIO is responsible for:

  • Instantiating the HHS EA for the Office of the HHS Secretary, for HHS Department-wide functions, and for the OPDIVs;
  • Designating the HHS CEA to be responsible for the Department’s EA and to serve as the Department’s representative on EA matters, on both intra-Departmental and inter-governmental advisory bodies and forums;
  • Providing direction, support, and resources to the HHS EA Program appropriate to the Department’s scope and complexity;
  • Ensuring that the EA Program adheres to legislative and regulatory policies and procedures;
  • Ensuring EA incorporation into policies, procedures, and implementation processes, and operations management within the Department’s IT planning, investment, acquisitions, standards-setting, IT security management, records management and performance monitoring processes;
  • Ensuring availability of and access to baseline and target architectures, and transition plans for the Department;
  • Ensuring that EA issues are addressed by the CIO Council and represented to the ITIRB and other key decision bodies within the HHS;
  • Ensuring management of the Enterprise Architecture Repository and tools.

6.6. HHS Chief Enterprise Architect

The HHS Chief Enterprise Architect (CEA) manages the HHS EA program under authority delegated from the HHS CIO. The HHS CEA establishes, plans, and directs the HHS EA Program and oversees the construction, verification, and adoption of the EA. The CEA directs the establishment, operation, and maintenance of the EA Repository and related tools. The CEA is the HHS CIO’s EA representative to each of the OPDIVs; to the CIO Council and to the Department’s ITIRB and related boards. The HHS CEA is supported by program and technical advisors through the HHS EA Program Management Office. The HHS CEA (or designee) is the HHS representative on EA-related issues to inter-governmental and intra-Departmental advisory bodies and forums.

The HHS CEA is responsible for:

  • Developing, disseminating, and ensuring compliance with Department EA policy, processes, and procedures as foundational principles and practices for business and information system development throughout the Department;
  • Developing the Department-wide EA Program budget; managing HHS EA Program resources; and establishing operational and technical capabilities within an HHS EA Program Management Office (EAPMO);
  • Developing and ensuring transition strategies and schedules from current to target architectural goals/views;
  • Providing a waiver process that is periodically monitored for continued relevancy and ensuring that out-of-conformance issues no longer granted waivers are entered into the capital planning and investment control (CPIC) process for monitoring from development to operation;
  • Developing and promulgating architectural standards;
  • Ensuring that OPDIV-proposed modifications to HHS EA metamodel and HHS technology standards required by the OPDIV in support of their business requirements are addressed by the HHS EARB;
  • Providing updated architectural standards for use: when procurement requests are developed, when IT Policy is developed, when IT program managers and business personnel request guidance, and for the Chief Technology Officer (CTO) to use when advising development efforts of options to mitigate problems;
  • Ensuring implementation of the EA within the Capital Planning and Investment Control (CPIC) processes and System Development Life Cycle (SDLC) standards of the Department; ensuring EA compliance reviews for Department-wide and OPDIV projects within the Department’s procurement and project review cycles;
  • Supporting OPDIVs and OPDIV Program Managers in planning and monitoring EA alignment and compliance for HHS-supported investments;
  • Ensuring the definition and documentation of HHS current architecture, target architecture, and interim target architectures;
  • Implementing and maintaining the HHS EA Repository and related tools;
  • Providing EA-related training and technical assistance to OPDIVs;
  • Supporting the EARB and its sub-committees and task forces; chairing the EARB and representing EARB findings to the HHS CIO Council, ITIRB, and related OS bodies;
  • Facilitating Departmental and OPDIV participation in federal enterprise-wide initiatives;
  • Ensuring Department adherence to EA performance and compliance mandates, including EA-related Records Management requirements, of governmental review and policy organizations including the GAO and OMB;
  • Representing the Department (directly or by explicit designee) on all EA matters, including representation on inter-governmental and intra-Departmental advisory bodies and forums;
  • Ensuring the review of waiver files not only for continued relevancy but also to consider the expansion of standards.

6.7. Operating Division Head (AND Other Management Executives)

OPDIV Heads and Managers implement and ensure adherence to Department policies by all employees and contractors within their respective organizations.

The OPDIV Head designates EA leadership and accountability structures within the OPDIV, and provides budgetary, personnel, and related resources to fulfill EA functions.

The OPDIV Head ensures completion of required EA planning and documentation and ongoing adherence to the Department’s technical standards throughout their organization’s business operations and technology management environment.

The OPDIV Head is responsible for:

  • Ensuring designation of an OPDIV CEA (or EA Lead);
  • Ensuring adequate resources, both human and budgetary, to support the OPDIV CEA (or EA Lead);
  • Ensuring OPDIV representation and active involvement by OPDIV program and/or business domain experts in EA-related planning, implementation, and advisory functions, including Department-wide and federal enterprise initiatives;
  • Ensuring OPDIV and Program Office compliance with the principles, guidelines, and standards contained within the HHS EA;
  • Ensuring that OPDIV policies and procedures incorporate relevant HHS EA requirements;
  • Ensuring that OPDIV technology investment planning and review processes conform to Department EA policies, guidelines, technical standards and architectures, and meet OPDIV requirements;
  • Ensuring completeness, timeliness, accuracy, and currency of EA documentation in OPDIV and Department EA Repositories.

6.8. Operating Division: Heads of contracting activities (HCA)

The OPDIV HCAs: (a) support HHS’ EA program through the management of procurement activities for systems and infrastructure development, enhancement, and maintenance; and (b) work with OPDIV CIO staff and OPDIV CEA to ensure that procurement actions with respect to IT projects reflect the guidelines and technology standards defined by HHS’ EA program.

The OPDIV HCAs are responsible for:

  • Assisting the OPDIV CIO and OPDIV CEA, and, as needed, collaborating with the HHS CEA to develop OPDIV procurement strategies that are consistent with HHS’ EA and contribute to the transition from the current architecture to the target architecture;
  • Ensuring that HHS-wide standard EA-related language is incorporated into OPDIV procurement actions for information technology products or services;
  • Ensuring OPDIV CEA verification of EA compliance prior to initiation of OPDIV information technology products or services acquisitions; and ensure OPDIV and HHS CEA resolution of non-concurrence;
  • Awarding and administering contracts to support the OPDIV’s EA program.

6.9. Operating Division: Chief Information Officer

Consistent with Departmental and OPDIV policies and procedures, the OPDIV CIO is responsible for ensuring the planning, budgeting, managing, and performance monitoring for the OPDIV’s IT investments. The OPDIV CIO chairs the OPDIV CIO Council, or equivalent, which oversees the work of the OPDIV’s Enterprise Architecture Review Board (OPDIV EARB), or equivalent. The OPDIV CIO oversees the implementation of the OPDIV EA Program, delegates responsibility for the OPDIV’s EA mandates to the OPDIV CEA or EA Lead, and reports OPDIV-related EA issues to the HHS CIO Council.

The OPDIV CIOs ensure implementation of HHS EA policies and procedures at the OPDIV level. The OPDIV CIO ensures that OPDIV IT investments align with the Department and OPDIV target architecture and related technology policies and priorities. The OPDIV CIO establishes OPDIV-specific EA policies, guidelines, procedures, and standards in conformity with the HHS EA. The OPDIV CIO ensures availability and management of resources and training opportunities sufficient to fulfill EA responsibilities of the OPDIV and its sub-organizations.

The OPDIV CIO is responsible for:

  • Designating the OPDIV CEA to manage the OPDIV’s EA implementation and compliance activities, to represent the OPDIV on the HHS EARB, and to represent the OPDIV in Departmental and inter-governmental EA-related activities;
  • Ensuring adoption, development, and implementation of Department and OPDIV EA policies and procedures;
  • Facilitating identification of and participation by OPDIV program and business representatives in EA-related activities at the OPDIV, Departmental, and federal level;
  • Ensuring establishment of an EA compliance review and waiver management process that meets HHS EA standards; ensuring that the business sponsor of IT projects complies with the OPDIV’s and Department target EA;
  • Auditing sub-OPDIV EA management processes to ensure compliance with HHS and OPDIV EA standards; receiving and resolving reported incidents of non-conforming technology projects or purchase requests that do not adhere to target architectures and standards;
  • Ensuring that EA-related issues are addressed by the OPDIV EARB (or other body designated to fulfill these functions), the OPDIV ITIRB and Technical Review Board (TRB), or equivalents;
  • Ensuring that the OPDIV IT investment portfolio has received EA compliance review and approval prior to submission to OPDIV or Department CPIC processes;
  • Ensuring that the OPDIV’s the OPDIV and Department target EA and transition strategies support the long-range IT Strategy and Security Architecture requirements;
  • Ensuring that the OPDIV TRB addresses technical requirements identified through the EA;
  • Ensuring submission to HHS CEA of proposed modifications to HHS EA metamodel and technology standards required by the OPDIV in support of business requirements;
  • Collaborating with the OPDIV acquisitions managers to ensure that OPDIV contractors and developers impacted by the EA or that impact the OPDIV’s EA are informed of their obligations and responsibilities for compliance with the EA including providing documentation to the EA Repository.

6.10. Operating Division: Chief Enterprise Architect

The OPDIV CEA (or, in the absence of an OPDIV CEA, the EA Lead) develops and documents the OPDIV’s EA. The OPDIV CEA represents the OPDIV on the HHS EARB and other Department EA policy and advisory groups. The OPDIV CEA may also represent the OPDIV on inter-governmental EA initiatives including FHA and E-Government. Where an OPDIV consists of multiple operational sub-organizations (e.g., “Centers”, “Institutes”), the OPDIV CEA ensures that policies and information are disseminated to related business units and their EA representatives and provides a forum for OPDIV enterprise-wide EA decision and advisory actions. The OPDIV CEA reports and makes recommendations to the OPDIV CIO and to any technology advisory group that may exist within the OPDIV on general EA matters, technology standards, and issues regarding adherence by OPDIV projects to the OPDIV and Department EA.

The OPDIV CEA is responsible for:

  • Developing and disseminating strategies, policies, standards to implement the EA program;
  • Managing OPDIV EA resources;
  • Providing leadership in developing, maintaining, and implementing a sound and integrated EA for the OPDIV and its sub-organizations;
  • Organizing and chairing an OPDIV EA advisory group to provide cross-organization business and technical input to EA-related matters; ensuring OPDIV programmatic and technical participation in EA-related activities;
  • Defining, documenting, and aligning the OPDIV’s and sub-OPDIV EA with the HHS EA;
  • Ensuring implementation of the EA alignment reviews, verification of EA approvals, and granting of waivers within the OPDIV’s CPIC Investment planning and reviews, acquisition procedures, SDLC project phase reviews.
  • Monitoring program and project artifacts for alignment with EA requirements; identifying and reporting on non-conforming projects for resolution;
  • Advising and informing OPDIV contractors and developers of EA standards and compliance requirements;
  • Ensuring that the OPDIV adopts data stewardship mechanisms necessary for EA data of acceptable quality to be created, captured, entered, and maintained in a timely manner in the Departmental EA Repository;
  • Recommending technical standards to the OPDIV TRB; ensuring submission to HHS CEA of proposed modifications to HHS EA and technology standards to meet OPDIV business requirements;
  • Ensuring that OPDIV EA-related training requirements are identified, planned for, and implemented;
  • Advising or ensuring that EA advice is available to OPDIV IT project teams;
  • Representing the OPDIV on the HHS EARB, and on all OPDIV, Departmental, and inter-governmental EA-related advisory bodies or working groups.

6.11. HHS Information Technology Investment Review Board

The HHS Information Technology Investment Review Board (ITIRB) is chaired by the Deputy Assistant Secretary for Information Technology, who is also the HHS CIO. The HHS ITIRB is supported by the Department’s IT Capital Planning and Investment Control (CPIC) Process. The HHS ITIRB selects and monitors performance of projects for HHS’ IT investment portfolio and is responsible for funding decisions on all major IT investments. HHS’ EA process is closely tied to the IT Capital Planning and Investment Control Process. The HHS ITIRB supports HHS’ EA program through the selection and funding of projects that conform to EA guidelines and standards.

(Video) The End of America? The HHS Mandate's Threat to Freedom

The HHS ITIRB is responsible for receiving and acting on advice, recommendations, and issues brought before it by the HHS CEA to:

  • Ensure that overall IT portfolio strategies and investment decisions support and are congruent with HHS’ target architecture and transition strategies;
  • Ensure adherence to HHS’ EA in IT investment decisions and ongoing portfolio performance monitoring;
  • Ensure that new and ongoing IT investments demonstrate EA alignment through documented CEA and EARB approvals (or waivers) at Department and/or OPDIV levels as a mandatory funding condition;
  • Review investments granted EA waivers to assess future compliance options and/or expansion of IT standards.

6.12. HHS Chief Information Officers Council

The HHS Chief Information Officers’ Council (HHS CIO Council) is chaired by the HHS CIO. The HHS CIO Council approves the adoption of standards for technology and architectures for the Department. It makes recommendations to the HHS ITIRB relative to proposed and ongoing information technology initiatives. The HHS CIO Council reviews and approves the technical approach being taken for proposed IT investments. The HHS CIO Council is responsible for assuring the proposed investment’s technical alignment and linkages with the EA in the review of proposed investments. The HHS CIO Council receives and acts on reports from the HHS CEA and from the HHS EARB.

The HHS CIO Council is responsible for:

  • Supporting implementation of EA as a Department-wide priority;
  • Supporting issuance of policies governing the development, implementation, and maintenance of HHS’ EA
  • Providing strategic direction to the development of HHS’ EA;
  • Reviewing all EA components including current architecture, target architecture, and interim target architecture, and EA principles, guidelines, and standards;
  • Approving adoption of HHS Technical Standards and ensuring that HHS EA requirements are reflected in Technical Standards review and approvals;
  • Ensuring OPDIV CIOs reflect Department EA policies and procedures in their OPDIV-level technology strategies and operations;
  • Ensuring that OPDIV budget guidelines provide for adequate funding for EA commensurate with the size and complexity of business and technology support appropriate to each OPDIV.

6.13. HHS Enterprise Architecture Review Board

The HHS Enterprise Architecture Review Board (EARB) provides Departmental coordination among the HHS Office of the Secretary and OPDIVs in establishing an integrated EA consistent with the goals and objectives of HHS. The EARB serves as the primary advisory body for OPDIV participation in the Department-wide EA Program. The EARB recommends and supports EA policy and procedural formulation and dissemination, conducts EA alignment reviews, and serves as a forum for EA Program information dissemination. The EARB is chaired by the HHS CEA and is comprised of designated OPDIV CEA’s or, in the absence of an OPDIV CEA, the designee of the OPDIV CIO. Program and/or business representatives from the OS and OPDIVs provide advisory input to the EARB. The HHS EARB establishes committees and work groups, as needed, to support its functions.

The HHS EARB is responsible for:

  • Advising the HHS CEA, HHS CIO, the HHS CIO Council, HHS ITIRB on Department and OPDIV EA strategic plans, budgets, resources, policies, procedures, guidelines, EA standards, and operations;
  • Providing EA compliance review, advice, and approval or waiver recommendations to the HHS ITIRB, HHS CIO Council, and other advisory bodies regarding conformity of IT projects with the approved Department EA and EA guidelines and standards;
  • Establishing EA priorities and advising on and ensuring OPDIV-level adherence to HHS EA policies and procedures;
  • Advising on and supporting definition, development, and analysis of HHS EA baseline and target architectures, interim architectures, and transition strategies;
  • Advising on potential impacts of new or emerging technologies on EA Target Architecture and transition plans;
  • Coordinating with the HHS Chief Technology Officer regarding emerging technology for consideration/approval into the EA standards;
  • Supporting the design, implementation, and management of the HHS EA Repository;
  • Ensuring that a Change Management and Configuration Control system is operational to ensure the integrity of the Department’s EA Program;
  • Supporting an ongoing EA Program Risk Management strategy;
  • Assisting the HHS CEA in conducting EA reviews to identify and recommend actions to eliminate gaps, duplication or incompatibilities among business functions, programs, and/or technologies;
  • Reviewing and recommending solutions to EA-related cross-domain issues and problems;
  • Serving as the HHS Department coordinating-body for advisory input to the FHA and related government-wide EA initiatives;
  • Supporting the analysis and Department-wide implementation of federal EA reference models;
  • Supporting sub-committees, workgroups, and/or task teams as necessary to facilitate HHS EA Program activities.

6.14. Operating Division: Information Technology Investment Review Board

The OPDIV Information Technology Investment Review Board (OPDIV ITIRB), or the OPDIV’s equivalent oversight board for IT investments, ensures that technology-related investments are congruent with OPDIV and Departmental EA. The OPDIV ITIRB ensures that all programs and projects within the OPDIV’s proposed IT portfolio meet HHS and OPDIV EA requirements.

The OPDIV ITIRB is responsible for:

  • Ensuring that the overall OPDIV IT portfolio strategies and investment decisions support and are congruent with HHS’ target architecture and transition strategies;
  • Ensuring adherence to HHS’ and OPDIV EA in IT investment decisions and ongoing portfolio performance monitoring;
  • Ensuring that new and ongoing OPDIV IT investments demonstrate EA alignment through documented OPDIV CEA and EARB approvals (or waivers) as a mandatory funding condition;
  • Ensuring that, where existing or proposed OPDIV initiatives are in conflict with or adversely constrained by Department EA policies, procedures, and standards, the OPDIV ITIRB makes these issues known to the Department through the OPDIV CEA and OPDIV CIO, requesting, if necessary, that their concerns be escalated to the appropriate Department review board through the HHS EARB.

6.15. Operating Division: Enterprise Architecture Review Board

The OPDIV Enterprise Architecture Review Board (OPDIV EARB) or its equivalent monitors and advises the OPDIV on EA. Membership includes architectural representatives from sub-organizations, and related technical, program operations, data management, security, records management and business advisors. The OPDIV EARB is chaired by the OPDIV’s CEA or, in the absence of an OPDIV CEA, the designated EA Lead. The OPDIV EARB is the OPDIV’s EA governance body that reviews all new and existing project initiatives with regard to architectural alignment for the upcoming budget year. It also monitors and analyzes ongoing and candidate investments for compliance with target architecture, technical standards, and overall project health. It analyzes candidate investments for technical feasibility and EA compliance. It recommends IT investment and Project approvals, corrective actions or waivers to the OPDIV ITIRB. The OPDIV EARB submits issues for action by the Department EARB as required.

The OPDIV EARB is responsible for:

  • Advising the OPDIV CEA on EA-related policies and procedures and for ensuring input is provided to EA reviews from OPDIV business and technology representatives;
  • Assisting the OPDIV CEA in conducting OPDIV EA compliance reviews of proposed and ongoing OPDIV IT Investments; recommending EA-compliance approval or waiver to OPDIV projects and investments within the OPDIV-approved architecture, and submitting waiver requests to the HHS EARB;
  • Advising on EA budget, staffing, and other resource requirements;
  • Analyzing OPDIV EA training requirements; planning and monitoring training schedules;
  • Providing information and advice to the OPDIV ITIRB, OPDIV CIO Council and other OPDIV advisory bodies regarding conformity of OPDIV IT projects and investments with the approved OPDIV and Department EA and EA guidelines and standards;
  • Advising on and supporting definition, development, and analysis of OPDIV EA baseline and target architectures, interim architectures, and transition strategies;
  • Advising on potential impacts of new or emergent technology on OPDIV EA target architecture and transition plans;
  • Supporting the design, implementation, and management of the HHS EA Repository, including OPDIV-specific model elements;
  • Monitoring compliance and accuracy of OPDIV EA data in the HHS EA Repository support requirements;
  • Serving as the OPDIV EA Change Control Board;
  • Supporting OPDIV advisory input for cross-agency initiatives;
  • Establishing sub-committees, workgroups, and/or task teams to facilitate OPDIV EA activities.

6.16. OPERATING DIVISION AND ENTERPRISE: IT Project Managers

The IT Program (or Project) Managers (PM) for Department-wide investments or OPDIV are responsible for ensuring that their projects improve HHS mission effectiveness and customer service. They must ensure compliance with the HHS EA throughout the project’s SDLC from Pre-Planning to Close-out. They must ensure at key decision points during the acquisition and implementation process and key project milestones that the project adheres to EA. The PM collaborates with the OPDIV CEA to ensure initial and ongoing alignment with OPDIV and Department technology standards and the OPDIV and Department EA. The PM works with the OPDIV CEA to identify existing or potential EA compliance issues and to provide information to decision and advisory groups relative to potential or expected impacts. The PM also ensures adherence to and implementation of EA-related decisions that impact their project.

The PM is responsible for:

  • Ensuring that proposed and ongoing IT investments align with or have secured approved waivers from HHS and OPDIV EA policies, procedures, and standards and that IT-related acquisitions are approved by the HHS CEA or the OPDIV CEA (or EA Lead), as appropriate, for EA compliance prior to the initiation of a procurement process;
  • Ensuring that standard language to secure and solidify the EA is inserted in the procurement contracts for information technology products or services;
  • Ensuring that OPDIV contractors and developers impacted by the EA or that impact the OPDIV’s EA are informed of their obligations and responsibilities for compliance with the EA including providing documentation to the EA Repository;
  • Ensuring that Project teams and contractors are kept current on HHS and OPDIV EA policies and procedures;
  • Ensuring full and ongoing engagement of business representatives in development and approval of EA-related project artifacts;
  • Ensuring that all EA-related work products created by the project team or contractors are submitted in a timely manner to the HHS EA Repository and are updated throughout the project lifecycle;
  • Submitting waiver requests or proposed standards modifications where projects’ requirements cannot be met within existing EA standards; representing project in review of waiver requests;
  • Supporting enforcement of EA requirements in ongoing contract monitoring.

6.17. HHS Employees and Users of HHS IT Resources

HHS employees are responsible for following EA policies and procedures in their requests to purchase new or modified hardware and software acquisitions. Department staff personnel are responsible for using available EA documentation and resources for ongoing planning, management, and monitoring purposes.

HHS Employees and IT Users are responsible for:

  • Participating in Department or OPDIV-level EA training, and maintaining current knowledge, appropriate to their roles;
  • Participating in and supporting development of EA documentation of business, technology, security, data, and performance architectures for the Department;
  • Using reports and analyses accessible from the EA Repository or available from the EA Program for ongoing strategic planning, analysis, and reporting requirements.

6.18. HHS Contractors

HHS IT Contractors support planning, developing, implementing, and maintaining IT systems. Such systems must meet Department and OPDIV EA requirements.

7. Applicable Laws/Guidance

7.1. Laws

The Government Performance and Results Act of 1993 (GPRA - 1993) establishes the foundation for budget decision-making to achieve strategic goals in order to meet agency mission objectives. Instructions for preparing strategic plans, annual performance plans, and annual program performance reports are provided in Part 6 of this Circular (see section 220). The Federal Acquisition Streamlining Act of 1994, Title V (FASA V) (1994) requires agencies to establish cost, schedule, and measurable performance goals for all major acquisition programs, and achieve on average 90 percent of those goals. OMB policy for performance-based management is also provided in this section. If a project falls out of tolerance (failure to meet 90 percent of cost, schedule, or performance goals), FASA gives the Agency head the authority to review, and if necessary, terminate the project.

The Paperwork Reduction Act of 1995 (PRA) requires that agencies perform their information resource management activities in an efficient, effective, and economical manner.

The Clinger-Cohen Act of 1996 (CCA) requires agencies to use a disciplined capital planning and investment control (CPIC) process to acquire, use, maintain, and dispose of information technology. OMB policy for management of federal information resources is contained in Circular A–130, Management of Federal Information Resources, and section 53 of A-11. The purpose of the CCA is to improve the productivity, efficiency, and effectiveness of federal programs though improved acquisition, use, and disposal of IT resources.

The Government Paperwork Elimination Act of 1998 develops procedures for the use and acceptance of electronic signatures by executive agencies.

The Government Information Security Reform Act (GISRA - 2000) focuses on the project management, implementation, and evaluation of systems security. It requires federal agencies to assess the information security control techniques of their systems. Specifically, agencies must support the cost-effective security of federal information systems by promoting security as an integral component of each Agency’s business operations.

The President's Management Agenda addresses Strategic Management of Human Capital, Competitive Sourcing, Improved Financial Performance, Expanded Electronic Government, Budget, and Performance Integration.

The Federal Information Security Management Act (FISMA - 2002) requires agencies to integrate IT security into their capital planning and enterprise architecture processes at the agency, conduct annual IT security reviews of all programs and systems, and report the results of those reviews to OMB.

The E-Government Act of 2002 (P.L. 107-347) requires agencies to develop performance measures for implementing E-Government. The Act also requires agencies to support Government-wide E-Government initiatives and to leverage cross-agency opportunities to further E-Government. In addition, the Act requires agencies to conduct, and submit to OMB, Privacy Impact Assessments for all new IT investments administering information in identifiable form collected from or about members of the public.

(Video) Department of Health and Human Services (HHS) FY2023 Budget | Sales training for Federal Contractors

7.2. Regulations and Guidance

Executive Order 13011 (1996) highlights the need for executive agencies to significantly improve the management of their information systems.

OMB Circular A-11, Preparing and Submitting Budget Estimates, instructs agencies on the preparation of budget submissions.

OMB Circular A-11, Part 7 - Capital Planning Budget Reporting, Exhibits 52, 5 and 300B. The OMB Capital Programming Guide provides guidance on the principles and techniques for effective capital programming. The Capital Programming Guide integrates the various Administration and statutory asset management initiatives (including GPRA, Clinger/Cohen Act, FASA, and others) into a single, integrated capital programming process to ensure that capital assets contribute to the achievement of agency strategic goals and objectives.

OMB Circular A-109, Major Systems Acquisitions, establishes policies for acquiring major systems. Major systems are defined as those programs that are critical to fulfilling an Agency mission, entail the allocation of relatively large resources, and warrant special management attention.

OMB Circular A-123, Management Accountability and Control, provides guidance to Federal managers on improving the accountability and effectiveness of Federal programs and operations by establishing, assessing, correcting, and reporting on management controls.

OMB Circular A-127, Financial Management Systems, prescribes policies and standards for executive departments and agencies to follow in developing, operating, evaluating, and reporting on financial management systems.

Circular A-130, Management of Federal Information Resources, establishes policies for the management of federal information resources to include procedural and analytical guidelines for implementing specific aspects of the circular.

OMB Circular A–130, Section 8b, establishes additional requirements for enterprise architectures, planning and control of information systems and technology investments and performance management. Agencies must develop, implement, and use a capital programming process to develop their capital asset portfolio.

OMB memorandum M-00-07 dated February 28, 2000, Incorporating and Funding Security in Information Systems Investments, reminds agencies of OMB’s principles for incorporating and funding security as part of agency information technology systems and architectures and of the decision criteria that will be used to evaluate security for information systems investments.

OMB memorandum M-97-02 dated October 25, 1996, Funding Information Systems Investments, establishes the decision criteria with respect to the evaluation of major information system investments.

7.3. Department Policy and Guidelines

HHS OCIO - Minutes of March 23, 2005 meeting with representatives of the National Archives and Records Administration, commits alignment of HHS Enterprise Architecture and Security to support fulfillment of Records Management mandates.

8. Information and Assistance

Direct questions, comments, suggestions, or requests for further information to the Deputy Assistant Secretary for Information Technology, who serves as the HHS CIO, at (202) 690-6162.

9. Effective Date/Implementation

The effective date of this policy is the date the policy is approved.

These policies and procedures will not be implemented in any recognized bargaining unit until the union has been provided notice of the proposed changes and given an opportunity to fully exercise its representational rights.

The HHS policies contained in this issuance shall be exercised in accordance with Public Law 93-638, the Indian Self-Determination and Education Assistance Act, as amended, and the Secretary's policy statement dated August 7, 1997, as amended, titled “Department Policy on Consultation with American Indian/Alaska Native Tribes and Indian Organizations.” It is HHS’ policy to consult with Indian people to the greatest practicable extent and to the extent permitted by law before taking actions that affect these governments and people; to assess the impact of the Department's plans, projects, programs and activities on tribal and other available resources; and to remove any procedural impediments to working directly with tribal governments or Indian people.

10. Approved

/s/
Michael W. Carlton
HHS Chief Information Officer

August 7, 2008
Date

Glossary

AM/PO: Acquisition Manager/Procurement Officer

ASAM: Assistant Secretary for Administration and Management

ASRT: Assistant Secretary for Resources and Technology

CEA: Chief Enterprise Architect

CIO: Chief Information Officer

(Video) Deriving Business Value with EA: Lessons from the Public and Private Sectors - Part 3 (of 3)

CPIC: Capital Planning and Investment Control

CTO: Chief Technology Officer

DASIT: Deputy Assistant Secretary for Information Technology

EA: Enterprise Architecture

EAPMO: Enterprise Architecture Program Management Office

EARB: Enterprise Architecture Review Board

ERM: Electronic Records Management

FEA: Federal Enterprise Architecture

FHA: Federal Health Architecture

GAO: Government Accountability Office

HHS: Health and Human Services

IT: Information Technology

ITIRB: Information Technology Investment Review Board

MOU: Memorandum of Understanding

OAMP: Office of Acquisition Management and Policy

OCIO: Office of the Chief Information Officer

OMB: Office of Management and Budget

ONC: Office of the National Coordinator for Health Information Technology

OS: Office of the Secretary

OPDIV: Operating Division

PM : Program (or Project) Manager

PSC: Program Support Center

(Video) HHS Health IT Modernization Project

SDLC: System Development Life Cycle

SLA: Service Level Agreements

STAFFDIV: Staff Division

FAQs

What are enterprise architecture policies? ›

The Enterprise Architecture (EA) Policy establishes an information technology framework to develop, maintain and use the EA as a tool for making decisions around information technology changes and investments.

What are the five 5 core elements of an enterprise architecture approach? ›

With this in mind, there are five common features of a successful enterprise architecture function that apply to all companies:
  • Governance. Enterprise architecture (EA) requires governance, however not in the form of complex documents, forms or processes. ...
  • Talent. ...
  • Executive Sponsors. ...
  • Scope. ...
  • Business Value.
11 Aug 2014

What are the 4 types of elements in enterprise architecture? ›

If you want to become a building architect or a designer, you will learn the four basic elements of architecture and design: Point, Line, Plane and Volume. With these four elements, you actually can create any architecture or design.

What are enterprise architecture requirements? ›

Educational Requirements

Enterprise architect jobs typically require an undergraduate degree in computer science, data science, or a related field.

What is EA methodology? ›

An EA development methodology is a body of methods, rules and postulates used to structure, plan, and implement the process of developing an EA. A methodology usually specifies a set number of development phases, each with its own defined inputs and outputs.

What are the 7 principles of architecture? ›

Seven principles encompass an interesting design.
  • Balance.
  • Rhythm.
  • Emphasis.
  • Proportion and scale.
  • Movement.
  • Contrast.
  • Unity.

What is the best EA framework? ›

Top 10 Enterprise Architecture Frameworks
  • TOGAF's ADM.
  • Zachman.
  • Gartner's Enterprise Architecture Method.
  • Federal Enterprise Architecture (FEAF)
  • Dept of Defence Architecture Framework (DoDAF)
  • Australian Government AGA.
  • SABSA – Enterprise Security Architecture.
  • Business Architecture Body of Knowledge (BizBoK)

Can EA be used by all types of enterprises? ›

Yes. Enterprise Architecture is a management and technology practice that is devoted to improving the performance of enterprises by enabling them to see themselves in terms of a holistic and integrated view of their strategic direction, business practices, information flows, and technology resources.

What are the 5 enterprise architecture benefits? ›

The benefits of having an Enterprise Architecture are: Frees unit IT staff time to work mission-specific projects and innovations. Enables more innovation at the departmental level. Provides a stronger technology infrastructure at the central technology core.

What is the purpose of EA? ›

The purpose of enterprise architecture is to create a map of IT assets and business processes and a set of governing principles that drive an ongoing discussion about business strategy and how it can be expressed through IT.

What are the 3 most important factors to consider when creating an enterprise architecture? ›

The critical factors found are grouped in three different areas: Management, Scope and Content. To succeed with an enterprise architecture initiative it requires top IT and business management buy-in. The scope of the enterprise architecture must be defined and agreed between business and IT.

What is a six step process in enterprise architecture? ›

6 Steps to Build a Strong Foundation for Execution

Step 1 –Analyze your existing foundation for execution. Step 2 – Define your operating model. Step 3 – Design your enterprise architecture. Step 4 – Set priorities. Step 5 – Design and implement an IT engagement model.

Do enterprise architects have a code? ›

Yes, in Enterprise Architect 7.5 and later releases, in the Business and Software Engineering, Systems Engineering and Ultimate editions, you can generate software and hardware code from Behavioral models.

What are EA artifacts and how do they relate to EA components? ›

EA artifacts are types of documentation that describe components, including reports, diagrams, charts, spreadsheets, video files, and other types of recorded information. High-level EA artifacts are often text documents or diagrams that describe overall strategies, programs, and desired outcomes.

What are the 4 key enterprise applications? ›

The Four Types of Enterprise Systems
  • Enterprise Resource Planning (E.R.P.) Systems. ...
  • Supply Chain Management (S.C.M.) Systems. ...
  • Customer Relationship Management (C.R.M.) Systems. ...
  • Knowledge Management Systems (K.M.S.)
25 May 2021

What is an example of an enterprise architecture? ›

What is an example of enterprise architecture? A common example of enterprise architecture is the Business Development (BD) Model. This model is used to label a business's framework and the key factors that play into that framework.

What are the three rules of architecture? ›

These universal principles of good architecture: Durability, Utility and Beauty, can help us all be better at what we do.

What are the 3 main functions of an architect? ›

Architect: job description
  • creating building designs and highly detailed drawings both by hand and by using specialist computer-aided design (CAD) applications.
  • liaising with construction professionals about the feasibility of potential projects.

What are the 12 principle of design? ›

There are twelve basic principles of design: contrast, balance, emphasis, proportion, hierarchy, repetition, rhythm, pattern, white space, movement, variety, and unity. These principles work together to create visually appealing and functional designs that make sense to users.

Which is better TOGAF or Zachman Framework? ›

The fundamental difference between Zachman and TOGAF is that the former uses different perspectives. It provides an unprecedented scope that defines, plans extra details concerning the subsets regarding the enterprise system. Organizations have all the right to choose one.

What is difference between Enterprise Architect and Solution Architect? ›

While the enterprise architect focuses on the enterprise-level design of the IT landscape, solution architects are in charge of finding and introducing solutions to specific business problems. They also manage all activities that lead to the successful implementation of a new application.

What are the advantages for applying an EA framework? ›

Benefits of Enterprise Architecture
  • Decreasing Complexity. Complex systems that are difficult to manage can cause many errors as well as reduce efficiency. ...
  • Standardization. ...
  • Reducing Wasted Time. ...
  • Cost Saving. ...
  • Change Analysis. ...
  • Strong Security.

What are the 4 elements of an EA management program? ›

Summary of Concepts

The purposes of an EA management program were described: strategic alignment, standardized policy, decision support, and resource development.

Who is responsible for EA? ›

Electronic Arts, EVP & Chief Operating Officer

Laura Miele is EVP and Chief Operating Officer of Electronic Arts, where she is responsible for developing EA's company strategy and leads the day-to-day operations of more than 14,000 global employees.

Who is EA's biggest competitor? ›

Electronic Arts (EA) competitors include Blizzard Entertainment, Niantic, Discord, Ubisoft and Activision. Electronic Arts (EA) ranks 4th in CEO Score on Comparably vs its competitors.

What are the different types of ERP architectures? ›

Two main categories of ERP architecture are monolith and microservices.

Why is IT called enterprise architecture? ›

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.

What are some of the basic characteristics of an EA framework? ›

There are three basic components that make up the creation of an enterprise architecture framework: description, design method and organization. The description of an architecture should outline how the enterprise will be documented, as well as how the documentation can be viewed from multiple viewpoints.

How do you build an EA team? ›

The 6 Factors to Consider When Building Your EA Organization
  1. Understand Your EA Stakeholders. The ideal enterprise architecture supports the needs of a diverse set of stakeholders. ...
  2. Involve Your EA Stakeholders. ...
  3. Choose an Operating Model. ...
  4. Define the Structure of Your EA Team. ...
  5. Build Your EA Ecosystem. ...
  6. Size Teams Correctly.
9 Jul 2018

What are some of the most important characteristics relevant to EA governance? ›

EA governance roles and responsibilities

Providing leadership and communication. Envisioning, leading, and guiding the development of overall solution architecture compliance with IT transformation. Understanding of business areas mapped to the business capability model.

What is an EA roadmap? ›

An enterprise architecture roadmap is a strategic blueprint that communicates how a company's IT plans will help the organization achieve its business objectives.

What are the 4 types of processes? ›

The main manufacturing process types are project, jobbing, batch, line and continuous. Project processes produce products of high variety and low volume. A feature of a project process is that the location of the product is stationary.

Is enterprise architect an IT role? ›

An Enterprise Architect (EA), or IT Business Analyst is responsible for ensuring that a company's business strategy achieves its goals through the proper architecture of its technology systems. Their duties include regulating the technology environment, increasing flexibility and reducing costs.

Is enterprise architect hard? ›

Yes, it is hard to become an enterprise architect. Professionals in this position must have a few years of industry experience. The best way to become an enterprise architect is to earn a bachelor's degree and gain job experience to work your way up.

What is the next level of an enterprise architect? ›

Using our career map, an enterprise architect can determine their career goals through the career progression. For example, they could start out with a role such as project manager, progress to a title such as senior project manager and then eventually end up with the title senior infrastructure project manager.

What are the enterprise architecture best practices? ›

Enterprise Architecture Best Practices
  • Charter the EA program.
  • Develop (and execute) a decision and communications plan.
  • Treat each iteration of the plan like a project.
  • Start with the business strategy and obtain business sponsorship.
  • Do the future state of affairs before the current state.
  • Be realistic.

Why is EA important? ›

Enterprise architecture will help multiple departments in a business understand the broader business model and articulate challenges and business risks. Because of this, enterprise architecture has an important role in unifying and coordinating departmental processes across an organization.

What are the reasons why EA is being implemented in an enterprise? ›

It enables the planning, design, and execution of enterprise analysis for the management of business strategies. The concept of EA emerged from reasons such as the difficulty of analyzing complex systems and the inability to evaluate IT needs correctly.

Why do I need an EA tool? ›

Enterprise architecture (EA) tools are software applications designed to support enterprise architects and other business and IT stakeholders with strategically driven planning, analysis, design and execution.

What is EA tool? ›

Enterprise architecture (EA) tools are software applications targeted primarily at supporting participants and stakeholders of the EA discipline in their strategically driven planning through to execution.

What is an EA implementation methodology? ›

EA implementation methodology is the process of defining architecture for the use of information in support of the business and the plan for implementing them. Agent-oriented techniques represent an exciting new means of analyzing, designing and building complex software systems.

Videos

1. Join HHS’ IT and Cybersecurity Team! (full-version)
(U.S. Department of Health and Human Services)
2. Indea's Story
(usgovACF)
3. 2017 Jun 1st, Cyber Security Training Day
(CMSHHSgov)
4. #IAmHHS: Cindy Kemp (SAMHSA)
(U.S. Department of Health and Human Services)
5. HIPAA Compliance: New HHS Cybersecurity Guidelines
(PBSI Technology Solutions)
6. Leveraging On Premise Cloud to Protect Critical Applications and Physical Security
(ATARC Channel)
Top Articles
Latest Posts
Article information

Author: Dean Jakubowski Ret

Last Updated: 02/08/2023

Views: 5487

Rating: 5 / 5 (50 voted)

Reviews: 81% of readers found this page helpful

Author information

Name: Dean Jakubowski Ret

Birthday: 1996-05-10

Address: Apt. 425 4346 Santiago Islands, Shariside, AK 38830-1874

Phone: +96313309894162

Job: Legacy Sales Designer

Hobby: Baseball, Wood carving, Candle making, Jigsaw puzzles, Lacemaking, Parkour, Drawing

Introduction: My name is Dean Jakubowski Ret, I am a enthusiastic, friendly, homely, handsome, zealous, brainy, elegant person who loves writing and wants to share my knowledge and understanding with you.