Within NATO the two Strategic Commands (ACE and ACLANT) are equipped with different C2-systems: basically ACE-ACCIS1 for ACE and MCCIS2 for ACLANT.
In reaction to the NATO Washington Summit (April 1999) a double convergence between ACE and ACLANT on the one hand and between the Command and Control Systems and the Management Information Systems on the other hand has been initiated in order to improve the interoperability and the cost efficiency of these systems. As the combination of the C2-services and MIS-services is called AIS (for Automated Information System), the common system target between the two Strategic Commands is therefore called Bi-SC AIS.
In practice the convergence is envisaged incrementally, whereas the first implementation target revolves around a common "core capability". Such a concept is close to The Open Group's "Boundaryless Information Flow" initiative and consists in harmonizing / standardizing the foundation IT services throughout the two command structures and also implementing common applications where possible.
The applications are categorized into:
The breakdown of the overall AIS target into "implementation segments", the articulation of these segments and the planning and management of their implementation, are of course many issues which cannot be successfully addressed without a sound and comprehensive architecture of the system targeted.
In order to avoid a "big-bang" development of such a "Target Architecture", which would be almost mission impossible at this scale, the architectural process has been divided into two parallel development activities with different objectives and scopes, namely:
The respective customers of these two kinds of architectures are the "stakeholders" on the one hand and the end-users and implementers on the other hand.
As explained in the Introduction to the ADM (under Time Horizon), 'In such an approach, the Target Architecture is evolutionary in nature, and requires periodic review and update according to evolving business requirements and developments in technology, whereas the Transitional Architectures are (by design) incremental in nature, and in principle should not evolve during the implementation phase of the increment, in order to avoid the "moving target" syndrome. This of course is only possible if the implementation schedule is under tight control and relatively short (typically less than two years)'.
An implementation plan, which both considers the operational priorities and the architectural constraints, and consequently defines the optimal implementation sequence, is required to transition from an agreed high-level Target Architecture to a Transitional Architecture dedicated to the first implementation target.
The following figure illustrates the above considerations and stresses the role of the Architects, who mediate between the stakeholders and implementers and are supposed to maintain the consistency of the whole edifice. They typically aim to reduce the latent gap or lack of understanding between stakeholders and implementers that is caused by the increasing complexity of their respective activities.
Figure 1: Role of architects vis-à-vis the stakeholders and implementers
The high level Target Architecture of the Bi-SC AIS has been developed and endorsed in the years 2001 and 2002, and has entered a maintenance process, whereas the Transitional Architecture for the first Bi-SC AIS implementation Target has been initiated.
The architectural consistency of these two architectures is largely based on the following factors:
The adoption / customization of a comprehensive architectural methodology, which would formally relate all the architectural tasks and make the linkage with the implementation projects, is still an issue. There is still some risk for a target architecture to be misinterpreted by implementers, whereas its traceability with the strategic objectives and mapping with the operational requirements remain both critical.
The TOGAF ADM is considered as a valuable starting point for the methodology, due to its adaptability and comprehensiveness. The concept of system "building blocks" is perceived as crucial to manage the interdependency between the aforementioned Target Architectures and to communicate with the users and implementers. Moreover, the latest release of the ADM (Version 8) explicitly supports an incremental approach and makes use of the IEEE1471 concepts (stakeholders, views and viewpoints...) which are fully applicable to a large organization like NATO.
The current architectural development is based on the following paradigms.
The architectural description is broken down into three views:
The three architectural views are described in three distinct levels of abstraction (conceptual, logical and physical) which enables a progressive development and facilitates the validation/exploitation of the architectural description. It is indeed no use developing a logical description of a view if the underlying concepts are not clear or agreed. The same way, a detailed physical description of a view, which deals with the site characteristics, is only possible when a common logical description is agreed.
The following figures describe the expected properties of the architectural rows and columns:
Figure 2: Expected properties the architectural model
Such a model, based on a 3 by 3 matrix, is also likely to facilitate the maintenance of the architectural descriptions and the consistency of the whole architectural process. A detailed mapping of this model with the aforementioned (NATO or US-C4ISR) "architectural templates" is available but exceeds the scope of this paper and is replaced by the following figure, which gives an overview of the internal structuring of the architectural description:
Figure 3: Overview of the structuring of the architectural description
The linkage of architecture with its environment is perceived as follows.
Some underlying "principles and objectives", derived from the stakeholders' views, pertain to the whole architectural model, whereas the operational context, the feedback from the fielded baseline, the "state-of-the art" or the user or system requirements apply to the model as follows:
Figure 4: Linkage or the architectural description with its environment
1 Allied Command Europe - Automated
Command and Control System
2 Maritime Command and Control System
3 Command Control & Communications