/CollaborationProgram/ArchitectureHarmonization/4866/home.htmlThe NGOSS Technology Neutral Architecture provides the necessary structural underpinnings and building constructs to support the analysis, design, implementation and deployment of open distributed computing solutions. By using the NGOSS Architecture and the vehicle of the NGOSS Contract it now becomes possible to move away from the traditional focus on providing interface definitions and begin offering more of  an end-to-end view of the Lifecycle to include visibility, traceability and linkage that enables the interests of the various stakeholders to be protected by representing the evolution of their interests as the solution progresses from the definition of the business concerns, through the mapping to a particular architecture and implementation and on to deployment.

The Contract is the fundamental unit of interoperability within an NGOSS solution and is the architectural construct used to capture the specification of how a managed entity will interact with its environment. Within the NGOSS Architecture, Contract-based interaction builds from work done by ANSA as documented in the RM-ODP specifications as well as from current software technologies like Java.  However, none of these approaches addressed the issue of different users requiring multiple tailored views of the same inherent Contract. Indeed, most preceding work has focused on the definition of Application Programming Interface (API) aspects of interactions and thus where focused on the implementation and run-time concerns of software interaction. The NGOSS Architecture, using the vehicle of the NGOSS Contract (with representation in each NGOSS Lifecycle View) moves beyond this traditional focus in order to provide an interface definition mechanism that offers end-to-end Lifecycle visibility, traceability and linkage in addition to the traditional functional API definition.

The basic description of an NGOSS Contract, no matter the View being represented, is made up of five main parts:

• General Contract Part: Common to all Contracts for each View
  • Header Part: This part identifies the Contract in an unambiguous way, and hosts a placeholder for a textual description of the Contract;
  • Descriptive Part: This part contains the goal of the Contract, along with descriptive information and a set of search criteria to facilitate searching for this Contract.
• Functional Part: This part defines the capabilities provided by the Contract; the pre-conditions needed for correct operation, the post-conditions resulting from correct operation and defines a context for the capabilities.
• Non Functional Part: This part defines aspects which govern or restrict the bounds of operation of the capabilities specified by the Contract (e.g., external influences such as technological limitations, legal or regulatory limitations and organizational limitations), as well as other considerations (e.g., cost).
• Management Part: This part defines the management capabilities needed to operate administer and maintain the Capabilities of this Contract.
• View Specific Model Part: This part contains various types of models (UML and others) tailored to support the specific View of the Contract (i.e., Business View Models or System View Models) being represented.