Requirements for a DoD-wide E-mail System

In August 2011 the U.S. Army 's transition to a single enterprise e-mail system has been put on hold to work out technical problems. With only 9% of the migration completed (88,000 accounts) it is not surprising that Army has uncovered that the existing e-mail service need “cleaning up”. The Army has designated its enterprise e-mail as a Software-as-a-Service (SaaS) cloud solution, though it is only a "hosted" cloud solution.

A lack of standardization has been the main problem as the Army hopes to install an enterprise e-mail program with DISA as the implementation manager. The Army e-mail could to be then used as a prototype to extend it to more than five millions of DoD mailboxes. However, it is unlikely that such standardization can be ever achieved.

A single, standard common operating picture replacing all e-mail versions would facilitate conversion to it. However, it does not appear that what DISA/Army is doing. To accommodate diversity for rapidly changing mobile technologies the Army is installing additions to the hosted e-mail. Such an approach is not likely to succeed because it will be difficult to maintain.

The DISA/Army DoD enterprise e-mail system may be flawed on account of the following:
1. The term SaaS refers to business software that runs exclusively on Cloud servers, rather than on- premise at a customer site.  The vendor provides a service that can be subscribed to and accessed over the Internet rather than a physical product that customers have to install and manage on their own. But the Army SaaS is not SaaS. It leaves parts of legacy software on desktops, laptops or smart-phones.  Users receive an exact copy of what they have previously used, without change. Consequently, the standard software had to be modified for coping with a variety of conditions.
2. What DISA is delivering is a “hosted” solution with custom features, not standard low cost SaaS software that offers only pre-defined features.
3. A “hosted” e-mail can’t offer the benefits of real SaaS because it expends too many resources in maintaining multiple versions of both its own software as well as a broad matrix of supporting infrastructure.
4. Army customers insist on retaining different versions of what is already in place.  They are not able to share infrastructure and operational resources to the extent that real SaaS vendors can.

The Army SaaS needs to have proceed with a program that has the following characteristics:
1. All customers share a single version of the e-mail software. This is a “multi-tenant” architecture;
2. All customers share the identical IT infrastructure and operational resources, using only browser Internet access;
3. Updates for features or program fixes are included with the service at no extra charge for every e-mail user;
4. World-class security for data center operations, applications, and data is concentrated at the SaaS cloud level;
5. Service level guarantees including 99.9999% uptime, backup, and disaster recovery;
6. Ongoing maintenance and performance tuning is performed by the SaaS vendor, without user involvement
7. There are no perpetual licenses, only pay-as-you-go charges.
8. The system can be configured to adapt to
the needs of individual customers without compromising the standard system. In order to serve many clients, most multi-tenant SaaS solutions offer configuration options to meet different needs. Configuration options are captured separately from the standard e-mail offering. The SaaS vendor will often guarantee configuration options. On-premise customizations are not supported.

SUMMARY
The current Army and DISA effort to install a standard e-mail system, which is potentially a prototype for all of DoD, is stalled. The current solution, based on an extension of existing Microsoft services, is attempting to slide an e-mail replacement on top of the existing multiplicity of legacy solutions. Such migration may not be economically justified, as evidenced by Congressional refusal to support the budget for this program.

Perhaps a more decisive cutover approach may be not only feasible but also executable in less time.