Whitepaper: Command Email – A New Military Message

It’s been a few months since my last blog. As always work commitments come first and it’s been a bumper couple of months.  I’ve been studying the military messaging environment and how it is evolving and summarized my findings in this whitepaper.  The main thrust is that organisations should be considering moving away from traditional Military Message Handling Systems (MMHS) approaches in favour of lighter, simpler, COTS based, modular and more cost-effective solutions.

“ The secret of war lies in the communications”

Napoleon Bonaparte

 

The ability to communicate effectively and without ambiguity has been, and continues to be, instrumental to the success of military organisations across the world.  Throughout history military organisations have pushed the boundaries of communication. Military messaging has evolved from smoke signals, to written letters, to telegraphs, to radio, to email and to unified communications today. Sending messages between organisations, units, roles and individuals is paramount to the success of both peace and war time operations.Military information needs to be exchanged in a secure, time-sensitive and standardised manner.  This is often done in environments where connections may be intermittent or of low capacity.  As messaging technologies rapidly evolve, the systems implemented must keep pace and retain the ability to upgrade easily and in short timeframes.  The key challenge for most organisations today is to ensure that these core criteria are met, without over-complicating messaging solutions to the point that they cannot be effectively implemented, maintained or used.  This whitepaper discusses the current military messaging environment, how it has evolved to today and the challenges surrounding the technologies. It will then go on to detail an alternative approach to these challenges which we call ‘Command Email’.

Introduction

The Legacy – Military Message Handling Systems (MMHS) – Implementing Yesterday’s Technology Tomorrow

Traditional MMHS approaches can be summed up as complicated, expensive and fraught with risk.

In past decades, military organisations have looked to international standards for guidance on what they should and should not be implementing as messaging capabilities. The STANAG4406 (Standard NATO Agreement) standard from NATO and the ACP123 (Allied Communication Publication) standard from the Combined Communications Electronics Board (CCEB), provide a great depth of information in this area.  These standards aim to specify a base level of capability for military messaging solutions and also to facilitate interoperability between organisations by providing standardised messaging formats and transport mechanisms.

A key problem here is that these international standards take a long time to develop, agree and ratify.  For instance, although updated in the last decade[h1] , STANAG4406 was created 20 years ago, a lifetime in the field of Information Technology.  This lengthy process fosters a gap between the standard’s technologies and the modern technologies that fulfil real operational requirements today.  Assumptions which were correct 20 years ago are no longer valid today.  In addition to this, the standards address functionality at such a granular level that providing such a messaging capability requires the inclusion of a significant amount of components, often with several different vendors being integrated into a wider system.

 

These MMHS systems can evolve into proprietary and complex beasts. They are not only difficult to deploy, but once in place, become a nightmare to administrate and costly to maintain. The inherent complexity introduces risks which often push projects over budget, even after the detailed and extensive procurement process which is required to purchase such systems.  It’s a long, expensive and complex process, the result of which is that, if an organisation is lucky, it will be in a position to switch the thing on. Once switched on, it’s already obsolete and they are stuck with it.  Ongoing maintenance costs are considerable and generally increase as the technology becomes more and more obsolete.  Something clearly needs to change.

Command Email – A Modern Approach to a Modern Requirement

A modern military messaging system should be built on a solid but dynamic platform of technologies. It should primarily be based on today’s widely-adopted interchange mechanisms and formats. Proprietary systems and custom-built technologies are not dynamic; it is difficult and costly to keep them up-to-date. This level of flexibility can only be achieved by a widely-deployed and mature Commercial off the Shelf (COTS) based platform.  In addition to this, experience shows that simple solutions deliver results. Complexity should be stripped out in favour of delivering only the minimum functionality required by each user as they need it. Modularity (or plug and play capability) in the overall solution is key to achieving this simplicity. Systems should also provide interoperability with international standards.  This is the focus of Command Email.

Command Email is based on:

  •    Simplicity
  •    COTS Products
  •    Modern Technology: SMTP/XML
  •    Modularity
  •    Interoperability

Simplicity

Some MMHS purists maintain that a complex requirement demands a complex solution. If this is true, then the definition of the requirement needs to change. Solutions need to be achievable and the simplest solution to any problem is usually the most effective.    When we refer to simplicity, this should not only be applied to the user experience, but also to the design, implementation and administration of the system.  Simple systems deliver results in shorter timescales and at lower cost.

Functional Requirements:
Keeping the solution simple starts with defining system requirements. When defining the requirements of a system, it is all too easy to get sidetracked into pursuing what is possible, instead of what is actually needed.  When assessing a list of requirements, each should pass a ‘Need Test’.  Although some features may look exciting, the following question should always be asked and answered with honesty: ‘Do I 100%, without ambiguity, need this functionality?’  While many things are possible, more often than not, the list of ‘must haves’ can be reduced to a level which will provide the functionality required to fulfil the day-to-day operational needs of the system.  For most organisations, these must-haves can be loosely summarised as follows:

Messaging services: the ability to create, apply additional attributes to, guarantee delivery of, send, receive, route and store messages

Classifying and labelling information/messages

Access Control: Based on classification, role, project, etc

Enhanced security: Digital signatures and encryption

Interoperability with Partners

System Architectures:

Once the list of requirements has been established, the technologies, products and components of the solution need to be identified, selected and integrated.  In legacy MMHS approaches, the list of proprietary products and components can quickly become unwieldy.  Incorporating 50 components from 20 vendors, all specialising in proprietary technologies, will make projects bumpy, drawn-out and expensive.

The reality is that a COTS-based solution with minor extensions will provide what is needed at a fraction of the cost and complexity. Using this approach still enables organisations to retain interoperability by addressing this at the border, but removes the headaches of design and integration.[RJ3]

User Experience:

Some legacy systems,based on international standards allow users to add up to 40 additional attributes and pieces of information to a military message.  It is difficult to imagine an environment where a user would want to use all 40 different fields, dropdowns and check boxes in a message. They don’t exist.  In reality, all that is required is a few additions to what is provided by a standard email client.  Only those should be available and visible to the user.   If a user has used standard email before, it is a simple step for them to start military messaging.

Commercial Off The Shelf (COTS) products

How many attempts did the inventor of the wheel take to produce something that was round, could be attached to a vehicle of some kind and would rotate to allow movement? Why go to that trouble all over again? If someone has already has the wheel, we only need a few additions to use it to fulfil our needs. A new surface may give it more traction and a hub cap might provide some protection. Building a military messaging solution from COTS components avoids reinventing the wheel.

Using COTS products provides a long list of important and tangible benefits. Here are a few to consider:

  •    Robust: Widely deployed and tested.
  •    Scalable: Often proved in large environments.
  •    Flexible: Designed to adapt to ever-changing markets.
  •    Reliable: Guaranteeing messages are processed and delivered based on priority
  •    Cost effective: Broad customer base provides economies of scale.
  •    Less Training Required: Users are often familiar with the products from non-military use. Administrator skills are transferable into and out of the military.
  •    Up-To-Date: Follow latest trends and implement latest technologies quickly.
  •    Extensive support: Bugs fixed and issues resolved quickly

Proprietary and custom developed solutions simply cannot provide these same benefits. They are difficult to shoehorn into an infrastructure and even more difficult to get out, once in place.  COTS solutions, with the addition of some specialised and packaged components, can provide the extra services and enhanced capabilities to fulfil the core criteria and requirements of a military messaging system.

Modern Technology: SMTP/XML

X400 and SMTP:

The relative benefits of X.400 and SMTP as email messaging technologies have often been debated. The argument goes that X.400 provides a much more complex and compressive set of capabilities whereas SMTP is easier to implement and manage.  While X.400 still has a place in some niche specialist applications, SMTP has been almost unanimously adopted.

20 years ago, X.400 was the sensible choice for systems where granular control and reliability were required for message transport.  While it was accepted that there was a greater configuration and administration overhead for X.400, this was considered an acceptable tradeoff to fulfil the requirements of the day. It has been subsequently included in many of the standards that were created in the early 1990’s.

SMTP and the underlying platforms and infrastructures supporting SMTP messaging have evolved.  Hardware and network technologies have vastly improved reliability and throughput rates. This makes the bulky protocol exchanges of X.400 much less important, some even defunct.  With new dynamic routing technologies now available, SMTP systems have evolved beyond the capabilities which were the original reasons for inclusion of X.400 in standards instead of SMTP.

X.400 emails are encoded in ASN.1 format. This format is very prescriptive and provides an extra level of complexity to systems, as messages are encoded and decoded for transmission.  The ASCII (text) based format used in SMTP makes it very easy to encode messages in format which can be easily understood by other systems.    It can be stated that XML is the dominant data format used in most systems that need to exchange data with other systems.  As XML can be transmitted as ASCII, this makes it a very simple process to include XML data in email messages.

SMTP systems are easier to implement, troubleshoot and maintain. It is the sensible choice for a messaging platform using today’s technologies, today.  The ability to easily utilise XML in conjunction with SMTP makes it very easy to integrate with existing modern systems. Supporting XML also goes some way to future proofing the messaging solution as and when new XML supporting applications are developed and released. It is very unlikely that new systems will provide any kind of support for ASN.1.  With this in mind, putting an X.400- based system into a modern IT infrastructure is like putting a square peg in a round hole.

Modularity

Do all the users of a military messaging system need the ability to use every function of the military messaging system? The answer is no.  What is needed is the right capability at the right time for the right people and at the right price.

Not all functionality is required by all users. Capability that is required on a case-by-case basis, should be provided on a case-by- case basis.  A Command Email solution provides only the components to each user that are required by each user.  In order to do this, functionality must be modular or component-based.  Each component should deliver its function and also should be able to function independently of the other components where appropriate.

Some users may only require some basic labelling and security, whereas others may require the ability to create and send formal organisational messages on behalf of the organisation to partners or other organisations.  Users should not be presented with the option of using capabilities which they neither need nor are unauthorised to use.  This can cause confusion and dissonance.

Once we understand our user’s needs, we can create profiles for them and only provide the components required for each profile.  Different grades of messaging capability can be defined and deployed to different users. Using this modular approach not only makes things simple for the user, but it also presents a very cost-effective way to provide the capability. An organisation only pays for the minimum that it needs, not the maximum that the product can do.

Interoperability

In the contemporary geopolitical landscape, it is rare for military organisations to act alone.  Military operations are usually undertaken as part of a large coalition of forces.  There has been a substantial shift in mentality towards co-operation and communication, where ‘need to know’ has become ‘need to share’.  In order to communicate with partners and other coalition members, we need to share information and we need to do that in a common language.  This is where international standards come to the fore and provide significant value.

International standards will always be characterised by the protracted timescales associated with bringing many nations to agreement on how things should and will happen.  Selecting the latest modern technologies for our systems doesn’t mean that we are at odds with the standards and that interoperability won’t be possible.  Interoperability and communication instead has to be addressed where it happens.  Either logically or physically, communication with outside organisations, partners or even nations, will occur at the border between the two parties.  As long as your internal system has the capability to carry the required message information, messages can be converted to the international interchange format at the border.

At the border, specialist gateways can not only be used for format conversion, but also content inspection and security checks.  Using a COTS-based infrastructure and dealing with proprietary and legacy message formats at the border, enables organisations to adhere to international standards, while at the same time meeting their real day-to- day operational requirements.

Extending the Baseline

Command Email as described above provides the minimum number of components to each user based on that user’s requirement for functionality.  Over and above COTS email, the following suggested components would provide the most benefit and greatest value, but with the least complexity:

  •    Military Messaging Forms – providing additional message attributes
  •    Labelling – providing either simple of extended
  •    Access Control – Restricting user access to send or receive messages
  •    Security Module – Enhanced signing and encrypting of messages
  •    Border Gateway – Converting incoming and outgoing message formats

Of course, there are always a number of environment-specific requirements which must be catered for and specialist components which may be introduced to do this.  For example, components that provide the following capabilities are also available:

  •    Automatic actioning of messages based on priority
  •    Automatic distribution of messages based on content
  •    Draft, review and release of messages
  •    Tools for fixed format messaging such as MTF Editors
  •    Integration with:
  •     Document management systems
  •     Archives
  •     Command and Control (C2) systems
  •     Low bandwidth messaging capability

There are a lot of possibilities, but it is recommended that simplicity prevail. If some of the more specialist capabilities are definitely required, it is highly recommended that these be considered after the core system is operational. A considered and phased approach to implementing capability will always ensure that projects have the greatest chance of success.

Conclusion

In this whitepaper we have examined the military messaging landscape. Starting with the traditional approaches to MMHS systems, we have seen that these beasts are driven by complex and dated standards, which are often at odds with current operational needs.  This puts organisations in a position where they have to seek out proprietary or custom-built products from a plethora of different vendors, which all need to be integrated in order to provide our required capabilities.  The systems are difficult to implement, maintain and administrate. No sooner are they in place than they are obsolete.  Ongoing maintenance and upgrade costs are substantial and continue to increase as time goes by. In summary, these systems are complex, costly and fraught with risk. Something needs to change.

Command Email provides a simple solution to a complex problem.  COTS-based products provide a modern technology base, SMTP/XML, which can easily keep in step with the rest of the IT infrastructure.  Robust, scalable, dynamic and easily-implemented components are able to fulfil the real operational needs of the organisation. Couple this with a modular component approach and we are able to provide only the functionality that each user needs to that user.  This has a direct and measurable impact on the cost and efficiency of the system.  Interoperability is included and achieved where it is required, at the border.

Taking all of these factors into account, we can conclude that Command Email provides many significant benefits in military messaging. It’s a simple way to increase efficiency, implement capability and reduce risk in a cost effective manner.

Author

Hani El-Qasem

1 comment to Whitepaper: Command Email – A New Military Message

  • […] The OSI model is a set of specifications, rules, guidelines, instructions and protocols that describe how networking should work. It is important to understand how this is used today. As you might guess from the above description, the model is large, complex and in some ways all encompassing. Back in the early 80′s and 90′s many companies implemented technologies that strictly adhered to the OSI standards. In fact, I worked directly with one of those related to email messaging (the X.400 protocol suite) in a previous role.  The OSI specifications are quite complex and difficult to implement. It takes a lot of specialist knowledge and effort and as a result the detailed elements of the model were soon ditched in favour of more agile standards which could be delivered quickly with ease. For example, SMTP is now the defacto standard for email messaging and X.400 is only used in some specialist areas in the military and other area. (Read more about SMTP for military email here:  Command Email Whitepaper). […]

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>