Currently there are two standard ways and one ad hoc way for information technology (IT) project teams to ensure their IT solutions comply with the NIH Enterprise Architecture. The two standard approaches are to file for compliance via NIH’s Capital Planning and Investment Control (CPIC) process and to self certify. The ad hoc approach is to contact the Office of the Chief IT Architect (OCITA) directly and request an architecture review of the solution. In the future, IT project teams will be able to file for compliance directly with OCITA via this website.
File For Compliance Through CPIC
As governed by NIH’s CPIC Policy, IT projects that meet one or more of the threshold requirements for a CPIC review will undergo a formal architecture review to ensure compliance with the NIH Enterprise Architecture. (Please note, this process is governed by the NIH CPIC Policy)
- If the IT solution is a new investment, the project manager (PM) of the IT solution will complete a “Project Prospectus.” However, if it is an existing investment undergoing an investment review, the PM will update the investment’s Office of Management and Budget (OMB) “Exhibit 300” (as required by OMB Circular A-11) to ensure its currency through ProSight. Both of these documents request architecture-related details about the IT solution. In addition to the information that is requested in the Exhibit 300 or the 'Project Prospectus,' OCITA requests a business process model and a data model for the business processes that will be affected by the project.
- The PM submits the 'Project Prospectus' or Exhibit 300 to the NIH IT Policy and Review Office (ITPRO), where it is reviewed for completeness.
- The CPIC Review Board, with OCITA representation, evaluates the IT solution for architecture compliance and risk. It is important to note that an IT solution will be determined to be in compliance if it incorporates “non-standards” and is accompanied by an approved Architecture Exception Request.
- If the solution is compliant, the CPIC Review Board will recognize it as such.
- If the solution is not compliant the PM will be contacted and asked to either seek a waiver through the exception process or re-architect the solution to ensure compliance.
Self Certify
Self certification is the process for IT project teams to independently ensure their solutions comply with the standards set forth in the
NIH Enterprise Architecture. The following scenario illustrates a typical process for how an IT project team will self certify. If at any point during self certification a project team requires or requests OCITA’s support, they are to contact OCITA at
enterprisearchitecture@mail.nih.gov.
(This scenario addresses the following phases of the system development lifecycle: Plan – Design – Develop – Test – Implement – Maintain. It is not intended to prescribe a standard, or complete, SDLC that NIH IT project teams must follow.)
- Plan. The IT project team will reference the Business Architecture to understand what business mission and processes the solution will enable. It will provide them with a solid, high-level understanding of requirements prior to conducting a detailed requirements definition. The project team will reference the Information Architecture to understand what information and application interfaces these processes require. It would be helpful to OCITA, if the project would send copies of business process models and data models that are developed during this and subsequent phases.
- Design. Prior to designing the IT solution, the project team will reference the NIH Enterprise Architecture Principles. These principles will guide the team’s work throughout the system’s lifecycle. They will reference the Information and Technology Architectures to incorporate appropriate data usage/design rules and “approved” technology components (as indicated by inclusion in the “Tactical” and “Strategic” categories of their respective architecture bricks). They will also reference the patterns in the Technology Architecture for design guidance. It would be helpful for the project to contact OCITA to discuss services that are being developed that would be useful to other projects, and to discuss services that the project requires from others.
- Develop. IT project teams will utilize technologies categorized in the “Tactical” and “Strategic” components of their respective architecture bricks, unless accompanied by an approved exception request.
- Test. If test results suggest design or development changes, IT project teams will assess what impact, if any, the potential changes will have on the solution’s alignment with the NIH Enterprise Architecture.
- Implement. Ensure the production environment adheres to the system design and any changes in the production environment remain in compliance with architecture standards.
- Maintain. As the IT solution matures and evolves, the project team will continuously reference the NIH Enterprise Architecture to ensure that changes to the solution remain consistent with the architecture’s guidance. The project team will check the system during each enhancement cycle.
Ad Hoc Request For OCITA Certification
In situations where an IT project does not meet the CPIC requirements for review but the project team (or application owner) would like an official compliance certification, they can contact OCITA at enterprisearchitecture@mail.nih.gov for a formal, ad hoc architecture compliance review. In the future there will be a standard file for compliance process (as opposed to the ad hoc approach available today).