Skip Ribbon Commands Skip to main content

Description

High level statements of NIH's fundamental values that guide decision-making for applications and applications technology.

 

 

Principles

Application Integration - enterprise applications will include known, published mechanisms for integration.

Rationale: Better application integration will reduce redundant data entry, will decrease the number of reconciliation problems and will make accurate data available quickly. 

Standards Compliance - developers of enterprise applications will comply with all NIH standards in effect at the time. This principle applies to internal or outsourced development and to COTS software, although to a lesser extent.

Rationale: Government policy (a) mandates the adoption of standards and (b) favors COTS applications when suitable.  Therefore, when COTS software does not fully comply with NIH standards, a balanced evaluation is necessary. 

Application Ownership - applications will have an identified business owner and technical owner or lead.

Rationale: Technology is effective only when aligned with business needs. Both technical and business interests will be represented when making decisions.

Comment: Applications will have an identified business owner and technical owner or lead. The owners will share responsibility for the application, with the business owner taking the lead on business matters and the technical owner taking the lead on technical matters.

Application Documentation - enterprise applications will be documented, both internally and externally.

Rationale: Poorly documented applications are expensive to maintain or modify.

Implication: Documentation standards need to be developed.  

Business Alignment - applications will have a stated business purpose. If there are multiple business purposes, they will be closely related.

Rationale: Technology is effective only when aligned with business needs. Also, It is easier to renew applications if there is modularity at a high level.

Comment: This principle is derived from the evolving NIH Information Architecture and is a well-known tenet of information engineering. 

Decision Analysis for Acquisition - a decision to custom build can be made only after an analysis that considers other NIH sources, COTS and GOTS alternatives.

Rationale: Decisions that are made without considering the alternatives may be suboptimal.

Comment: No one alternative is favored for all cases. 

Application Scope Definition - enterprise Applications will meet broad needs. The requirements and design will be published prior to development, and all IC’s will have the opportunity to comment.

Rationale: Enterprise applications that consider only a subset of needs are unsuitable for enterprise-wide use. The result is a necessary proliferation of extension systems, which is inefficient.

Implication: The project plan will provide for this. Adequate communication methods will be developed.

Software Configuration and Change Management (SCCM) - the Software Configuration and Change Management (SCCM) process will be documented and all parties will adhere to it.

Rationale: When software is put into production without a SCCM process, reliability suffers, users are adversely affected, and extra cost is incurred to fix the problems.

Implication: Developers and maintainers of enterprise applications will have a CM process.

Systems Development Lifecycle (SDLC) - the systems development lifecycle will be documented and repeatable.

Rationale: Without an SDLC, software development is haphazard and risky.

Implication: Developers and maintainers of enterprise applications will have a documented SDLC.

Comment: The authors of this principle recognize that there are many well-known development methodologies. They intentionally avoided favoring one.

Reusability of Components - applications should be assembled, in part, from reusable components or services.

Rationale: Reusable components lower cost of subsequent application development, but are initially more expensive to build than single-use components.

Implication: Developers should create new components as part of the implementation of new functionality. 

Comment: The development of modular components and services is always favored, but not all components will or should be highly reusable.


Time Table

This architecture definition approved on: September 2, 2003

The next review is scheduled in: None scheduled.