| NODIS Library | Legal Policies(2000s) | Search |

NASA Ball NASA
Procedural
Requirements
NPR 2830.1A
Effective Date: December 19, 2013
Expiration Date: December 19, 2025
COMPLIANCE IS MANDATORY FOR NASA EMPLOYEES
Printable Format (PDF)

Subject: NASA Enterprise Architecture Procedures

Responsible Office: Office of the Chief Information Officer


| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | AppendixA | AppendixB | AppendixC | ALL |

Chapter 3: Development and Use of the EA Process

3.1 NASA EA Process

a. The NASA CIO is responsible for providing Enterprise IT resources and processes that enable mission success. The NASA CIO has delegated to the NCEA responsibility for maintaining the NASA EA program and processes and facilitating strategic IT decision making in alignment with mission goals. Personnel responsible for IT planning, development, and implementation will collaborate with the NCEA or designated architect to ensure that their mission, program, project and Center IT projects are in compliance with the architecture and the strategic goals of the Agency.

b. Each Center Director, via the Center CIO, has delegated to the Center Enterprise Architect (CEA) responsibility for the Center-specific EA program and processes that shall align and complement the Agency-level EA efforts.

c. All IT initiatives and service offerings shall comply with the approved NASA EA. The NCEA has instituted review processes to ensure adherence of all NASA IT initiatives and service offerings to NASA Strategic Plans and Mission Support needs. The NASA CIO maintains oversight responsibility for all of the IT investments of NASA.

d. Each of the EA Process steps detailed below identifies the specific products and outcomes, roles and responsibilities, and procedural requirements that govern each Agency EA activity. These steps correspond with the boxes on the EA process diagram in Figure 2-1. The Center-level activities and plans below identify similar steps that should be occurring at the Center- level to align and complement the Agency efforts.

3.2 NASA Strategic Plan

3.2.1 Description

The NASA Strategic Plan outlines NASA's long-term goals and describes at a high level how NASA will accomplish these goals. The plan addresses NASA's missions, workforce, and technical capabilities that support them, as well as the continuous improvements in technological and operational efficiencies.

3.2.2 Products/Outcomes

The NASA Strategic Plan outlines the Agency's long-term vision and identifies specific goals and how NASA intends to accomplish those goals over a ten-year period. The document details the specific missions and programs and will drive the IT strategy and investments necessary to accomplish these goals.

3.2.3 Roles and Responsibilities

The NASA Strategic Plan is the responsibility of the Administrator and Deputy Administrator. The NASA CIO and NCEA must maintain a formal, ongoing dialogue to ensure enterprise IT strategy is properly positioned to meet mission and business needs and to ensure mission stakeholders are aware of IT change drivers that could influence mission investments. Likewise, the Center CIOs and EAs must maintain an ongoing dialogue with Center stakeholders to ensure Center IT strategy is positioned to meet Center needs and ensure stakeholders are aware of IT change drivers that could influence Center investments.

3.2.4 Procedural Requirements/Governance

NPD 1001.0 - 2011, NASA Strategic Plan

3.3 NASA IRM Strategic Plan

3.3.1 Description

The NASA IRM Strategic Plan, referred to as the IRM, is the NASA CIO's plan to guide the direction, focus, mission alignment, principles, investments, initiatives, and accountability of the NASA organization and to maximize the value of IT to NASA missions, programs, partners, stakeholders, and the American public.

3.3.2 Products/Outcomes

Annually, the NASA Office of the Chief Information Officer (OCIO) reviews progress made toward the IRM Strategic Plan and adjusts and publishes updates to the plan, as appropriate. This key Agency IT document guides and informs the Agency and Center strategic plans for IT and establishes Agency IT spending priorities and guides the allocation of IT resources.

3.3.3 Roles and Responsibilities

The NASA CIO is directed to develop and maintain a strategic IRM plan. The EA role is to provide the IRM development process with change driver input and to utilize the IRM plan in the development of the target architecture and transition plans. The NCEA facilitates the development, consolidation, and analysis of the change drivers. Centers utilize the IRM to guide their development of Center IT strategies.

3.3.4 Procedural Requirements/Governance

Section 3506(b) (2) of Title 44 of the United States Code and the Clinger-Cohen Act of 1996. The IRM is approved by the NASA Mission Support Council (MSC).

3.4 Target Architecture

3.4.1 Description

The target architecture is the formal documentation that translates mission strategy into IT direction by defining the future state of NASA's IT enterprise. It describes the environment where the IRM goals and objectives are met. The enterprise target architecture is comprised of Agency and Center-level architectures. Agency target architecture guides Center architecture development. Center target architecture aligns with and complements the Agency target architecture.

3.4.2 Products and Outcomes

a. Formal documentation of the Agency target IT architecture detailing vision, goals and objectives, guidance, and reference models. The Agency target architecture will document the integration of all Agency-level domain and cross-domain target architectures.

b. Formal documentation of the individual Agency-level domain and cross-domain target architectures. Target architectures shall be documented for the following domains: Host Computing, End-User Computing, Applications, Communication, Information, and Security. These domains make up the fundamental infrastructure that supports NASA's IT services. Cross-domain target architectures address specific IT mission or business needs that cut across two or more domains. Domain and cross-domain services and architectures can span multiple Centers. Each of the domain and cross-domain architectures consist of targets described from a people, process, technology, performance, and data perspective.

c. Formal documentation of each Centers target IT Architecture that provide the vision, goals and objectives, guidance, and reference models for the Center, and is in alignment with, and complements the Agency target architecture. The Center target architecture will document the integration of all Center-level domain and cross-domain target architectures.

d. All target architectures will align with the NCEA approved reference models.

3.4.3 Roles and Responsibilities

a. The NCEA shall be responsible for the delivery of the integrated Enterprise Target IT Architecture which is comprised of Agency and Center architectures. The NCEA shall collaborate with domain, cross-domain, and Center architects, mission subject matter experts, service executives, Chief Technology Officer (CTO), and other stakeholders in the development of the target architecture. The NCEA is the curator of all enterprise and Agency-level products.

b. For domain and cross-domain architects, the NASA CIO/NCEA invites or nominates a candidate based on the necessary experience, skill set, or role, and the candidate accepts or rejects the nomination. The candidate, his or her direct manager, and the NCEA agree on the amount of time the candidate will spend fulfilling the domain or cross-domain duties and the length of the appointment. All candidate nominations are recorded, and appointments are formally confirmed by NCEA and the candidate's manager.

c. Domain architects are responsible for developing their respective Agency-level architectures in collaboration with the NCEA, other domain and cross-domain architects, Center architects, mission architects, service executives, and other stakeholders. Domain architects will help ensure that the Agency has integrated target architecture. Domain architects are the curators of their architecture products.

d. Cross-domain architects are responsible for developing their respective Agency-level Cross-domain target architectures in collaboration with the NCEA, other domain and cross-domain architects, Center architects, mission architects, service executives, and other stakeholders. Cross-domain Architects will help ensure that the Agency has an integrated target architecture. Cross-domain architects are the curators of their architecture products.

e. Center Architects are responsible for developing their respective Center-level target architecture in collaboration with the NCEA, other domain and cross-domain architects, other Center architects, mission architects, service executives, and other stakeholders. Center architects shall align their target architecture with the Agency target architecture. Center architects are the curators of their architecture products.

3.4.4 Procedural Requirements/Governance

a. The NASA Enterprise Architecture Board (EA Board) is the approval authority for the Enterprise Target IT Architecture, in consultation with appropriate governance bodies. The EA Board is responsible for overseeing the development of the target architecture.

b. Center-level target architectures are reviewed and approved by the appropriate Center governance board(s) and shall align with and complement the Agency target architecture.

3.5 Transition Plan

3.5.1 Description

NASA's Enterprise IT Transition Plan is the Agency's integrated five-year plan with the primary purpose of achieving IRM goals and objectives by advancing all domain and cross-domain architectures from the current state to the target architecture. This plan identifies a prioritized set of investments, funding requirements, and milestones required to progress toward the enterprise target architecture. The enterprise transition plan is comprised of Agency and Center-level plans and provides linkages between all domain and cross-domain target architectures. The plan's timeframe aligns with the Federal budget cycle, as identified in the PPBE process, and provides input to and receives guidance from the Agency Budget Process and Investment Boards that ultimately determine deliverables identified in the transition plan. The completed plan will authorize the investments to be made in the annual tactical plans for use at both the Agency-level and Center-level.

3.5.2 Products and Outcomes

a. An Agency-level IT Transition Plan is formal documentation that integrates all Agency-level domain and cross-domain IT investments, funding requirements, and specific milestones prioritized by year for a period of five years.

b. Separate formal transition plans for each Agency-level Domain and Cross-domain that identify all IT investments, funding requirements, and specific milestones prioritized by year for a period of five years.

c. A Center transition plan is formal documentation that identifies and integrates all Center-level domain and cross-domain IT investments and contains funding requirements and specific milestones prioritized by year for a period of five years. The Center-level transition plans shall align to and complement the Agency transition plan.

d. The transition plans will be delivered 60 days prior to the start of the budget formulation process.

3.5.3 Roles and Responsibilities

a. The NCEA shall be responsible for the delivery of the integrated Enterprise IT Transition Plan which is comprised of Agency-level and Center-level plans. The NCEA will work collaboratively with a variety of stakeholders, including the Enterprise Service Integration Lead, Program/Service Executives, mission and science subject matter experts, domain and cross-domain architects, Center EAs, CTOs, and Investment Managers to develop the plan.

b. The NCEA shall be responsible for integrating the Agency-level domain and cross-domain transition plans and for briefing the integrated Agency transition plan to the appropriate governance boards. The NCEA is the curator of all enterprise-level products.

c. Domain and cross-domain architects are responsible for developing the prioritized set of IT investments, funding requirements, and milestones for each individual domain and cross-domain transition plan. The domain architects will work collaboratively with the NCEA, other domain and cross-domain architects, Center architects, mission architects, service executives and other stakeholders. Domain and cross-domain architects are curators of their respective products.

d. The Center EA shall be responsible for developing their respective Center Transition Plans that align with and complement the Agency Transition Plan. The Center architects will work collaboratively with the NCEA, domain and cross-domain architects, Center architects, mission architects, service executives, and other stakeholders. The Center EA is the curator of all Center-level products.

3.5.4 Procedural Requirements/Governance

a. The NASA EA Board is the approval authority for the Enterprise Transition Plan, in consultation with appropriate governance bodies. The EA Board is responsible for overseeing the development of the Enterprise Transition Plan.

b. Center-level transition plans are approved by the appropriate Center governance board(s) and shall align with and complement the Agency Transition Plan.

3.6 Agency Budget Guidance (PPBE)

3.6.1 Description

NASA develops its budget in accordance with the PPBE process. The PPBE process requires an enhanced level of analysis during budget formulation to ensure that resource alignment supports the accomplishment of Agency strategic goals and objectives. As part of budget formulation, the Agency budget guidance must align with the IRM Strategic Plan. The Enterprise IT Transition Plan is provided to the Investment Boards and other stakeholders during the budget process. This plan provides an integrated path to the target architecture and ensures alignment to the IRM plan's goals and objectives.

3.6.2 Products and Outcomes

Agency budget guidance is produced as part of the annual PPBE process. The budget guidance received from the PPBE process is used as an input to develop tactical plans and to update the transition plans.

3.6.3 Roles and Responsibilities

a. The NCEA, as the overall transition plan integrator, will advocate for appropriate investments that support the transition plan, by coordinating with service owners, program/service executives, portfolio managers, CIOs, and other stakeholders. As part of the Investment Review process, the NCEA shall analyze and communicate any gaps, risks, or potential impacts associated with unfunded goals and activities to the Investment Review Board(s). The NCEA will also review all Summary Investment Business Case (SIBC) entries and all major IT investments to produce findings and recommendations to validate alignment of the investment with the target architecture and transition plan.

b. Domain and cross-domain architects will help advocate for appropriate investments that support their particular transition plan, by coordinating with the NCEA, service owners, program/service executives, portfolio managers, CIOs, and other stakeholders. As part of the Investment Review process, the domain and cross-domain architects shall analyze and communicate any gaps, risks, or potential impacts associated with unfunded goals and activities to the Investment Review Boards associated with their domain. Domain and cross-domain architects should review all SIBC entries and all major IT investments associated with their domains to produce findings and recommendations to validate alignment of the investment with the domain target architecture and transition plan.

c. The Center architects will advocate for appropriate investments that support the Center Transition Plan, by coordinating with service owners, program/service executives, portfolio managers, Center CIO, and other stakeholders. As part of the Investment Review process, the Center architect shall analyze and communicate any gaps, risks, or potential impacts associated with unfunded goals and activities to the Center Investment Review Boards. The Center architect should also review all Center SIBC entries and all major Center IT investments to produce findings and recommendations to validate alignment of the investment with the Center target architecture and transition plan.

d. Investment owners should utilize the review findings and recommendations to make appropriate changes to the investments.

e. Investment owners, portfolio managers, and the CIOs should utilize the EA findings and recommendations to make informed decisions about investments.

3.6.4 Procedural Requirements/Governance

a. NPR 9420.1 - Budget Formulation

b. OMB Circular A-11- Preparation, Submission, and Execution of the Budget

c. NPR 2800.1B - Managing Information Technology

3.7 Tactical Plan

3.7.1 Description

The Enterprise IT Tactical Plan is the Agency's current execution year plan to implement the approved and funded investments identified in the transition plan and authorized through the PPBE process. The tactical plan is an integrated document, based on prioritized, annual investment milestones. The plan includes all domain and cross-domain investments at the Agency-level and Center-level.

3.7.2 Products and Outcomes

a. A formal integrated Agency-level plan that includes all Agency-level domain and cross-domain strategic performance criteria, annual project milestones, deliverables, and risks for each authorized Agency investment for the current execution year.

b. Formal Agency-level plans for each domain and cross-domain that aggregate all strategic performance criteria, annual project milestones, deliverables, and risks of each authorized investment for the current execution year.

c. Formal Center-level plans that include all Center-level domain and cross-domain strategic performance criteria, annual project milestones, deliverables, and risks for each authorized Center investment for the current execution year. The Center plan aligns and complements the Agency tactical plan.

3.7.3 Roles and Responsibilities

a. Based on outputs from the PPBE process, the OCIO Capital Planning and Governance Division shall be responsible for creating the integrated Agency Tactical Plan in partnership with the NCEA, Program/Service Executives, Domain and Cross-domain Architects, Center EAs, CTOs, and Investment Managers.

b. The NCEA shall be responsible for reviewing alignment of the Tactical Plan with the Transition Plan, and validating linkages to the Agency Strategic Plan.

c. The domain and cross-domain architects shall be responsible for reviewing alignment of the Tactical Plan with their respective Transition Plans to ensure linkages to the Agency Strategic Plan.

d. The Center EA shall be responsible for collaborating with Center CIO and Center executive management to develop the Center Tactical Plan that aligns with and complements the Agency plans.

3.7.4 Procedural Requirements/Governance

Agency-level IT governance boards are the approval authorities for the NASA Agency Tactical Plan. Center-level tactical plans are approved by the appropriate Center governance board(s).

3.8 Project and Activity Reviews

3.8.1 Description

a. NASA projects are finite undertakings to create a product, service or result and have a defined beginning and end. NASA EA project reviews take place as projects move through the various life-cycle gates at the Agency-level and Center-level. An activity is a component of work that is performed periodically or part of an overall process, product, or service and does not have a defined beginning and end. These reviews ensure that projects and activities are aligned to the Agency and Center Target Architectures and Transition Plans.

b. EA project and activity reviews shall be included in existing project management reviews and in milestones, rather than conducted as stand-alone activities. This will minimize overlap with other reviews, while providing broader discussion of EA findings and recommendations.

c. The NASA EA checklist is used to ensure application of standard review criteria and to provide feedback to continuously improve the project and its alignment with the target architecture.

3.8.2 Products and Outcomes

a. The NASA EA checklist is utilized during EA reviews to provide a comprehensive and evolving reference to the target architectures at both the Federal-level and Agency-level to which projects and activities must align. The data collected through the checklist identifies the degree of alignment with the target architecture and transition plan. Centers can add content to the checklist that supports specific architecture data required for a Center review.

b. Results of the project and activity reviews are summarized in the form of findings and recommendations. These results provide guidance to project managers, sponsors, portfolio managers, and other stakeholders to support informed decisions on IT projects and future project funding.

c. The Agency EA repository accumulates data from all reviews to measure progress toward Federal and Agency initiatives such as sharing and reuse, regulatory compliance, and integrated service catalogs and help desks.

3.8.3 Roles and Responsibilities

a. The NASA EA checklist and associated processes are the responsibility of the NCEA, with support from the EA community.

b. The EA Project and Activity reviews are performed by NASA OCIO/NCEA approved architects familiar with the EA checklist and EA processes.

c. Project managers and technical leads should utilize the review findings and recommendations to make appropriate changes to the projects and activities.

d. Project sponsors, portfolio managers, system owners, and the CIOs should utilize the EA findings and recommendations to make informed decisions about project and activity investments.

3.8.4 Procedural Requirements/Governance

EA reviews are required in accordance with NPR 7120.7 guidelines. Reviews on activities or projects that don't meet NPR 7120.7 criteria may be initiated by the Agency or Center architects, program or project managers or project or activity sponsors.

3.9 Current Architecture

3.9.1 Description

a. NASA's current architecture describes the current state of NASA IT environment. The current architecture is built from an aggregation of information about IT services, applications, and assets across the Agency.

b. This information is drawn from multiple Enterprise, Mission, and Center sources, including, but not limited to, architectural tools, project and activity reviews, IT service catalogs, end-user configuration management databases, system-level designs, application inventories, and all other IT asset inventory systems.

3.9.2 Products and Outcomes

a. Data about the current architecture is collected as needed from multiple sources, including data calls, and automated tools and is consolidated within the enterprise architecture repository.

b. The current architecture data provides support for service and operational reviews that in turn provide change driver information to the IRM process.

c. The current architecture is an assessment tool for measuring maturity and progress towards the NASA to-be state and provides key information for Office of Management and Budget (OMB) submissions.

3.9.3 Roles and Responsibilities

a. Management and documentation of all service and operational assets are the responsibility of service owners and providers who shall make this information available to NCEA and other architecture stakeholders on an as requested basis.

b. The NCEA, in close collaboration with stakeholders, shall develop and maintain Agency-level architectural standards and models to ensure current architecture information is accurately maintained and reported.

c. Domain architects, in close collaboration with stakeholders, shall develop and maintain architectural standards/models to ensure current architecture information is accurately maintained and reported for their respective domains.

d. Cross-domain architects, in close collaboration with stakeholders, shall develop and maintain architectural standards/models to ensure current architecture information is accurately maintained and reported for their respective domains.

e. Center architects, in close collaboration with stakeholders, shall develop and maintain architectural standards/models to ensure current architecture information is accurately maintained and reported for their respective Centers. Center standards shall align with and complement Agency standards. 3.9.4 Procedural Requirements/Governance a. The NASA CIO is the approval authority for the Agency IT architecture standards/models, in consultation with appropriate governance bodies.

b. Center-level standards/models reviewed and approved by the Center CIOs, in consultation with appropriate Center governance board(s), and shall align and complement the Agency standards/models.

3.10 Service and Operational Reviews

3.10.1 Description

a. NASA EA service reviews evaluate whether current operational IT services are achieving intended results, meeting business requirements, and performing at agreed upon service levels. Operational reviews assess functional requirements and the operational performance of the supporting IT infrastructure. The reviews help identify opportunities to improve NASA IT services and provide input back into the enterprise architecture process steps.

b. Service and operational reviews are initiated by NASA Enterprise Architects when opportunities to improve the architecture are identified by indicators such as customer feedback, external drivers, or performance metrics. A service review may also be initiated by service owners to assess the value of current or future investments.

3.10.2 Products and Outcomes

a. Service and operational reviews employ the NASA EA checklist to identify the degree of alignment to the evolving target architecture and services portfolio. The reviews determine whether sustained investment in the existing services is justified or improvements are needed.

b. Opportunities for cost savings from sharing and reuse are considered through analysis of similar services offered in inter-Agency and extra-Agency service catalogs. Potential budget shortfalls or cessation of services are documented to show the impact and risks to the business and missions.

c. The service and operational reviews are summarized in the form of findings and recommendations that shall be provided to the service owners, portfolio managers, and other stakeholders. The checklist data and findings are aggregated in the EA repository.

3.10.3 Roles and Responsibilities

a. The NASA EA checklist and associated processes are the responsibility of the NCEA with support from the Center EA community.

b. The service reviews are performed by NASA OCIO/NCEA approved Enterprise Architects familiar with the NASA EA checklist and associated processes.

c. Service owners, program/service executives, and portfolio managers should utilize the review findings and recommendations to support informed investment decisions.

3.10.4 Procedural Requirements/Governance

The results of the NASA EA service reviews and operational reviews are inputs into OCIO's performance management process. OCIO periodically reviews investment performance to validate that approved investments are being executed according to plan and are achieving the intended strategic benefits. EA service and operational reviews input back into the strategic planning and enterprise architecture processes.

3.11 Change Drivers

3.11.1 Description

Change drivers are forces that create a change in the IT environment that may impact NASA. These changes influence the NASA Strategic Plan and inform the IRM planning processes. The drivers provide input from programmatic and institutional customers on their strategy, IT needs, opportunities, vulnerabilities, constraints, and goals that are critical to developing a comprehensive IT strategy for NASA. The drivers also include information on laws and mandates, policy and policy changes, technology trends, risks, and other environmental factors or gaps that impact IT planning.

3.11.2 Products and Outcomes

a. Change drivers are formalized in an integrated collection of IT-related data and analysis deliverables. These deliverables will be communicated through the OCIO, as input into the NASA Strategic Planning process.

b. Change drivers will be delivered to stakeholders at least 30 days prior to the start of the NASA Strategic Planning Process.

c. Types of change drivers include, but are not limited to:

(1) Industry/technology trends in the commercial and government sectors. They provide some insight into what IT could or should be utilizing to support its mission.

(2) Mission IT needs are derived from analysis of mission business needs which are translated into IT requirements.

(3) IT technology research and development investments, as described in the Strategic Space Technology Investment Plan and the associated IT Technology Roadmaps, are developed and maintained by the Office of Chief Technology.

(4) Service reviews provide analysis of deployed IT services at NASA and how well the services are performing. These reviews identify opportunities for service improvement or enhancement.

(5) Analysis of current IT environment.

(6) Policy and policy changes impacting the enterprise architecture and its goals, objectives, and priorities.

(7) Standards identify all commercial, governmental, and internal NASA standards that apply to NASA IT.

(8) Laws and mandates that impact NASA IT.

(9) Risks that threaten the ability of current IT infrastructure to support the achievement of NASA's strategic goals.

(10) Other environmental factors or gaps not previously mentioned that could or will have an impact on IT decisions at NASA.

3.11.3 Roles and Responsibilities

a. The NCEA shall facilitate the gathering, development, analysis, and integration of all IT-related change drivers into a coherent artifact for approval by the OCIO. This approved artifact is then delivered to the strategic planning and architecture stakeholders. The NCEA should collaborate with domain architects, cross-domain architects, Center architects, mission architects, service executives, and other councils, boards, and stakeholders in the development of the change drivers. The NCEA is the curator of the change driver package artifact.

b. The Council shall develop, maintain, and provide analysis of all industry/technology trends and collaborate with the NCEA in integration of those trends into a coherent change driver package for delivery to strategic planning and architecture stakeholders. The CTO-IT Council will collaborate with domain architects, cross-domain architects, Center architects, mission architects, service executives, and other stakeholders in the development of the trends. The CTO-IT Council is the curator of all industry/technology trends products.

c. Domain architects shall develop, maintain, and provide analysis of all change driver areas as they relate to their domains and collaborate with the NCEA in integrating those change drivers into a coherent change driver package for delivery to strategic planning and architecture stakeholders. Domain architects should collaborate with cross-domain architects, Center architects, mission architects, service executives, and other stakeholders in the development of the change drivers. The domain architects are the curators of all change driver products that relate to their respective domains.

d. Cross-domain architects shall develop, maintain, and provide analysis of all change driver areas as they relate to their domains and collaborate with the NCEA in integrating of those change drivers into a coherent change driver package for delivery to strategic planning and architecture stakeholders. Cross-domain architects should collaborate with domain architects, Center architects, mission architects, service executives, and other stakeholders in the development of the change drivers. The cross-domain architects are the curators of all change driver products that relate to their respective domains.

e. Center architects shall facilitate the gathering, development, analysis, and integration of all Center IT-related change drivers into a coherent artifact for approval by the Center CIO. The approved artifact is then delivered to the Center strategic planning and architecture stakeholders as well as to the NCEA. The Center architect should collaborate with domain architects, cross-domain architects, Center architects, mission architects, service executives, and other Center councils, boards, and stakeholders in the development of the change drivers. The Center architect is the curator of the Center change driver package artifact.

3.11.4 Procedural Requirements/Governance

Agency change drivers will be approved by the OCIO before being provided to Agency-level strategic planning and architecture stakeholders. Center change drivers will be approved by the Center CIOs before being provided to Center-level strategic planning and architecture stakeholders.



| TOC | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | AppendixA | AppendixB | AppendixC | ALL |
 
| NODIS Library | Legal Policies(2000s) | Search |

DISTRIBUTION:
NODIS


This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.