Network Centric Software Engineering

I was reading the Cooper Journal of Interaction Design when I stumbled on a few articles on Sensemaking and Network Centric Operations (NCO), a new military organization doctrine that tries to use information technology to facilitate operations of geographically dispersed units and to enhance operational effectiveness compared to a traditional force. For me this sounds relevant to software engineering, too, so I got interested. Wikipedia noted that a similar approaches have already been adopted by the UK and Swedish military.

The idea of the NCO is to enhance the situational awareness by improving the information exchange between the troops. This includes perceiving the environment, comprehending its meaning, and projecting the status in the future.  As a software engineer this sounds very familiar. The SW projects rarely have situational awareness even when all the developers are present on the same floor or even when they are sitting side by side. When the project is introduced with the off-site customer or the outsourced Indian developers, the information exchange problems tends to escalate even further. Why it is so difficult for the software engineering teams to exchange information even between the developers? One article on the Cooper Journal discussed the similarities between the SW Engineering and Movie production, but one commentor noted that the most significant difference is that in the movie casting the director has the final say of everything, while in the software projects nobody has the technical and visionary ability to comprehend all parts of the system or communicate on all topics.

The NCO approaches the problem differently. The key process of sensemaking involves all levels and perspectives of the organization and is grounded on a robustly networked force that is capable of information sharing. The second tenet assumes that the information sharing and collaboration enhances the quality of information and the shared situational awareness. This leads into self-synchronization of the units, that leads finally into a dramatical increase of mission effectiveness.

The sensemaking process by the U.S. Department of Defence starts by

  • Forming an awareness of key elements relevant to the situation. This entails knowing ”the who, what, when and where.”
  • Forming an understanding of what it all means in some bounded context, based upon past experiences, training, education and cognitive capabilities. This entails:
    • Forming hypotheses and making inferences, i.e. generalizations (predictions or anticipations) about future events.
    • Forming a sense of the implications for different courses of action.
  • Making decisions by:
    • Generating alternative response actions to control the situation.
    • Identifying the objectives, constraints, and factors that influence the feasibility and desirability of each alternative.
    • Conducting an assessment of these alternatives.

The enhanced collaboration and higher quality of information enables people to make better decisions. I can see directly, how this can be applied on a distributed software engineering project. The practices such as a Daily Scrum already implements partly the same purpose, but it should be taken further. I envision that a NCO software engineering team would utilize tools like Twitter to continuously update the status of what they are doing, what are their problems, what things should be known about and estimates about the remaining effort. Yesterday I watched a Apollo 11 document where the lead flight director Gene Kranz explained how he simultaneously listened to 7 simultaneous communication loops, but with training was able to focus on the one communication that was important for performing the current task. Similarly the twits could be a way to exchange information and meaning in a distributed SW project. However, a key enabler is to identify the communication language, or the common concepts everybody should understand. Another point is to define the key elements of the situation. The NCO -model seems to promote also the learning organization -dogma by giving permission and tools for the team members to understand and challenge the  knowledge of others (or the situational awareness). Often the true ground-reason for project failures is not the tools or the people, but the inability to acknowledge the current situation and react to the changes.

The IT industry is surrounded by all kinds of communication software, but still unable to utilize or leverage it for meaningful communication. Perhaps the problem is with the cognitive models of software team organization and new models such as the NCO is desperately needed.