There is more than one way to develop your ICT based capabilities in Military Environment

Abstract

This paper introduces several development models for ICT based capabilities. Paper recognizes both continuous and discrete development but concentrates mainly on latter. Development models are adjusted to situation and environment described by Cynefin model. Besides waterfall development utilized in known environment, there are also incremental development for knowable situation, spiral development for complex situation and experimental development for chaotic environment. Paper concludes in discussion of managing all development possibilities together.

Do not directly accept System Development Life-Cycle method as your only ICT capability development – Analyse the situation first

Information and Communications Technology is becoming even greater enabler to military force as their digitalization  is proceeding. There is a natural approach for ICT engineers to develop systems by utilising Systems Development Life Cycle  method sometimes also called waterfall  approach. This paper introduces an analysing method for choosing between different development models and provides a few examples of their use. There is more than one way to develop ICT enabled capabilities in military environment. See figure 1.

Figure 1: One development method does not fit to all situations and change approaches

In developing ICT enabled capabilities there are two main lines of business: Lean development and disruptive development. Lean development (continuous improvement, kaizen)  is systems continuous adaptation to changes by:

• monitoring its performance and effect and 
• altering its configuration and operation to match the changing needs. 

Normally this is done within operations expenditure, OPEX.

Disruptive development (radical improvement, kaikaku) calls separate organization to design and produce new parts for capability and then implement them in existing structure of people, processes and technology. Normally this is done within capital expenditure, CAPEX. This study is focused more on latter development and choosing applicable method from environment and object point of view.

First one should analyse the environment where developed capability will be implemented. To create understanding of different environments this paper uses Cynefin framework  of Known, Knowable, Complex and Chaos situations.

Second one should analyse the object that needs to be transformed in order to gain new capabilities. To elaborate understanding of different objects of change a Managing Successful Programmes  method might be used. It defines specification-led change, business transformation and societal migration.

This paper is focusing in analysing development from environment and situation point of view. The object of transformation view will be studied in other papers.

Apply development method according to situation and environment

This study is using Dave Snowden’s (2003) Cynefin  method to describe four different environments or situations possibly faced by a developer of ICT capabilities. These environments are Known, Knowable, Complex and Chaotic. Each environment calls for different development approach as illustrated in Figure 2.

Figure 2: Using different development approaches adjusted to each environment and situation

In known situation environment is unchanging. Information requirements may be stated unambiguously and comprehensively since they are very stable and recognisable. The risk management wants complete and precise descriptions of new capability. Formal, specification-driven development methods would provide them with whole documentation.

In knowable situation environment might be turbulent. Organisation may be in constant change thus needs are also changing.  Linear, requirement based, development might be too slow to cope with changes. Development needs to be faster, delivering smaller parts or reusing existing parts of capability.

In complex situation environment is uncertain. Needs for the capability are unknown or uncertain.  Requirements cannot be accurately defined since situation is new or system is innovative. The development must emphasise learning. One version of Spiral development has learning phase after each delivery.

In chaotic situation environment is adaptive and unknown. Environment may change in reaction to the introduced change. In developing capabilities for this environment adaptation is the key. Development method must enable a straightforward introduction of new rules as in experimental process models using prototyping and rapid development. Development process should be able to record the reaction created and adapt to situations as they unfold.

The following chapters are explaining the development case in each of these four environments. These development methods are as follows:

SITUATION	DEVELOPMENT METHOD
Known - unchanging	Waterfall, System Development Life Cycle
Knowable – turbulent	Incremental development
Complex - uncertain	Spiral development
Chaotic – adaptive and unknown	Exploratory development

ICT capability development in known and unchanging environment

In known environment cause and effect relations are repeatable, perceivable and predictable. Business processes are following “best” practices and cemented in standard operating procedures. Developer is able to gather all needed information of user requirements, their competence, relations to environment and other components. The pace of change in this environment is slow.

Models for development

All variations of the classic ‘Waterfall’ Development  model may be used successfully in this environment. One example for the steps of waterfall development approach is:

1. System Conceptualisation includes consideration of all aspects of the targeted business function or process. It calls for discovering how each of those aspects relates with one another and setting goals accordingly. The intended capability should be analysed within its coming environment to define interrelationships. There should also be resolution of which aspects should be incorporated into the development and which remain untouched. 
2. Systems Analysis includes gathering of system requirements. Each requirement needs to be studied and determined how it will be accommodated in the system.  Analysis is not possible without intensive communication between the customer and the developer.
3. System Design includes identifying in detail how the system will be built to perform necessary tasks. Designing is a process where data requirements, software construction and interface construction are planned together as a balanced design to fulfil the model created in steps one and two. 
4. Implementation or Coding in software development is creation of the system software. The System Design is translated into machine readable computer code. 
5. Verification or Testing is performed to ensure that developed application is working correctly and efficiently. Testing is to validate both internal efficiency and external effectiveness. Testing the external effectiveness is to corroborate the software is functioning according to system design and that all necessary roles or sub-functions are performing.  Internal testing assures the computer code is efficient, standardised, and well documented.
6. Maintenance occurs after the developed feature has been installed in live environment as one or more configuration item. It means continuous evaluating of running systems. It means providing services for example with ITIL processes , where configuration management, problem management, release management and performance management have effect on single configuration item. Besides continuous improvement there may be a need to have mid-live updates within extended life cycle of the system. 

One variation of waterfall development model is depicted in figure 3.

Figure 3: Waterfall development model with documentation and validation emphasis by V-variant

Improved variations of this linear and specifications driven development method are:

• V-model where testing is emphasised and added into each level of delivery as depictured in figure 3. 
• In the System Development Life Cycle, SDLC operations, maintenance and finally disposal of delivered system is bound into holistic life cycle approach. Open SDLC group  is preserving and improving Systems Engineering and Software Development Life Cycle Framework.
• Systems and software engineering – Software life cycle processes standard preserved as IEEE/ISO/IEC 12207:2008 includes supporting life cycle and organisational processes. 
• Systems engineering standard ISO/IEC 15288:2008 is including some programme and portfolio management features into development intent. This is the most generic model to build systems that include “hardware, software, data, humans, processes (e.g. processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities” .

Waterfall approach has high level of success if utilised in producing complex systems on known design or replacing technology. It is less successful when delivering new technology to organisation. Least success is predicted when method is used in changing organisations or in implementation of unproven technology.

Examples

The Finnish Defence Forces, FINDEF was renewing transport network during 2004-2006  mainly following the waterfall development model. It was feasible since there were no big changes in network topology and the change remained mainly at technical level. Requirements were gathered from each Services  and merged with constraints of finance and military environment. Analysis of needed topology and number of nodes provided simple design that was straightforward to acquire from minimum three vendors by comparison of cost.  The telecommunications organisation of FINDEF installed the MPLS  nodes themselves, updated fibre optical connections and integrated new network to system management. Project did deliver required capability almost 2 years ahead of deadline  but failed to recognise the following issues:

• As circuit switched SDH  network layer was replaced with packet switched MPLS network the Quality of Service, routing and performance would have provided unforeseen applications. Project did not recognise these opportunities but only carried out a Mid-Life Update.
• As Information Technology at upper layers were changed parallel, network project failed to capture their emerging needs.
• As network service transformed to be more than dedicated point-to-point circuits of 2 Mbps multiples, the network node management system provided by project was not able to managing these new end-to-end services.

The Enterprise Resource Management system (SAP)  implemented in the Finnish Defence Forces during 2003 – 2008 was following typical SDLC model. Process owner initiated the programme (MAHATA) with business improvement as a goal. Concept was defined as incremental consolidation of Enterprise Resource Management, ERM functions. Plan was created with programme and project organisations aiming to replace all legacy systems. Requirement analyses was straightforward since existing processes were planned to be replaced with SAP functions. SAP integrator was chosen to take care of design, development, integration, testing and implementation.  Same vendor was also assigned to provide both process and technical level support in operation phase. System delivery was achieved as planned but other issues occurred during the implementation:

• Since the culture of Defence Forces was not supporting process driven approach, SAP did not provide original business benefits since programme did not change the culture of administration. 
• SAP was implemented to consolidate all administrative functions and information. Programme was not integrating operative management and administration functions together as in normal ERM development. This left Defence Forces with a handicap.  

Development in knowable but possibly turbulent environment

In knowable but turbulent environment the relationship between cause and effect needs analysis to become understandable. The analysed cause may still be changed during development with pace that normal development project management faces difficulties to match. Development should follow shorter iterations of delivery, which allow Sense - Analyse - Respond process in presenting new capabilities.

Model for development

Development models fitting in knowable environment are iterative, prototyping or rapid. The Iterative Development model delivers new capability in small parts. This allows partial results to be displayed earlier on within live environment and earn feedback from users. Each iteration might be managed as mini-Waterfall project and feedback loop is linked to future phases of analysis, design or implementation. Iterative development needs users to be involved actively in process. Requirement management is needed throughout the delivery. Attention needs to be paid to control possible creep of the scope. Figure 4 is illustrating this development model.

Figure 4: Iterative Development model

The iterative development approach may be further extended with continuous integration approach that is coming from software development called extreme programming.  Continuous integration means that developed iterations are integrated and tested together within main system several times before launching them in operation. Using continuous integration to develop large System of systems helps to manage turbulence caused by vast number interrelationships within System. 

Example

The Finnish Defence Forces was implementing an Information Technology Service Management (ITSM) system following good practice of the ITIL/ISO/IEC 20 000:2007 standard 2006 – 2008 as it was changing also the organisation for providing ICT services.  An incremental development of ITSM capability was chosen as organisation was transforming and maturity of different processes was diverse. The FINDEF was implementing ITIL and defining Configuration Management Database (CMDB) within one of the first organisations in Finland, which increased the likelihood for extra turbulence. Iterations were mainly as follows:

• Delivery 1: Transforming event management and change management from TMN  model to ITIL using existing management systems
• Delivery 2: Implementation of ICT service production processes with Enterprise Resource Management processes
• Delivery 3: Changing end-users processes and application.

Outcome was positive as system and processes were completed but the following lessons were identified: 

• Process and tool training should be integrated otherwise trainees may not understand the context of the capability
• Usability of application is imperative when trying to change the behaviour of over 14 000 people
• Risk management is important even in incremental approach. Now both human behaviour, training and performance provided unforeseen challenges.

Development in complex environment

In complex and uncertain environment the relationship between cause and effect can only be perceived in retrospect. Training focused approach with Probe - Sense – Respond method should be applied when establishing development programme.

Development methods fitting in complex situation are more evolutionary in nature as the models of experimental and spiral development. 

Models for development

Spiral Development  model differs from other models in being more risk-driven than document-driven or code-driven. A new capability is developed in spiralling rounds which each create a prototype in achieving to balance better the interrelationship of requirements, solutions, risks and costs. A typical round of development spiral runs as described in figure 5:

1. Identification of objectives (performance, functionality), alternative means of achieving objectives (Design, Reuse, Buy) and constraints imposed on the application of the alternatives (Cost, Schedule, Interfaces).
2. Evaluate alternatives relative to the objectives and constraints. Find out the areas of uncertainty. 
3. Formulation of cost-effective strategy for resolving the sources of risks with means as prototyping, simulation, benchmarking, reference checking or analytical modelling.
4. Develop a prototype driven by risk management. Try to mitigate the sources of biggest risks first. Create a concept for future prototypes matching the assumed sources of risks sequentially.
5. Test and field the developed iteration to gather feedback both from users, service providers and business owners
6. Review products, plans and resources in accomplished round. Define and improve further measures to mitigate sources of risk in development.

Figure 5: Spiral development rounds as described by Barry Boehm 1988 

Spiral development is managed like a scientific research process: 

• Create a hypothesis that operational capability can be achieved by system development
• Carry out a series of tests defined by risk structure. If hypothesis fails the test, then spiral should be abandoned.
• Usually each test creates more information and possible new hypothesis that requires to be tested.

Experimental Development model includes the acquiring, combining, shaping and using of existing scientific, technological, business and other relevant knowledge. It uses the skills for producing plans, arrangements or designs for new, altered or improved capabilities.  Experimental approach means: 

• active user involvement throughout development process; 
• prototyping experiments closely coupled to work-situations and use-scenarios;
• transforming results from early cooperative analysis and design to targeted object-oriented design, specification, and realisation;
• designing for tailorability. 

Example

Transferable Operations Centre (TOC) was developed in FINDEF during 2000-2003.  TOC programme was to build a prototype for new joint operational level command and control concept for Finnish Defence Forces. Since situation was analysed to be complex and unprecedented, Barry Boehm’s spiral development was selected as main development model. Risk driven approach was applied as depicted in figure 6 as follows:  

• Since tradition for having fixed command posts was identified as biggest source of opposition, transferability was chosen the first feature to be achieved. Late 2001 a transferable command post using cloud computing applications as service was prototyped.
• Second source of opposition was analysed coming from request of physical presence in staff working. This was achieved by 2002 when one command post was distributed to three places following shifts of 8 hours. It was proved that physical distance do not hinder staff work in planning, situation briefings and decision making.
• Having several levels of confidentiality accessed through same network and terminal was estimated to be third biggest source for opposition. A technical solution to use unrestricted, restricted and secret content in same session was presented. Vulnerability analysis proofed that risk for security breach was within risk appetite of Operational Security.
• Fourth source of opposition was assumed to come from staff processes. A Service Oriented Architecture was applied to implement operational planning and execution processes. It was proven that process driven approach to staff work is more productive but requires change in entire operational thinking and staff behaviour.

The TOC demonstration programme achieved its goals by 2013 but when doctrine and concept was implemented to whole Defence Forces in Integrated C4ISR  programme (ITVJ) it confronted the following challenges: 

• Tradition of physical presence in staff work delayed effectively the distribution of any command post until it was achieved with persistent effort by 2012
• Defined best practices in operational planning and execution processes failed mainly since culture was not ready to standardise any other staff work but templates for orders.
• The pace of technical evolution outdated some solutions and same time presented number of opportunities that technical people were having challenges in keeping ICT stack together.

Figure 6: Transferable Operation Centre development rounds  

Development in chaotic and adaptive environment

In chaotic, adaptive and unknown environment there is no relationship between cause and effect. Act-Sense-Respond approach is needed to penetrate the Fog in this area of operation and overcome the unseen Friction in execution.  In developing capabilities for this environment, adaptation is the key. Development method must enable a straightforward introduction of new rules as in exploratory Development process models using for example prototyping and rapid development methods.

Models for development

An elaboration to experimental model is Exploratory Development model , which runs as follows: 

1. All the information available is gathered together in an attempt to get an idea of what the new capability is expected to do, and how it can be done.
2. A rudimentary first-generation solution is put together. It is based on best assumption but no way specified final requirements.
3. The first-generation solution is fielded to see how it performs, what it can and cannot do, and what might be done to improve it.
4. A second-generation system is developed based on lessons from first generation and information gathered from first users.
5. The second-generation solution is fielded to replace the first. Its performance is evaluated, and possible needed improvements determined.
6. The process is repeated as many times as necessary to obtain user satisfaction, or until it is decided that the project is unworkable.
7. Routine maintenance is established to prevent large-scale failures and to minimize downtime.

There are no precise specifications defined with the Exploratory Development.  Validation is based on adequacy of the end benefits and not on its compliance to pre-defined requirements.

Each generation of capability may be developed by creating a series of working models before any real system development occurs. Each prototype , is a working model or intermediate version as defined in figure 7 that is not nearly complete but works in production environment mainly as intended even if only on temporary bases.  The user in turn provides feedback to the developer, who amends the system requirements and proceeds to implement the actual function. There is a possibility that user expectations may overextend with prototyping or pressure for rapid delivery may drive development into poor design and unnecessarily layered or patched construction.

Figure 7: Concept for exploratory development 

In Rapid Application Development model  the components are developed in parallel as if they were mini projects. The components are time boxed, delivered and then assembled into a working prototype.  The working prototype can quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements. This model of development is applicable when delivery time is less than 5 months and there are number of developers available.

Example

Unknown environment was faced when improving battle management capability for the Finnish Land Forces.  There was no feasible means to capture requirements since there was but different opinions of end state. An exploratory development model was chosen to probe the maturity of land forces culture and search for opportunities of approach. Since earlier attempts to automate land forces command and control were mainly failed there was additional opposition to computers in battle field. 

To mitigate risks and exploit all unfolding opportunities the exploratory method was applied as follows:

• An end-to-end blue force tracking feature was introduced in existing battle management system and it was extended from HQ of Land Forces down to companies. As first field exercises started to show positive feedback it become clear that this feature was needed. But not in all areas of operation since early adaptation in Finnish ISAF task force it was not welcomed. These bad experiences delayed BMS implementation in international operations for 3 years.
• Second probe of capability was done when land forces blue force tracking was integrated with police, civil defence and medical support blue force information for Civil-Military operations for home land defence area of operations. As land forces battle management system and other agencies field management system were integrated, it provided clear benefit to all complex home land operations from police lead searching operation to life fire exercises of Defence Forces. 
• Third probe was done by extending legacy BMS to platoon and group level. This started the change of operational procedures in battle technical level. Gradually swarming tactics was applied and the opportunity to develop new land forces fighting doctrine was appearing more promising. 
• Fourth probe was to introduce full 4th generation battle management system for international operations. This time driver for implementation was coming from other forces implementing similar capabilities as earlier experiments were keeping some officers doubtful. First BMS was introduced in exercises and training for operations. Gradually capability was rotated to actual peace keeping operations. With effort on usability it was welcomed especially by reservists who formed the main body of troops. This drove also enlisted soldiers to adapt new methods of planning, commanding and controlling peace keeping and enforcing operations.  
• Fifth generation battle management system was developed using rapid application development model parallel to these earlier prototypes. In development all lessons from other lines of operation were carefully studied and risks were mitigated.  

An example to manage overall development of military ICT enabled capabilities

As Military Forces become more digitalized the complexity of C4ISTAR System of systems will increase but military functions become simpler since added information will take away some friction and fog from battlefield. The challenge to gain and sustain asymmetric advantage over potential adversaries becomes harder. Forces need to be more flexible  in operation than any time before. This calls for quick learning and adapting both when building forces and in operating them in surprising situations. There is a demand for hybrid model to improve one’s ICT enabled capabilities. Figure 8 illustrates one possible structure  to have agility in development but still maintain control over the whole life-cycle of System of systems.

Figure 8: An example to manage more agile development of ICT enabled military capabilities

The strategic portfolio is divided into three areas of development :

• Keiretsu or LEAN development in Operations of ICT Service Production

• Kaikaku or discrete development of ICT enabled capabilities

• Recognising concepts and opportunities for longer term development.

Continuous or keiretsu improvement loop is taking place in ICT service production being mostly end-user requirement driven. Management may follow LEAN, Six Sigma or Deming loop within ITIL service management family of processes. Improvement pace may vary between once a year to daily delivery. Development process starts “Alpha” version testing in ICT reference environment. If passed increment is migrated to Pilot environment for “Beta” testing. After full assurance of integration increment is migrated to production environment.

Kaikaku development may use any fitting development model to deliver capability parts per situation or environment. One development program is needed to manage all developed changes. There might be several parallel projects and programs ongoing utilizing different development models, but they all will deliver their capability parts via Service Production Change management. Simple management of creating new capabilities may follow Define-Design-Build process.

Strategic level sense making includes recognizing new opportunities, modelling them and war gaming in simulated environment where adversaries, neutral, own forces and their systems interact. There should also be several different experimenting sessions to test the practicality of new opportunities.

This concludes the analysis of environment and situation where development is taken place. Analysis was done by using Cynefin method in explaining different situations. Each situation was faced with some existing development method and further explained with examples from the Finnish Defence Forces. Finally an overall developing management framework was introduced to control different development approaches, situations and goals.