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.

C4I service and management of its level in military chain of value

This paper defines a basic relation between service provider and client in environment of closed market. Paper also provides guidelines to Service Level Management in military chain of value. Principles of Service are illuminated with examples from the Defence Forces of Finland.

Closed market needs special drivers since money does not talk that loud

A market may be closed or open. Open market is typical for private sector where providers are competing and clients may freely choose what service and provider they use to create more value. Money is changed when value is created. Closed market is typical public sector, where one service provider adds value to clients that lack freedom of choice. There is seldom money changed for value but costs may be projected in the accounts of closed markets units by the end of year. Closed market needs artificial drivers to function efficiently. These drivers may be called Management of Service Agreements as described in Figure 1.

Figure 1: Drivers of closed market in Military Organisation

Client is a military force or unit with mission. It requires the support of a Service Provider, which is not under clients command structure. The Service Provider may utilize several sub service providers either within closed market or from open market. Together with client service provider and its sub providers create a value chain. Customer is responsible of managing the closed market. In military organization it is normally the highest Commander and his supporting Headquarters. 

The commander is issuing a mission to Force and support objectives to Service Provider. In order to build efficient relationship between client and provider, there is a need to establish Service Catalogue and Service Level Agreement. The Command Intent (=Strategy) needs to be communicated to all parties of the value chain. 


The following chapters will study some basic features of closed market and give examples of their failures.

Service is not what provider offers but what client values

Service is something that Client values and Service Provider produces. If there is no feedback to service provider, service does not get improved. Further Client’s feeling of value decreases since service becomes granted. Service is created mostly by the Value Chain as complex services are made up from sub services. There is a challenge to manage the value chain and project the client’s appreciation of value all the way through chain.

Service flows along value chain and its quality, level or value should be measurable in conjunction points. In open markets the value of service is measured against monetary value. In closed markets there needs to be other means to measure the value and provide drive through the chain. If there is no free choice for client to get more value by changing provider or service, a Service Level Management authority should be in place. Authority is needed to create favourable conditions to improve service provider – client relations, to create feeling of value in each conjunction and, in the end, to produce business benefits. A basic service relationship and value chain is described in Figure 2.

Figure 2: Basic relationships of value creating chain

Sometimes it is difficult for military organisations to understand value chains if they are recognising only traditional command chains. It these cases it is sometimes fruitful to recall how field artillery functions. The fire controller (=Client) is causing losses to enemy troops by using services (= fire) provided by artillery battalion (=Service Provider). Requirement for service equals fire command. Report of service quality equals correction orders of fire. The plan for combined fires that aligns both units and the supporting artillery battalions equals Service Level Agreement.


Service with no value to client
The Electronic Workshop of Finnish Defence Forces was ahead of time in implementing quality management and defining its services back 1990’s. Electronic maintenance services were defined according to best industrial practices but the clients of Workshop were at different level of maturity. Clients took services as granted since there was no feeling of value in transaction. The superiors preferred line command over governance of closed market. Whole intent dried up as there were no maturity in the whole value chain, just one provider trying to change alone.

Only added value is recognised as service
The C4I Centre of Finnish Defence Forces was built incrementally and Service Catalogue matured step by step through 2005 – 2008. The Services of C4I Centre was estimated to be at Service Production maturity level 4 (= business benefit). Then the focus of management shifted. The mature Service Catalogue was changed by the engineers of C4I Centre. Within one round ICT service descriptions, terms and conditions were reversed to maturity level 1 (= devices). With only a small change in the governance of closed markets and the interest of clients was missed as services lost appearance of value.

Service Level Agreement is not just a paper

Service Level Agreement (SLA) is an agreed way between provider and client to deliver valued services to create business benefits to client. There are some key issues in service level agreements like: lines of demarcation, regular communication, persistent improvement, enforcement and linkage to business value. 

Agreement is to create base of trust between provider and client. There should be clear roles of responsibility and procedures to follow when incidents occur. Contract should mitigate the effect of possible political and personal conflicts in problem identification and resolution. If contract does not serve the purpose of trust, it becomes only a part of bureaucratic margin.

Agreement will wither if there are no regular meetings to foster communication between parties. It does not need any problems or great new ideas to have a meeting. Meeting is main tool to extend and exchange the understanding of the business between both parties. Meetings should improve the insight of business through the whole chain of value creation. All parties of chain are learning by fusing tacit knowledge and creating new mind models. This creates new insights whether tacit or explicit.

Longer the service is creating value, more important is to tune and improve it to meet the evolving expectations of client. Constant feedback to service provider is an enabler for service improvement. Service Provider should listen their clients and take action based on feedback. There is no hierarchical line command that can replace the direct feedback from client and a lean development of services.

Client is dependent on services of the designated provider in closed markets. There should be a sanction in place if provider fails to meet agreed levels of service. Client’s loss of value due service defect should be projected to the outcome of service provider. 

The main driver for entire value chain should be the business value or benefit of client. If client’s organisation is not aware of this value chain, there is a tendency to take service as granted. If client does not value service or see its benefit to business, service should be cancelled. The integrity and understanding of value chain is compulsory for lean improvement through the whole chain of value creation.

Service promise without delivery
The CIS Agency of Finnish Defence Forces was created 1997 to develop ICT products and provide them to regional ICT service providers. It took two years to stabilise service agreement process between centralised developer and regional operators. The SLA was taken as the main driver for whole CIS Agency. Then the management of CIS Agency changed, and within a year, the trust and policy between parties was gone. Management turned to listen more the hierarchical line command and development units failed to deliver what they had promised in SLA. There is no trust from clients if service provider does not take agreement as binding contract.

Responsibility without transparency and sanctions
After setting up measured, reported and sanctioned Service Level Agreement between Joint Service Provider and all forces, the J6 of Finnish Defence Forces changed their focus. The J6 neglected to require timely reports based on transactions direct from client-provider contact. Reporting was downgraded to traditional line of command procedure. Since the levels of hierarchy through reporting line exceeded four, the facts were lost in process. The culture of Service Provider did reverse to previous behaviour. The unfocused J6 was getting general reports from the line of Service Provider. These reports were countered with feelings based feedback from clients. One opinion was arguing against another opinion based on everything else but facts. The dearly gained trust was lost in friction caused by miscommunication and lack of transparent information.

Is there real client driven approach without sanctions in SLA?
The J6 of Finnish Defence Forces fixed a controlled relationship between provider and client and sealed it with sanctions in the SLA template. Sanction chapter did effect the performance measures of unit and personal levels. After the first full year all measures were collected and time for personal performance assessment came. The metrics evidenced intermediate success at most, since service levels were not met according to goals set by the J6. The first attempt to build direct cause between actions of client, service and provider failed because of loud opposition from managers and evading support from Human Resources Management. Transformation of culture did not happen since communication was not delivering clear understanding of new responsibilities and measures of success.

 

Service agreement is nothing without the Service Agreements Management

In closed market it is important to have Service Agreements Management process in place to compensate the lack of the choice of open market. There is a process of managing service agreements described in COBIT5 framework . It includes five steps: 1. Service Identification, 2. Service catalogue, 3. Service Level Agreement preparing, 4. Monitoring and reporting and 5. Reviewing. Process is showed in Figure 3.

Figure 3: Service Agreement Management

The client’s business requirements needs to be analysed and ways to add value to core business needs to be identified. Client is responsible to identify possible new services that may create value. Service provider is accountable to find and propose new possibilities to clients. Together they could experiment and test the opportunities in finding most valuable combination. Service Provider collects requirements and describes possible new services to Chief Information Officer (CIO) of Enterprise.

In closed market CIO own a process that define, maintain and publish Service Catalogues for relevant client groups. Service agreement is defined and prepared on base of the options in service catalogue. Agreement process is established by Enterprise level CIO. Responsibility of agreeing falls into the business manager of client and the chief of operation officer (COO) of provider. The CIO of client and service manager of Provider are accountable for executing this agreement.

Monitoring and reporting the level of services provides important feedback to all parties of closed market, since there is no natural financial driver present. Providers service manager together with clients CIO are accountable to create service reports. The responsibility to review, analyse and adjust accordingly the relationship falls to business process owners and COO of the provider.

Reviewing service agreements and contracts also helps to keep them aligned with business operation and strategic goals. When business or its environment changes, agreements should not hinder the change in otherwise flexible chain of value. Responsibility falls to enterprise CIO and his staff, where as both clients CIO’s and service provider’s management are accountable of this process. SLA templates should be reviewed as a part of annual business planning process.

Misunderstanding of service level agreement
A Chief of Staff of one unit in Finnish Defence Forces did not understand the nature of the SLA template offered to him. With support of his CIO he came up requiring further tailoring the agreement to meet his personal preferences. He was questioning the standardized services and their terms and conditions. The Service Provider forwarded these reclamations to the J6. After studying the case, the J6 communicated to the unit of higher strategy of Defence Forces. The strategy required standard services for two reasons: 1. to achieve interoperability between units and 2. to have more available services in crises time. The unit understood that the need of whole Defence Force was more important than their own peace time optimized requirements.

Losing the control of closed ICT market
The J6 of Finnish Defence Forces lost their focus in managing closed ICT market. They made a mistake in delegating the Enterprise ICT Service Catalogue responsibility to the Joint Service Provider. Without link to strategy ICT Services started to evolve towards to the preferences of Service Provider. Clients were put in a position where they had mission to implement strategy but Joint Service Provider did not support them with appropriate ICT services. It did not take long from clients to implement their own service production to bypass the short comings of the designed Joint Service Provider.

Study your Command and Control system and culture before implementing it to Information System.

"We are what we repeatedly do." 

Aristotle

"We never had time to do anything properly. 

Consequently, we always had to find time to do it twice."

Marcus Aurelius

"The key success in the twenty-first century is the management of knowledge and expertise." 

Peter Drucker

"In an economy where the only certainty is uncertainty, the one sure source of lasting competetive advantage is knowledge."

Nonaka & Takeuchi

"The most dangerous phrase in the language is 

' we've always done it this way '."

Rear Admiral Grace Hopper

“I still learn something new every day. 

Education and knowledge are the reason behind progress of man, his happiness and stability. 

The path of education and knowledge is the key to building a nation 

that achieves progress in all walks of life”.

His Higness Shaikh Mohammad Bin Rashid Al Maktoum

1. Knowledge Management approach opens better opportunities to improve military C2 capability than basic acceleration with information system

A military combat operations command and control (C2) process called OODA-loop (Observation – Orientation – Decision – Action) defined by John Boyd (1987) has been choosen often for a model of military process to be improved by information services. The approach for U.S. Armed Forces (Joint Pub 3-13) in improving C2 capability is to run OODA loop faster than adversary to achieve and maintain advantage in battlefield i.e. Information Superiority. This is usually enabled by information systems.

This paper is studying OODA loop under the framework of knowing organisation defined by Chun Wei Choo (1998) and emphases knowledge management is more important than mere information technology in gaining better C2 capabilities. There are three capabilities in the OODA-loop from the point of knowledge management:

1. Sense making, consisting of observation (sensing) and orientation (making sense), is interpreting the equivocal data by enacting interpretations. Sensemaker is required to recognize the area of awaress one is approaching. There are four distinctively different sense making models when approaching situations that are: Known, Knowable, Complex or Chaos.
2. Decision making is searching and selecting alternatives according to projected outcomes and preferences. There is a major difference how decision making is implemented in military organization that defines the capability of decision making.
3. Knowledge acquisition is creating new knowledge and improving the whole OODA loop through knowledge conversion and sharing of information. There is a huge improvement in ability of creating new knowledge when one evolves from behavioural oriented learning towards more constructive and social ways of learning in military organization.

These three components of C2 capablities are described in figure 1.

Figure 1: Orientation for military knowledge management from sense making, decision making and knowledge acquisition approach

Three following chapters are describing the three areas of OODA loop improvement by illustrating their evolution in military organizations using road map approach. Map visualises the main evolutionary path but also some short cuts and downshifts that has occurred on the way.  

2. Description of evolutionary paths in Military Sense making 

This chapter is concentrating on how observing (sensing) and orientation (sense making) of Boyd’s OODA loop is executed. Sensing needs to overcome the fog of battlefield and egocentricity of human sensing. Sense making needs to address the attempts of deception by adversary, biases of sense making teams and individual mental models

When sense making situations is modelled with Cynefin framework by Kurtz and Snowden (2003), four different models of approach can be defined: 1. Known, 2. Knowable, 3. Complex and 4. Chaos as described in figure 2. Sensing and Sense making is following different process in each of these situations, thus implementing of only one in information system will result constrained and predictable capability.

Figure 2: Road map for military sensing and sense making from OODA approach

The four different sense making situations are described in following subchapters.

2.1 Sense – Categorise – Respond in known environment

In known environment cause and effect relations are repeatable, thus easily perceived and predicable. In this situation military is following their Standard Operational Procedures, SOP.

Both individual, team and organisation are observing an event. Event is being categorised with previously defined model like the assumed order of battle of adversary. Each category has a predetermined type of respond, which is being followed without orientation or decision making. A good example of this is firing based on predetermined targeting list.

It is not often that adversary is behaving by the book. Even more harmful is when surveillance and reconnaissance systems are preprogrammed with these standard patterns and fail to detect anything divertive.

This approach is realistic for the lower levels of conscript army, where time to train ISTAR capabilities is very short. It is erroneously followed in forces that believe in Information Superiority. It is also followed in Armed Forces with access to resources overwhelming adversary’s.

2.2 Sense – Analyse – Decide – Act in knowable environment

In knowable environment cause and effect are separated over time and space. It requires some scenario playing and systems thinking to create a possible model to describe the knowable environment. 

After detection the incoming data needs to be analysed to reveal all effective cause-effect relationships. Sense making is evolving the scenarios as new data is detected.  There is a need to create a bigger picture from smaller events and their recognise their interrelationships by systems thinking. 

Current trends of Big Data and Business Intelligence are good example of organisation trying to utilise all information it possesses. By fusing and correlating data differently, organisation may create new knowledge and if succeeding in sharing it, may gain a competitive advantage.

2.3 Probe - Sense – Analyse – Decide – Act in complex environment

In complex environment cause and effect are only coherent in retrospect and similar events seldom repeat. Emergent patterns can be perceived but not predicted. 

It requires a initiative probe to make possible patterns more visible for observation. Understanding these emergent, new patterns needs multiple perspectives to be involved in sense making. It needs to create narratives as base for understanding as they are simple and easy to communicate between team.

This is the very base of military professional approach in sense making since situation almost always is at least complex in military environment. Interestingly this has been defined already by Miyamoto Musashi, Samurai and Ronin from early 1700 century Japan.

2.4 Act - Sense – Analyse – Decide in chaotic environment

No cause and effect relationships perceivable in chaotic environment. System is turbulent and there is no time to wait patterns to emerge. One might assume there is a potential pattern but it is not visible or reconstruction able.

It requires a quick and decisive intervention to reduce the turbulence and ability to sense immediately the reaction to the intervention. This deliberate action might create something that is either known or knowable and with effective observing and analysing it might make sense.

Fast and determined action was the main German staff officers approach and key enabler against Allied officers that tried to approach situations as knowable.

2.5 Leaps, downshifts and revolutionary paths on sense making map of possible roads

Especially in crises situation and under extreme stress, the sense making capability may collapse and only behavioural routines will sustain. Thus there should be exercised process before utilizing more agile methods in sense making.

Sometimes the feeling of having information superiority may cause a downshift, when complex situation is addressed as knowable and collecting more data is believed to provide the eventual clarity. This might have been the case in late ISAF operation, where the amount of collected data reached 40 Exabyte (10^18) in a month.

Requirements for near real-time recognised operational picture to provide targeting information for target acquisition process may constrain the time and method used for fusion and recognition. Thus targeting may fall short at basic event categorising and both friendly fire and collateral damage may occur.

3. Description of evolutionary path for Military Decision Making 

Decision is a function of residual uncertainty and the risks associated with the available options as a function of time. More naturalistic methods for human decisions are seeking first behaviour in similar conditions, then human goes for most familiar. If none of the mentioned is applicable, human is trying to minimize undesirable outcomes and maximize his own utility. Thus human being is easily manipulated in stressful situations.

Figure 3: A Road map of Military decision making from Knowledge Management view

3.1 Authoritarian decision making in classical command and control

Decisions are made at top, Commander-centric, orders are flowing down and reporting heads upwards by support of hierarchical knowledge management. 

Information flow is following line organisation to enable superiors to understand better situation than their subordinates. Situational information and orders flowing back down are delayed by levels of hierarchy and means of communications. Information is shared “need to know basis only”.

Carrying out tasks is based on pretrained procedures and there is no need to change behaviour during operation. Knowledge base is following the doctrine and managing issues following standard operational processes.

3.2 Shared strategic intention with synchronised operational execution

Unlike his adversaries Napoleon could delegate operational decision making to his generals, who were heading Army Corps, bataillon carré. Napoleon shared his battle intent with his commanders and gave them some degree of freedom in execution. This enabled to achieve timely numerical strength, deep strategic penetration and rapid concentration of force superior to adversaries. 

Ability to share strategic information by actively collaborating between Corps heads provides good strategic and operational level awareness, alignment and manoeuvrability even if the lower levels in organisation are rigidly following orders and informing superiors through line.

3.3 Mission command

In mission command tactical freedom is delegated to combined arms force level by giving mission to forces including commanders intent of battle. Forces were expected to fulfil the mission in most suitable way adjusting their tactics as situation was unfolding before the eyes of their commanders. 

Higher command was controlling execution by defining end states rather than tasking detailed goals. 

Mission command requires continual dialogue with higher authorities and mission partners to better understand the changing environment and perspectives. Collaboration helps in perceiving what shared awareness looks like. 

3.4 Mission command with peer level collaboration

New level of awareness enabled by force digitalisation has flattened military hierarchical organisations because middle level commands are not needed for control and quick reaction. Peer level collaboration lacks strick command relationships and is based more on trust.

Although the recognised operational picture is presenting the current situation to everyone interested, building and maintaining the trust requires continuous dialogue between stakeholders. It will consume time differently but shared understanding enables empowerment, cross-domain synergy and eventually improves effectiveness compared more line or functional approach. 

3.5 Self-synchronising with swarming tactics

Power to the Edge (Alberts&Hayes 2003) principle addresses the shift in relationships required to leverage shared awareness to foster self-synchronisation and achieve major improvements in mission effectiveness. Control is sustained with shared command intent and consciousness instead of tight line control.

Swarming is a way to manoeuvre forces to gain advantage in time and space. It enables asymmetric tactics with agility, focus and convergence.

Gen McChrystal was able to improve his Special Operations Task Force capabilities about 30 fold in Iraq Operation 2006 when he implemented the vision: “If we’re going to win, we need to become a network”. He transformed task force from hierarchical command and control structure to the network of a swarming force. 

3.6 Leaps, downshifts and revolutionary paths on decision making map of possible roads

Attrition with dominant resources has been keeping the command culture centralised and emphasised linear planning and management more than leadership.

Improved communications and ability to gather up-to-date information from battle is not necessarily leading to mission command or more loosely controlled battle management. The hunger for information at the top may produce an information overload resulting even longer lead times to prepare and launch operation. 

It is far easier to return to more centralised command culture when returning to peacetime garrison, tight fiscal constraints, and increased competition for promotion. With the low number of events happening during peacetime it is also tempting to higher headquarters to centralize the control of myriad of more detailed peacetime management events. 

4. Description of evolutionary paths in Military Knowledge acquisition and Learning 

Military training has to prepare individuals and collectives to enter into harm's way and perform physically and mentally demanding tasks at the highest possible levels of proficiency. Military training has the tradition to be more like discipline than a process of creating competence. 

In this paper learning is analysed from the knowledge management point of view, emphasising especially organizational knowledge acquisition defined by Chun Wei Choo (1998). Four different approaches to knowledge acquisition, training, education and learning are described in figure 4 opening a different view to evolution in military skills and competence acquisition.

Military skills are learned mainly in team training with progressive challenges tailored to each team of arms. Repetition is a disciplined way to establish team’s behaviour as part of a bigger system. At battle technical level both individuals, troops and weapon systems are trained to be able to act at level of subconscious habit, motoric memory or preset programming. 

Figure 4: Road map for military learning from knowledge management approach

Military understanding has several learning approaches. There is a strong legacy of operating by the doctrine and thinking by the book. There is also increased request of not educating soldiers what to think but how to think. This means introducing a combination of three thinking methods: systems thinking, creative thinking and critical thinking. 

4.1 Drilling what to do and think with behavioural drivers

Drilling has been a tool for military training as documented vividly in Sun Tzu’s Art of War or in Prussian army when soldier was made a standardised, predictable and reliable unit to operate the musket. This is the very basic way of socialising tacit skills when instructor (master) shows how to do movement to soldiers (apprentices) and then drills it continuously supervising proceedings and correcting mistakes. 

In behaviourism learner gets positive feedback when his behaviour and learning results are moving in right direction. This is especially effective, when standard of required performance is gradually increased and award from right behaviour is direct and public. 

4.2 Understanding how to think with cognitive drivers

General James Gartwright (2008) called after learning how to think and improving the pace of learning to meet current speed of evolution of business (3 months), technology (18 months) and war fighting (30 days). This requires the ability to create explicit knowledge by bringing together explicit knowledge from a number of sources. Combining different explicit and tacit concepts requires systems thinking, critical thinking and operational analyses.

The cognitive learning follows more the human way of creating understanding and processing information in his brain. New things are learned within a familiar orientation model. Problem solving is using cognitive approach, where one learns a new way of thinking (schema) and is able to utilise this “tool” further in solving for other similar problems. After learning these schemas, there remains a problem of mapping problem to a right pre-existing schema. This requires logical reasoning like systems thinking or operational analyses.

Skills are learned mainly by team training with progressive challenges tailored to each team. Repetition is a discipline as a part of bigger system, but utilisation of skills in different situations and environment is a driver for successful execution in progressively challenging environment. 

Understanding is soldiers’ ability to perceive their space of operation, teams and systems, other combat supporters, supported and adversary as huge system where different parts interact with each other and with environment. It requires leaders to achieve synthesis when processing towards understanding of this phenomena. Leaders should reach a certain level of insight and foresight to be able to innovate and create best ways to deploy and operate one's system as interdependent part of fighting system of systems. 

4.3 Experimenting with constructive drivers

The full knowledge conversion process by Nonaka and Takeuchi (1995) is described in figure 5. Individual shares some experiences of his trials (tacit knowledge) with peers and together they come up (socialization) with hypothesis for causality model of their analysed experience. They publish (externalization) their findings in lessons identified (explicit) board. Someone else faces a challenge, finds these lessons together with few more similar, and fuses (combination) these concepts (explicit) to fit into situation in hand. One learns (internalization) from this successful trial and increases his (tacit) knowledge.

Figure 5: Knowledge conversion process (Nonaka&Takeuchi 1995)

Constructivism means that new information is learned within social and cultural interaction and is understood in relation to prior knowledge, experience and skills. Constructivism is using sociocultural dimension to support learning. Interaction with more capable peers, skilful leaders or cognitive tools do create mental constructions that enables students to recall learned things longer. 

The support is provided according to students’ maturity and it is gradually withdrawn as subjects become more internalized. This is a coach or mentor approach, where instructor is supporting enough to have student over first fears, provides safe environment for student to experiment, fail and learn, and gradually allows student to have more room for independent action.

4.4 Military as knowledge creating organisation driven by social cognitive learning

The competitive edge may be gained from continuous organisational knowledge creation and learning by “start talking and get to work” as Alan Weber (1993) says. Conversations are the way knowledge workers discover what they know, share it with their colleagues and in the process create new knowledge for the organisation.

Knowledge conversion is enforced by social cognitive learning. It means that learner's behaviour changes as a result of observing others' behaviour and its consequences. There are several factors that determine whether observing a model will result behavioural or cognitive change. These factors include the learner's developmental status, the perceived prestige and competence of the model, the consequences received by the model, the relevance of the model's behaviours and consequences to the learner's goals, and the learner's self-efficacy. Self-efficacy refers to the learner's belief in his or her ability to perform according the behaviour.

Machines and men are collaborating, sharing information and creating understanding, learning from past experiences and sustaining the asymmetric capability over the opponent. As military is adapting the continuous knowledge conversion process between people, they also need to include machines in to the loop of continuous learning. 

4.5 Leaps, downshifts and revolutionary paths on knowledge creation map of possible roads

When following the evolutionary road on the map of knowledge creation and training, there are two distinctive leaps: 1. from what to think to how to think and 2. from team learning to organisational learning. 

As described earlier, U.S. Armed Forces have been trying to leap from what to think to how to think for decades, but they have this far downgraded back to behavioural basics because of the gravity of their doctrine, culture and C2 attitude.

Despite of U.S. Armed Forces tradition McChrystal achieved to take his special operations forces from behavioural level directly to organisational learning within couple of years. 

5. Consider what kind of knowledge management to support with information systems and automation

When military command and control is studied from knowledge management view, one recognises major opportunities but also challenges in three areas of C2 capability evolution: Sense making, Decision making and Learning as illustrated in Figure 6.

Figure 6: Evolutionary roads of military knowledge management within OODA-loop

From evolutionary road map of Figure 6 one may conclude that:

• There is a possibility to use these maps of possible roads to create a strategy to improve C2 capability. 
• 1. Define current C2 situation by acknowledging the typical features of each stage of C2. 
• 2. Set goal stage for improved command and control in each subfeature. 
• 3. As gap between current and future capability is thus defined, there is possibility to analyze alternative roads leading from current stage towards future capabilities.
• 4. As these roads are two-way, there is possibility to be aware of tendencies that keeps C2 from improving or reverse back to starting position.
• Most flexible structure of C2 culture is gained if Sense making in complex situations, Decision making delegated within swarming network and Learning as organization is combined. 
• Combining Mission command with Sense making in Chaos situations and learning together made German staff officers way better than their Allied counterparts in II WW.
• U.S. Officers have been struggling in their efforts of improving C2 as their Sense making is heavily fixed with Known approach and Learning is mainly by the Book. Efforts in delegating Decision making have been bouncing back.
• Delegating decision making to swarming level and being able to learn continuously as organization requires different base of trust and openness of communication.
• If one finds his force to be at very first level of sense making, there is probably a need to evolve knowledge, competence and process before it is implemented heavily in information system. Even assuming that one’s own force is known may rise challenges when facing fast changes of order of battle.
• Analysing situation before decision requires more heterogenic team than before to bring in all possible aspects. Effective team work requires building by practice and challengers rather than more information technology. Information technology should be applied first to enable virtual collaboration of adhoc sense making teams.
• Delegating decision making towards mission command requires continual dialogue with higher authorities and mission partners to better understand the changing environment and perspectives and what a shared understanding of right looks like.
• When one reaches towards more agile, focused force that has convergence, there needs to happen a transformation alike McChrystal implemented 2006 in Iraq: McChrystal explains the transformation strategy of Special Operations Task Force in Iraq as follows: “We began as a network of people, then grew into a network of teams, then a network of organizations, and ultimately a network of nations. Throughout, we evaluated the health of our network by how well each node shared a common but ever-evolving understanding of our organization, of our battlefield, of our enemy, and of our strategy to defeat them—what we called ‘shared consciousness and purpose.”
• Repetition and drilling are essential in learning skills that are needed under stress but building competence that bring advantage in crises situation requires trial, error and social reflection.
• There is a tendency in military as in any other organization, which does not face pressure from outside to gain excessive bureaucracy, create narrow functional silos, simplify skills and competence to be easier trained and withhold most freedom of initiative from lower levels. Command and control culture of this kind does not necessarily survive in complex crises situations. Especially if information systems are constraining the change to more flexible culture.
• One should not expect that C2 strategies are linear, but always approach military C2 system of systems as a complex structure that is constantly in motion.