NIH Enterprise Architecture Home

Integration Principles

Description

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

Principles

Plan for Integration - Application integration is required in the early project planning process for enterprise applications. It must be included in the project plan and key deliverables such as requirements, analysis and design.

Rationale: In the past, application integration has often been an afterthought, resulting in missing or inferior interfaces built quickly on a tight budget.

Loosely Coupled Interfaces - Interfaces will be loosely coupled, backward compatible, self-describing, and offer a low impact to the enterprise if changed. (An interface service is tightly coupled to the application of which it is a part.)1

Rationale: Loosely coupled interfaces are preferred, because when interfaces between independently designed applications are tightly coupled, they are (1) less general and (2) are more likely to result in undesired side effects when changed.

Publish Integration Points - “Public” inputs and outputs of an application must be known, published and understood to promote open data exchange and interfaces for enterprise application integration. Diagrams of connections and data syntax and semantics should be published to promote re-use.

Rationale: Lack of understanding results in ad-hoc integration that is inconsistent and inefficient. "Private" interfaces should not be published or used, as their stability is not guaranteed.

Platform Independent, Open Standards - Open standards and industry standards are preferred for enterprise application integration solutions (mandatory for integration outside NIH); mechanisms should be language and platform-independent.

Rationale: This principle will allow for easier integration with the heterogeneous platforms and programming languages that are the norm at NIH today.

Reusable, Shared Services based on a service-oriented architecture (SOA), and other forms of Application Program Interfaces (API), are preferred to direct data access.

Rationale: This approach will minimize direct access to data; thus lowering the risk of bypassing the business logic or compromising data integrity.

Integration Change Management - Software Configuration and Change Management (SCCM) is mandatory for application integration interfaces.

Rationale: SCCM for interfaces is especially important, because multiple applications may be impacted.

Minimize Application Impact - Enterprise application integration mechanisms used should be non-invasive to the applications as much as possible. For instance, data transformation should be done externally from the applications involved.

Rationale: Adding application integration code to existing applications (1) delays integration projects and (2) increases the application maintenance burden.

1. Loose coupling means that services (e.g., enterprise APIs) are designed with no affinity to any particular service consumer. Inside the service, nothing is assumed as to the nature of the consumer. Thus, a service is fully de-coupled from a service consumer. However, the service consumer is dependent on the service (that is, it embeds literal references to service interfaces). The service is also responsible for exception handling. The result is a semi-coupled (or loosely coupled) architecture.

Time Table

This architecture definition approved on: July 26, 2004

The next review is scheduled in: None scheduled.