C4I system lifecycle and Enterprise Architecture
This is a short story of some experiences collected in the Finnish Defence Forces while using Enterprise Architecture method in developing Command, Control, Communications, Computers, Information, Intelligence, Surveillance, Target Acquisition and Reconnaissance capabilities from life cycle point of view as described in figure 1.
Figure 1: Using Enterprise Architecture to steer C4ISTAR lifecycle
Paper is using an applied model for C4I System of systems life cycle as follows:
- In military business there is always need to keep certain capability in operations or in readi-ness. This governs the management of all components of capability. Change and sustain is op-timized through the life cycle and all change iterations are done by changing only some parts of C4I system of systems.
- Modeling and simulation is important phase for military since they always grave for asymmet-ric advantage over adversary’s capability. Only those forces that have infinite resources or are dominating over their potential adversary may copy best practices or other forces solutions. Modeling and simulation is providing several options both to capability concepts and their sys-tem solutions.
- As military is graving advantage by changing their complex system structure, there is a need to experiment both competence, processes and technical tools. This is done both in frame exer-cises and live exercises. Both USA and NATO are experimenting in Multinational Experiment (MNE) and Coalition Warrior Interoperability Exercise (CWIX). As new possibilities are recognized in experimenting, they are also introduced to C4I reference environment to see how they will change existing C4I structure. After analyzing the change situation, there may be resolution taken to give capability component for vendors to produce.
- Any new component from development program or all changes in existing systems are intro-duced in C4I reference environment. They will overcome both technical and functional inte-gration, testing and evaluation. At least Material, Information, Integration and Learning com-ponents are tested from the whole DOTMLPFII sphere. USA and NATO are using Combined Endeavour exercise to provide reference testing for all major changes in their Mission Net-work and integrated structures of their multinational C4I systems. After the change has passed all tests, the change manager may approve it to proceed to pilot environment.
- Pilot environment takes change to continue further adjusting all other DOTMLPFII dimensions in place. Pilot will create migration package with all changes and training needed to successful transformation. When all piloting is done successfully, change manager may propose to pro-ceed to migration in production environment. Change Advisory Board (CAB) will assess pro-posal and give their recommendation. Chief of Service Operation orders migration and follows it through the whole production environment collecting feedback to reference environment to learn or solve.
Case 1: Pointing irrationality
In the very first years of distributed information technology military often developed IT-system for each function. This happened because functions were both in business and finance. Outcome was often a kaleidoscope of several hundreds of different IT systems each tailored individually to support single function. There was no interoperability at data level nor possibility to achieve any kind of process integration.Enterprise Architecture, EA may be used to describe how things have evolved or drifted to existing situation. It may be used to pinpoint the fact of how irrational it would be to continue following the same path or remaining in that place.
By describing existing situation with enterprise architecture, the Finnish Defence Forces was able to come up with decision to stop all functionally focused IT development, adopt one Enterprise Resource Management, ERM platform and take huge leap in process integration and improvement by adopting to generic supply chain management model.
Case 2: Defining Future vision
A typical situation to call architecture to help sense making is when military is trying to describe new strategy for force utilization. As information is becoming an asset, also military tried to define their business and processes with a model and systemized description language.Enterprise architecture may be used to describe future end state of military business, processes, information utilization and information technology. It may give clearly defined goal to system architecture to be able to deliver system with business integration.
The Finnish defence forces tried to describe their main business processes, datamodel and technical system in order to take longer leap in gaining “information superiority” over possible adversaries. First attempt was successful in defining the main Command and Control, C2 processes and implementing them with Service Oriented Architecture, SOA technology based on best international practices. Everything was successfully accomplished and pilot indicated major improvements in both planning quality and execution promptness. Despite initial success, program failed to field the semi-automated processes since they were not answering the expectations of existing staff working culture. Digitized processes were too rigid and existing operational maturity was not ready to adapt to different art of operations.
Second attempt to define technology from very beginning seemed good on paper, but failed when both IT technology and data model were too ambitious to be successfully implemented. It never proceeded beyond reference environment. Reason for failure may have been insufficient model-ling and simulation or experimenting. There might have been high ambition to field solutions of other Forces and not understanding their constraints in national defence.
Case 3: Describing the future C4I System of systems
As military system integration improves it becomes challenging to manage a large number of interconnected systems called System of Systems, SoS. Complexity is increased as several different generations of ICT systems should interact and provide quicker response to improved requirements by end users.Architecture may be used to describe constraints of future System of systems and provide better defined area of innovation and experimentation within integrated project teams including both military users and vendor designers. Architecture may be given to vendors to propose their prototypes or concepts for users to experiment. It is easier to users to decide what they want when they have tangible choices to experiment and compare.
The Finnish Land Forces defined a concept description for their next generation tactical communications systems and invited different vendors to demonstrate their possible solutions fitting into described technical cap. Vendors both from defence industry (MOTS), providers of commercial tailored solutions and Commercial of the Shelf, COTS integrator's appeared and a strategy of three parallel paths was created. All three courses were advanced to next experimentation status and suitable solution was found fitting to organizations maturity.
Case 4: Aligning technical and tactical migration of C4I improvement
The most difficult task in military C4ISTAR capability development is to match steps of improvement coherently through all Doctrine, Organization, Training, Material, Leadership, Personnel, Facilities, Information and Integration (DOTMLPFII) components.Architecture descriptions may be used in communicating the urge of improvement to several stake holders, whose action is imperative to integrate different components produced by several paths within reasonable window of time.
The Finnish Land Forces was able to succeed in iterative development of their C4I capability by using both architecture and reference environment to help orchestrating several waves of migration through the entire Land forces. Architecture was a reference point and way of defining key performance indicators when each wave of change went through reference and pilot testing and finally released to operations. It also helped to collect feedback from each stage and manage changes in following iterations.
Enterprise Architecture might remain only a document if CIO does not give a task and meaning for it
According to Finnish experience, the best outcome of architecture work is achieved when:• There is a definite goal for each description as in cases 1, 3 and 4
• Architecture is paired with real world reference as in cases 3 and 4
• Architecture is defined suitable to each phase of development and not falling in believe that everything may be described in the beginning as in case 2.
