To fully leverage the benefits of enterprise architecture, information technology (IT) solutions must align with the architecture's standards and guidelines. IT project teams will likely seek formal recognition or certification from the IT Architect that their IT solutions comply with these standards and guidelines. This process is referred to as “filing for compliance.” Other times, IT project teams will want to “self-certify” that their solutions align with enterprise architecture guidance.
However, in the course of developing IT solutions, there are times when a technology standard is not defined, or it is neither feasible nor realistic to comply with the standard (as defined in the Technology Architecture). In these situations, IT project teams request approval to deviate from prescribed standards. The process of managing these requests is referred to as “exception handling.”
Exception handling is a critical process for managing technical risk, tracking the emergence of non-mainstream technologies, and ensuring architecture flexibility. It ensures that the requested technology component does not expose the NIH to unnecessary levels of risk.
There are currently two ways NIH IT project teams and stakeholders ensure compliance with the NIH Enterprise Architecture. One approach is to file for compliance via NIH's Capital Planning and Investment Control (CPIC) process. The other approach is through self-certification.
File For Compliance Through CPIC. IT projects that meet the threshold requirements for a CPIC review (as determined by NIH's CPIC Policy) will undergo an architecture review to ensure compliance with the NIH Enterprise Architecture. In these situations, project managers fill out the architecture sections of the Office of Management and Budget (OMB) Exhibit 300, as required by OMB Circular A-11.
The NIH CPIC Review Board (CPIC-RB), on which the Office of the Chief IT Architect (OCITA) has a seat, reviews the Exhibit 300 for alignment with the enterprise architecture. If IT solutions do not comply, they must obtain an Architecture Exception by forwarding an Architecture Exception Request to the Chief IT Architect. Otherwise, the associated risk will be relayed to the IT Review Board (ITRB) as part of the CPIC process, which reviews funding for the project.
The CPIC process was formalized in 2005, and the Chief IT Architect recognizes that time is needed for systems to change how they operate in order to comply with the architecture. Therefore, OCITA established a four-phase process to allow IT project teams to bring their IT solutions into alignment with the CPIC review process:
- 2005 - the steps were publicized and systems were asked to answer the question whether or not they have business process and data models.
- 2006 - system must supply the business process and data models to the architect in order to be able to check the "complies with the enterprise architecture box on the form 300B.
- 2007 - systems' process and data models must map to enterprise architecture process and data models.
- 2008 - systems' process and data models must conform to the NIH Enterprise Architecture.
In addition, the project manager should meet with the Chief IT Architect when planning a new IT project and be prepared to discuss system development issues. The team's software development lifecycle (SDLC) and/or project plan must include the interactions needed between the Chief IT Architect during the various development stages.
For IT projects that do not meet the CPIC requirements for review, but for which the team or application owners would like an official compliance certification, the project manager or lead may contact OCITA at EnterpriseArchitecture@mail.nih.gov for a formal, ad hoc architecture compliance review.
Self-Certification. In the self-certification approach, IT project teams and application developers reference the applicable NIH Enterprise Architecture bricks and patterns to ensure their designs are compliant. IT project teams should continuously reference the technology architecture throughout the application's lifecycle to ensure it remains in compliance.
According to NIH's principal enterprise architecture principle, the NIH Enterprise Architecture "applies to all aspects of NIH Information Technology (IT)." However, business requirements sometimes necessitate a temporary exception. In these situations, IT project managers submit an Architecture Exception Request to the Chief IT Architect by executing the exception process. Generally, exceptions are temporary and limited in scope.
When an individual submits an exception request, the NIH Chief IT Architect determines if it is major or minor exception. The NIH Chief Information Officer (CIO) adjudicates minor exception requests while the Architecture Review Board (ARB) adjudicates major exception requests.
Major Exception Requests. A request is usually classified as "major" if it meets one or more of the following criteria:
- The total remediation cost for the exception exceeds ten percent of the project value.
- The total remediation cost exceeds $1 million.
- The exception will introduce a product, technology, or practice not currently in use at the NIH, or is categorized in an architecture brick as "emerging" in the NIH Enterprise Architecture.
- The exception violates an NIH Enterprise Architecture principle.
- The exception is a product, technology, or practice, which is categorized in an architecture brick as "containment" or "retirement" in the NIH Enterprise Architecture.
- The exception does not comply with the data standards for a system for which it creates, updates, or deletes data.
Major exception requests are adjudicated on a monthly basis to coincide with the ARB's monthly meeting schedule.
Minor Exception Requests. Generally, all other exception requests will be considered to be "minor." The exception process to review and adjudicate “minor” exception requests takes approximately 10 business days.
Decision Criteria. In exercising the discretion to approve an exception request, the approval authority (NIH CIO or ARB) will consider the following criteria:
- The impact (business and technical) of not granting the exception.
- The technical merit of the exception.
- The collateral impact to other systems and business processes.
- The impact to the NIH Enterprise Architecture.
- Alternatives to granting the exception.
- Precedent setting effects.
Decision-makers will also consider the NIH IT Enterprise Architecture principle, “Components”, which states:
"The NIH Enterprise Architecture supports leading edge technologies to meet mission-differentiating needs and requires mature, prove interoperable technologies in support of service environments. Technical diversity that does not tie to business needs is discouraged."