Developing Tactical Communications for Renewed Land Fighting

1. Introduction

This paper describes shortly, how land forces tactical communication systems were developed between 2006 – 2012 in Finland in order to support land forces renewed fighting. The approach is to introduce lessons especially from program and risk management point of view as perceived by author. This is a story of traditional attempts, normal failures and gradually improved risk management, which aligned with DOTMLPFII development enabled major improvement steps in force integration and fighting capabilities. Study is based on writer’s personal observations along life cycle of land forces communications development and maintenance program.

2. A short history of land forces tactical communications before 2006

A Quantum leap from II WW -time communications to first digitized communications

During 1980’s Land Forces communications system was changed in a way that enabled totally new ways to command and control. Before introduction of messaging system voice was main means of communications from company to brigade and beyond as utilized by Gen. Guderian  in Fall Weiss -operation in Poland 1939. Nokia Special Electronics produced Messaging system (Sanomalaite m83), that enabled encrypted short messaging on both radio- (AN/PRC-77) and field telephone (LB-field telephone m70) communications. Messaging system provided new age of both man-to-man (free format) and later man-to-machine (variable format) communications and accelerated surveillance, reconnaissance, indirect fires processes together with anti-aircraft artillery fires processes. It also enabled joint fires and joint fight with Army, Navy and Air Forces land based components. 

Late 1980’s saw first digital field communication system to replace mainly Local Battery field telephone connections within brigade and above. Brigade’s digital field communication system (YVI 1) speeded voice connections and increased their survivability but also created first messaging nodes within forces and flattened traditional hierarchical communications to more process and area of effect driven. This was the first time when communication lines weren’t following line of command anymore in Finnish Land Forces. Both combat and combat support functions within brigade were streamlined with these new means of communication. First computers were used in command posts to enhance staff work. This signals digitalization with other improvements in mobility, air defence and surveillance created new capability that was called Brigade m90, a very agile combined arms force with digitally automated communication system. Whole transformation of a brigade structure was successful because of holistic transformation program that was headed by process owners (Inspectors of Arms) and Chief of Army.

Meagre update with best systems out of military shelves

Land Forces started their next modernization in late 1990’s with Brigade 2005 program. This program introduced new field network system (YVI 2) with further distributed switching topology and increased bandwidth for both voice and message communications. Legacy combat network radios were replaced by digital radios equipped with crypto and ECCM functions (LV 241 –family). Messaging system was updated (m90) and Brigade command posts were equipped with automated Command and Control systems (JOTI –family). Signals updated systems were more survivable in battle space under heavy fire and jamming. Messaging system was integrated with C2-systems, which speeded up combat processes especially in intelligence, artillery, air defence and logistics. But like in earlier modernization focus of improvements were majorly at Brigade staff and combat support level, whereas battalion and lower levels remain almost intact. Later C2-systems requirement for better local data connections was fulfilled with ATM-switches that provided field Ethernet-services within command posts. Systems were up-to-date from military shelves (MOTS), but battle processes and tactics remained mostly traditional although automated information management increased some main support processes together with command and control. Fielding of command and control systems succeeded in artillery, intelligence and air defence, but failed in other command posts mainly because focus was more system development than C2-process transformation. Brigade 2005 program was also divided into three courses of action and drivers were mainly the three parent brigades of Kainuu (Northern terrain), Karelian (Eastern terrain) and Pori (Western terrain). This ended up with three different outcomes of combined arms battle systems with different processes and levels of maturity.  See fig. 1 for Signals evolution from M80 to M05.

Figure 1: Evolution of Land Forces Communications from M80 to M05

3. First attempts to define something that enables advantage

Separate strengths become weaknesses when combined

Land forces communications development within two previous decades provided outcome with three different field communications systems (m80, m90 and m05), that were each best at their category but not interoperable with each other. When utilized together in evolving missions and demanding area of operation, each of their weaknesses were summed up and produced major points of failure. The interoperability level of three different systems was degrading all achieved counter-counter measures; data management advantage was inclined with a mixture of automated and manual processes; and mobility and survivability was taken away with adversary’s advances in signal intelligence, jamming and artillery fires.

Is there anything new available in military markets?

Early 2000 military markets were full of systems that were even better than five years before, but markets projected the late cold war thinking of combat systems and there was no real solutions for data communications, better bandwidth with ECCM capabilities nor were there anything in command and control that really promised changes for infantry combat. U.S. Army had their Force XIX, IDF was digitalizing their brigades, but everybody else were more keen on theatre level capabilities amazed by II Gulf War operations than any tactical level improvements. Titaan in Netherlands 2002 and TOC  in Finland 2001 were showing next generation solutions in C2-structure for mission level. TETRA-system implementation in Kosovo 2003 within Deployable COTS Network concept from Finland was changing peacekeeping operations communications, but there was no real advantage gained in actual combat conditions. Combat radio network vendors were focused on improving their Low Probability of Interception (LPI), Communications Security (COMSEC) and other electronic counter-countermeasures (ECCM) but better bandwidth with packet switching was too advantage.

Can we utilize anything developed in civil industry?

Meanwhile wireless technology had leaped in civilian markets producing different (WLAN, WIMAX, 2G, 3G, Flash-OFDM) waveforms. Many parallel waveforms brought up the need to integrate them in one transceiver thus software defined radio (SDR) concept was created. In Finland Defence Forces started investing in SDR development 2001 onwards. Commercial satellite communications advances provided better services (Mobile phone, narrowband IP-connection) than legacy military communications satellites which suffered lack of investments and performance. Packet switching technology had survived after Telco driven ATM-hype and stabilized both IETF-driven MPLS- and Metro Ethernet –switching markets. Voice circuit switching had been replaced with Voice-over-IP –services with struggle between Telco and IETF standards. Open source programs introduced new ways to develop military specific systems utilizing civilian basic functions. Linux-operation system introduced new possibilities to utilize same platform, but tailored for different purposes. Every military force was experimenting with COTS-technology and some traditional Defence Communications vendors were threatened by civilian solution providers. Only salvation to traditional Defence industry seemed to be interoperability and COMSEC requirements that military society was not able to change in the pace of technology evolution.

What are we actually doing?

As mobile communications, personal digital assistants and advanced information management tools were accelerating the productivity of private sector, military was also after new capabilities. Concepts of Effect Based Operations were learned from Kosovo operation 1998 and tested in Iraq operation 2003 and further in war between Israel and Lebanon 2006. All lessons indicated the need of more agile force, better effect at tactical level and more understanding for strategic corporal. 

Future Soldier programs were drafted as infantry was keen on getting cool looking gadgets from digitalization programs and new cyber competence recruits had adapted from Internet war games. Wildest industry dreams included Head Up Displays (HUD) within helmet and extended reality environment to each soldier. Fortunately some field studies ended these visions, finding again that sight is not best way to communicate with human being in stressful situation but hearing and feeling.

To make sense of all ongoing things and future requirements in Finland, studies of future battle was conducted first at literature level, then capturing lessons from military history, further defining alternative concepts of combat, and finally having war games assisted with operational analysis tools. While this was ongoing, something was required to do in able to prepare Signals for the next leap of communications and information systems in battlefield.

4. Three parallel courses of action

Since end state for land forces fighting concept was still under development, no definite requirements for Signals capabilities was given. Although it was clear that communications together with data management technology would be the major enabler for future forces integration. Thus it was imperative for Signals to proceed with tactical communications, three parallel courses of action was adapted: (1) Commercial technology utilization, (2) Open Source based tailored system approach and (3) military-of-the-shelf -solution. These parallel projects were implemented simultaneously in quest of capturing wider understanding and different initiatives. COTS application presented widest ground for crowd sourced development since Cisco routers and switches were widely used in fixed networks of Finnish Defence Forces. Ascom access network system was chosen for open source course, because it was widely used in Navy and Joint access networks and provided good bases for development with agility of a small Finnish vendor. Material Command was given the task to seek any applicable military solutions from MOTS –markets and Signal School heads up to survey other forces in international exercises. 

Figure 2: Three parallel courses of action to seek possibilities for tactical communications improvement

Commercial of the Shelf (COTS) IP solution with Cisco routers

As Cisco routers and switches were widely in use around Defence Forces and first field trials were done as early as mid-1990’s, they were natural source for troop initiatives in tactical land IP-network experimentation. Tuning IP-packets to fit into narrow 16-32 kbps circuits optimized for voice connection was challenging. Especially when quality of connection was mostly below 10 -6 BER. Routing was another problem. Connecting together larger networks created too heavy routing traffic for narrow bandwidth. Familiar OSPF was either too slow or too heavy for tactical routing. Management of Cisco routers was either Cisco Works type or relied on SNMP-protocol, both quite unsuitable for narrow band connections and conscript training. Basic pessimists were arguing that taking COTS-devices to field conditions is not a solution and they do not last long dust, moisture, cold and heat. In real world surprisingly few COTS -devices were damaged by environment causes. It appeared that physical interfaces wore out because of repeating cable connecting and disconnecting during training. 

The fact, that Cisco IOS was educated in most technical schools and conscripts were familiar with using IP-connections at home, created advantageous conditions for accelerated conscript training and provided faster adaptation than military specific system interface. New technology required more from instructors than from their disciples and it took some time for instructors to change first their attitude and then their competence.

Tailored solution based on the family of open source access systems

Since Navy and Joint access networks had implemented tailored open source solution for their usage, this option was decided to be starting point of exploiting new possibilities. Access router did already have WLAN, RJ-45 and fiber optic interfaces attached to Linux platform with open source routing, encryption and VOIP packages. Routing was not applicable as is, system management was web based, VOIP -service was for access point use only and cabinet was not ruggedized enough, but structure promised good options for further development with reasonable price. Routing optimization was on way to more field friendly protocol, adaptors with legacy field systems were under design, open source encryption package enabled tailored configuration and even with VOIP –services vendor had a plan to build more distributed design. Implementing IP –packet transfer in narrowband (1024 kbps) and disrupted (BER < 10 -6) channel remained only real technical challenge. Thus testing and experimenting was focused on finding solutions for this.

In the midst of development process owners of this small agile company sold their shares to Ascom and international enterprise with different working culture was not able to keep original development team aboard. This resulted a chain of changes in development team, loss of communication with customer and in the end loss of the trust of customer. Unfortunately people at customer’s side changed also. New stake holders did not study original plans but created their own, some points of connection were too busy to pay enough attention on what was going on, project managers changed from iterative development to waterfall development with different priorities and strategic level forget to give direction and communicate totally. 

All this resulted a situation, where vendor was not able to meet environment tests and had difficulties to provide tactical EUROCOM -interface. Secondary requirements for end state point of view, but become acute and with high priority in procurement process. Short term failures ended up with contract dispute and withdrawal of both sides. 

Military of the Shelf, (MOTS) solution

Defence communications providers had either products that were based on digital ISDN –exchanges or they were promising to deliver All-IP functions in their next versions. ISDN and voice circuit was there because NATO’s inability to follow development from circuit switching to packet switching technology. NATO legacy was too extensive to make swift changes. New members like Poland adopted different bath and designed field systems with domestic providers that had only outer interface with NATO ISDN. Thales had SOTAS -family of field devices, but their features were immature at that time. Kongsberg had new IP-switch only as a prototype. General Dynamics had something under development but no products. There was plethora of small and agile companies that had ideas but lacked founding. Bigger Telco vendors like Cisco, LME or Alcatel did have ruggedized products, but their features did not differ majorly from their COTS –products and they had closed programs with big price tags for tailored development.

When asked information on estimated prices and maintenance costs, traditional defence vendors gave price tag that were either defined for smaller forces or too long life cycles. They overprized themselves in competitive market where smaller open source companies or COTS products were infiltrating.

5. After successes, failures and sense making, a road map appears

Crowd sourcing may bring up solutions and they are quickly adapted whilst promoted by peers

While misfortune in two courses of action, there was welcomed initiative coming within Signal troops. As team of officers and engineers were experimenting with Cisco-routers and YVI 2 –channels they found out that several 16/32 kbps channels was possible to trunk together and provide more bandwidth to data connection. Four trunked channels provided 128 kbps gross bandwidth for IP –transfer and still enough channels was left for voice circuits. Team was further encouraged to design whole IP-network for brigade and come up with prototype construction. This happened in one annual C4IS -integration and demonstration exercises, where team showed the design and configuration to other units around nation. This accelerated Tactical IP -transformation (TACTIP) adaptation in other units since it was advised by peers, recognized in shared occasion and implementation did not require huge effort.  

MOTS and COTS procurement differ and need special competence

Buying COTS devices via military equipment procurement process appeared to be difficult since Material Command did not have competence in COTS maintenance procedures with annual updates and clauses in warranty conditions. They were also having difficulties of not following waterfall procurement approach, when they were asked not to arrange competition between products but possible vendors of field proven product. Because procurement decision was not based on lowest item prize but total cost of life cycle of whole fleet of capability, which was mainly service, they were uncertain with comparison criteria. This unfamiliarity of COTS-procurement delayed the delivery of routers to units already in waiting in a degree, that a bypass was needed to get initial devices fielded. Procurement bypass was provided by Defence Forces C4 Centre with better competence of similar COTS systems utilization.

Complex system of systems, as field communication system is, needs reference environment to manage changes, configuration and problems together with improved communication between people

As brigade base network was updated with COTS routers mainly installed by units themselves, the Material Command expressed their concern on configuration management and safety of operation. This created a window for opportunity to create a reference environment in order to manage coming tactical communications systems transformation. Material Command, Signal School, Maintenance Facility and main vendors were asked to join in this quest of managing changes and being able to solve together 2-3 level problems of complex communication system. Reference environment also provided tangible “small world” for all engineers and officers to come together with their requirements, problems and possible solutions, thus the time from problem detection to implementable solution shortened drastically. 

Within 5 years period any development program faces changes, new possibilities and problems

As other courses of action slowly withered or were doomed with problems, COTS line was successful. Technology was not the best for task, but required competence was easily achieved by conscripts and devices were expendable because of low unit price.

Signals tactical and technical training was started ahead of supported units. Instructors and leaders training was scheduled ahead of troop training. Since time table and requirements changed, two parallel baths was defined for Signals as presented in following figure 3: 

1. Model 12 that was constructed from updated legacy communication systems and provided new services by COTS –devices. 
2. Model 18 that would follow m12 starting from 2018 with totally new technology, but matured tactics and processes matured while training and exercising with m12. 

A spiral development approach was adopted for m18 with test, reference and pilot environments and equivalent feedback loops to achieve required DOTMLPFII -maturity before fielding. 

New technical possibilities appeared while building m12 capabilities. After various experiments with COTS-devices and their vendors, a new domestic producer appeared. A Finnish company with mainstream in mobile communications and special systems was able to pilot Software Defined Radio platform that included major features of the failed Ascom access node. 

Figure 3: Two lines of development for new tactical communications capabilities of renewed fighting

This was a result of Nokia driven development started early 2000 within one of the best technology hubs of Finland, where University research, Nokia vision and resources, SME agility and Government funding was integrated. Lessons in Software Radio development were adapted from civilian mainstream and shared with international military SDR development forum. Lessons from Ascom node was shared with company and their military counterparts for not to repeat past failures. A small steps approach was adopted with renewed procurement processes in Material Command to mitigate risks that always follow introducing of new technology.

Signal School’s development and education co-operation with Aalto University was able to produce a prototype for new field messaging software. Field message solution was simpler to use but much more efficient than existing Nokia based messaging system. It included tailored encryption and promised to be able to maintain the main capability of combined and joint collaboration between men, machines and organizations. All these new possibilities were able to be included into m18 plans, because m12 was taking timetable pressures out and providing sufficient services for tactics and processes to mature. 

Signals needs requirements and drivers from other arms to be able to multiply their combined effect

As m12 services were trained, land forces renewed fighting concept matured in war games and first field tests started to give better understanding of new requirements for Signals. Operational level requested better understanding of situation and foresight in possible scenarios. Tactical level required swarming tactics with platoons and patrols to be more agile when facing adversary. Combat technical level required more efficient processes for combined arm effects. Combat support services required on-time control of support network with client driven processes as depicted in following figure 4. 

Figure 4: An example of four levels that were matured within renewing Land Forces fighting

6. Intermediate solution Model 2012

System of systems calls for integration and optimization both horizontally and vertically

As TACIP solution with COTS –routers provided new services, other parts of m12 land communication system of systems was defined and new concept was designed through extensive integration testing and experimenting with different solutions. After trials a compromise configuration was found for both YVI and router structure, which provided near null-configuration even when connections and topology were changed. 

To get other parts of technical capability up to date with TACIP services, last midlife update for Nokia message system was executed. This improved geographical information interoperability with some encryption features and extended systems lifecycle to meet m12 requirements. IP connectivity provided more bandwidth to messaging with better routing to survive changes and kinetic effects in area of operation. It also solved message network routing problems with more effective IP-routing.

Since legacy Combat Radio Network was not able to handle IP-packages, messaging remained as an important connectivity and encryption layer for m12 communications. All Army command, control and information systems were able to communicate via messaging system so troop leader were able to order support from all arms within the brigade. Old messaging terminals were substituted with field computers that included messaging application together with Battle Management System applications.

Because field radios in Combat Radio Network (CRN) –system were old, their producer did not provide any maintenance services or spare parts for them. It required a special arrangement to extend life cycle of whole fleet of radios to meet m12 requirements. Distributed maintenance and storage was discontinued and centralized maintenance unit was founded with responsibility of whole radio fleet and its lifecycle. Some radio units were assigned for spare parts (cannibalization) and life cycle readiness requirements were set to drive sustenance for remaining life of devices. 

Capability is not only material items but all DOTMLPFII components functioning together 

Signals new capability included changes also in other parts of DOTMLPFII structure as explained in figure 5, thus Signal School arranged several Signals tactics and doctrine workshops to create and deliver required understanding. This was aligned parallel with land forces fighting doctrine development in many computer assisted war games and live exercises. With this design process other arms, especially infantry, artillery and sappers, did set their requirements to Signals support and in the end state combined effort created more capability than merely their sum would be able to project.

Organization was changed to support better online network operations and maintenance. Most challenging was to transform deep functional organization with sub optimized procedures to service provider’s value chain that is driven by client’s needs. Also distributed way to employ troops but with coordinated way to effect to adversary, was requiring a lot from leaders, communications and logistics.

Training was scheduled within Signal School, Reserve Officers School and other Signals units before user training commenced.  This provided readiness of service that Signals needed, when troop leaders and platoons training began. Material and software updates were provided always through reference environment, where it was tested together with all stake holders of Signals capability, harnessed, integrated and delivered to operational system of systems with balanced performance. 

Both platoon leader’s, forward observer’s and signal officer’s leadership skills needed to be transformed. First two leaders were trained to act even more as a team and utilize combined arms effect in fighting. Signals officers were trained to be more supportive towards fighting and same time more capable to manage distributed and independent patrols. 

Maintenance personnel was appointed to take care sustenance of programmable electronics. Long leap was taken, when repair shops specialized to analogue technology, warehouses with optimized off-line device management and ICT-support units with device focused procedures were transformed to support on-line warehousing with configuration management and disposable devices. 

New facilities were built to support both training and maintenance of new systems. Intensive training required new base stations and connection points within garrisons and exercise areas. On-line warehousing, in which all communication units were stored on line with power switched on, required new cabling on shelves.

New information sources like weather forecasts for artillery, digitalized RAOP –data for air defence, Blue Force Tracking data from other components and Joint level operational picture data was directed to support units situational awareness. Additional information exchange gateways was build and information flows was directed to support all fighters. Focus of information management shifted from command posts to units and domain boundaries were pierced by flows of new information. This really transformed both information management and combined fighting for new possibilities. Legacy processes were questioned by new possibilities appearing with new information.

Figure 5: An example of DOTMLPFII capability components and coordination of their development

Interoperability within technical system both horizontal and vertical dimension was guaranteed both with reference environment and with annual integration and interfacing exercises. Interoperability through whole DOTMLPFII -structure was assured in pilot environment, where all bigger changes were tested, practiced and mapped before fielding into operation. Eventually change management was following three different flows of weekly, quarterly and bi-annual delivery. Weekly updates included smaller patches, configuration corrections and information assurance remedies. Quarterly changes included larger updates of operation systems and applications. Bi-annual changes introduced new features and services, which were required by units in field.

Doctrine includes management that starts with capability life cycle planning, which in one hand takes care of smooth transformation, but in other hand strives for strategic advantage over adversary’s capabilities in probable area of operation. It goes through program and portfolio management and is not afraid to give freedom to Corps initiatives when opportunities appear. It creates collaboration between various stake holders to keep everyone within same understanding and level of communication. It ends up with stabilized structure and processes to deliver quality services and continuously improve their effectivity and utilization.

7. Stabilizing the maintenance, development and risk management of communication system of systems 

Between developed technology and service requirements from units, Signals needs to follow continuous development principle

Signals transformation was not only introducing COTS –technology to gain quick wins, restructuring organization and implementing new procedures, but also creating long term procedures and culture for continuous improvement and change management.  Doctrine, organization and tactics were studied and developed in Signals annual tactical seminar, where previous years performance metrics was analysed and new possibilities were introduced. Education, training and learning were improved via Signals annual training seminar, where metrics of previous year was studied and new measures for education was introduced. As continuous system change was either pushed by provider’s technical updates or pulled by client’s functional requirements, annual technical interoperability exercise brought Signal troops together to implement new devices and services, test their interoperability, fix their service processes and learn from each other.

Bi-annual field exercises for conscript troops

Since conscript troops are produced bi-annually in Finland, there is a series of unit exercises at the end of each training period. These exercises train and test combined arms co-operation within battalion task force with live fire. This provides ultimate peace time framework for Signals troops quality and effectiveness measurement. Each signal patrol, each level of technical system and whole task force C4I –system is measured against value they are providing to other combined arms in fire effect, agility in movement and survivability in hard conditions. These measures together with commander’s judgment gives basis for estimation capability sustenance of signal units in reserve. Measures give also tangible drivers for Signals to improve their services without continuous operations in warlike environment. This is captured as goals for following year’s plans and orders for each training and service providing unit in Signals. Without these national defence exercises, Signals may be tempted to follow only lessons identified in peacekeeping operations and that would not prepare forces for next war. 

Life-cycle management of Signals C4I –system of systems

New, legacy, extended life-cycle and COTS devices are integrated to a C4I -system of systems. This technical complexity together with Signals personnel and procedures are enabling combined arms tactics, functions and procedures. This intertwined structure creates a new kind of capability life cycle management challenge, which is introduced in figure 6. This pace of change is confronted with lessons identified from current operations in Iraq and Afghanistan, where adversary is able to learn and change their fighting technics within 24 hours by utilizing differently COTS –technology, facilities and terrain familiar to them.

Figure 6: Some examples of Signals system of systems change cycles 

System of systems changes should be done by value chain in continuous flow mode driven by performance that is a balanced between client needs and system vulnerability. No C4I -system of systems is isolated any more from surrounding structure, information flows and many processes passes over organizational boundaries. Every chain is as strong as the weakest link. Technology, competence and procedures must be updated aligned to keep the chain equal strong. There are some general update times for C4I –system of systems presented in previous picture to give example of required pace of change in networked force.

Signals needs value driven procedures that provides a service flow to supported combined arms forces

Signals assets creates intertwined system of technical systems with both horizontal topology and vertical layers. This is integrated with people and processes to create holistic C4I -service provider system of systems, which by itself is of no value. It is only one part of value chain of combined arms forces and has many interfaces both with fighting components and supporting components. Signals is the glue that keeps distributed combined arms together as a force and multiplies their effort by providing tools for improved information utilization.

This complex, intertwined and continuously changing system of systems requires the  life-cycle management of programmable and trainable capabilities as depicted in figure 7. A continuous flow of services is being provided to clients at same time as both continuous and disruptive development occurs. It is like driving a car on a highway while it is being serviced and gradually changed part by part. Service performance is optimized to meet combined arms tactical needs.  Units’ requirements of improvement are fulfilled with fast solution finding by stake holders working together around reference environment. If needed, defined solutions are further tested in pilot environment, before launching them to operation. Same iterative cycle is followed with each update and patch that is provided by subsystem vendors. 

Figure 7: An example of signals capabilities life cycle management

Both legacy and new services are being planned as capabilities and not just new systems that replace older systems. This create value driven logic for new investments, which are first modelled and simulated in virtual world in order to make sense of all possible changes required in existing system of systems. Technical solutions for modelled services may be experimented in both experimental and reference environment, where both existing providers and new vendors share awareness of future needs and possibilities. 

Procurement is then given a task for iterative development with bi-annual delivery goals that are coordinated with cooperation in reference environment. After technical integration in system of systems reference environment, change items are further tested in pilot environment to integrate them through all DOTMLPFII dimensions. Eventually change items are ready to be delivered into operation in one of the update windows or suitable rotation of troops. Every change is prepared and followed with guides, training and feedback gathering.

8. A road to next generation solution

Utilizing the lessons identified in developing Model 12, it was less risky to plan a holistic DOTMLPFII capability road map for next generation Model 18 development. Road map was constructed from sequential loops called spirals, where advance is achieved by small iteration that are being tested and fielded while learning all the way. The best feedback was provided from m12 training and exercises, where other arms and services were improving and learning renewed fighting. As new requirements was captured from process development, several possibilities were experimented in technology line of operation. Suitable technical increments were forwarded to integration testing and further to pilot testing. This provided agile method to advance at the pace of combat development and not be driven too much by fanciest technology.

Spiral development with continuous cycles through laboratory, reference and pilot environment 

Laboratory and reference environments were created side by side to provide the best possible understanding and collaboration framework to all vendors and stakeholders. Pilot environment was appointed to a whole brigade, where all arms were combined for testing and training of renewed tactics. Reference environment supported pilot by delivery testing, problem management and spare parts. If technical problem was faced in the pilot environment, the root cause was analysed and solution found in reference environment. Spiral development is described in figure 8.

Figure 8: An example of spiral development in software defined C4ISR system of systems

Since process and application development was based on semantic knowledge model and communications systems were mainly software defined, it was possible to utilize independent spiral cycles for each layer of applications and communications. Main version (vX) spiral was annual, but sub spirals (vX.y) were spinning quarterly. Application layer and information model was developed with quarterly scrum sprints and iterations were introduced over communications structure first time in laboratory environment. After first spiral feedback both application and communications were adjusted to second laboratory test cycle. After second successful tests, system was duplicated to reference and pilot environments. Pilot brigade started conscript training, whereas engineers continued to finalize configurations in reference environment. Simultaneously second main spiral started with process iteration and knowledge model workshops in order to create new capability iterations for future sub spirals.

Value driven perfection by client and not by providers or contracts

The quick pace and small iteration steps made it possible to adjust any feature separately in application and communications layers according to tactical and combat technical maturity or phase of training. Development listened very carefully comments coming from pilot brigade. Because pilot brigade had best understanding of holistic DOTMLPFII development situation, they were delegated the decision of proceeding pace within the year. The entire development chain was adjusted to bi-annual decision points including contracts with vendors. This ensured that technical development was supporting other capability components in combined balance and whole value adding chain was following user’s feedback to achieve best usability. Laboratory environment was utilized as technical development buffer, where more advanced or accelerated features were tested but then downgraded to enter to reference environment. Twice a year pilot and reference environment was updated with new capabilities whereas patching and configuration changes were made weekly or quarterly.

Program office was controlling development at annual level agreeing on annual goals with all stakeholders and issuing resources to achieve them. Risk management was additionally managed with several parallel options:

• Annually major problems at technical development were mitigated either by using latest functional system version in training or substituting missing feature with nearest COTS-capability.
• Where ever technical development was proceeding faster, it was allowed until laboratory testing, but downgrading to balance other features was insisted from reference environment onwards.
• Each annually agreed delivery was required within that year and within agreed price. Within year variation was allowed, if it was kept within training schedule of the pilot brigade.

This produced one time a situation where pilot troops were using four versions older BMS over two versions older messaging system that was using one version old routing program but one channel was substituted with nearest equivalent COTS -communications system. Complexity of this kind was possible because of strict integration testing with heavily adhered testing routines and good communication between developers and testers.

9. Summary

Developers have same weaknesses as any humans. They tend to forget information that does not support the adopted line of their thinking. They tend to narrow their path as time goes and problems occur. They tend to be the only ones that understand how things should be done and they tend to become blind to any evidence that contradicts their profound believes. If Signals is given freedom to develop their capability independently, they most probably will come out with best technology but not that good services the other arms are needing. It is imperative to deliver intent of whole program as understandable as possible through all stake holders to align all efforts towards same capability goal.

Large enterprises and alliances tend to stick with systems, standards and procedures that are good for interoperability but may kill any strategic advantage in long run. New solutions are often found outside the legacy stake holders and utilized only by those that have vision and will at right moment. This calls transformational leadership whereas more transactional management tends to prefer familiar solutions.

If development is divided to narrow functions with independent decision making, one often end up with sub-optimized solutions that might nullify all good features when integrated together. Portfolio management requires tangible values that every project is following with agility because real life seldom follows theoretical plans.

Portfolio management should consider parallel courses of action, when either end state or path is uncertain. Sometimes best initiatives may come also from field units and not necessary from procurement engineers or defence vendors. In information and communications technology currently defence initiatives are rare, whereas mainstream of development is in commercial services. On the other hand open source components are providing fruitful possibilities to both defence vendors but also to their new challengers. Military capability developer may collect some good initiatives if they explain their problem clearly in Request For Information and publish it wider than only to legacy defence industry. 

Procurement procedures needs to be changed if military, government and commercial technology is mixed. Waterfall development method proved to be unsuitable for any system of systems development but stands on it’s ground in small subsystem development.  Spiral development has proven to be best method for managing iterative changes in complex C4I -system of systems. Any project will face probable failure if communication between people and organizations is not functioning. Even organization cultural differences may produce difficulties between points of contact.

One has to follow and understand technology and markets, since it is not always the best technical solution that champions in markets. It is sometimes the brand, package or channel that decides who wins in current markets. C4I –services life in markets is shorter than any time before. It is seldom that modern IC-technology can endure 20 – 30 years in service as sometimes expected in military.

With C4I -system of systems the interrelationship with all other systems makes it almost impossible to change anything independently. Even standards are short lived, when default agreements rule. There is always next version in coming, which is always better than any previous product or service. Only system in training and full operation is capability.

Technology itself is not force multiplier but when machines, men and procedures are trained as integrated system and supported with better information, then force effect may be multiplied. One should consider always other parts of DOTMLPFII –capability structure when pursuing to develop integrated military force.

Networked technology requires maintenance and updates delivered at same pace as other nodes in value chain. If one part of that technology chain is outdated or noncompliant, that node becomes the weakest link of the whole value chain. This requirement extends over organization borders to all networked stake holders. Unified and agreed security and maintenance policy should be implemented though network with transparent audit track.

It is mistake to think that within 5 years long development program there will not be any changes, problems or new solutions. As in any military planning, one should keep close eye on assumptions of the plan that is under execution. In development programs stubbornness is not necessary the way to success. But it is sadly the only way, if there is no risk or agile program management aboard.

One might utilize the newest technology as a first adaptor, but implementation needs more time, development steps should be careful and one should have alternative solutions if one part of complex structure fails. After all there is a possibility to gain strategic advantage with early adaption of latest technology. In the end of the day it might not be the newest technology implemented, but development and maintenance process that has been adopted with technology that provides unrepeatable asset at strategic level.

If one does not have enough investments to replace all sub systems within short time and possibility to train all forces at once, one should be prepared to extend the life cycle of legacy systems as a part of new system of systems capability.

If one focuses only developing capability with investments, one might not achieve advantages of continuous development, which may be even better. Competent and motivated personnel can develop capabilities faster through small changes than force is able to adapt with waterfall development. This is case at least in conscript and reserve force since there are so many different professionals coming together to defend their country. With continuous development one must identify the value, measure it and publish results through to the whole force projection chain to enable learning and improving.

It might need to establish on-line warehouses to maintain programmable electronics at up-to-date level and configuration ready for operation on demand. This calls for new competence, skills and procedures from existing support, repair, storage and maintenance personnel.

C4I system of systems development and maintenance is too complex process to have long lines of communication and deep hierarchical command structure. Flatter the organization and shorter the lines of collaboration, the better understanding between stake holders and lesser risks. One cannot buy system of systems of the shelf, thus integrated project team is imperative.

Next generation technology promises major advantages, but requires more maturity from all stake holders of development and maintenance network. As always technology can provide short strategic advantage, but in the end it is more of organizations capability to continuously improve their capability, than long, risky technology leaps that may crash land. It is coming rare that one man can understand or one vendor can provide all that integrated military force is requiring for next generation capabilities.