How to Prevent Vendor Lock-in for Cloud Services?

DISA is proceeding to offer e-mail and collaboration enterprise services for DoD. The issue now is how to prevent vendor lock-in when selecting the provider of cloud services.

Almost all of the existing e-mail applications are Microsoft based. It would be logical to continue adopting versions of Office 365 cloud services as the preferred solution. Whether this is hosted at the Microsoft Azure cloud environment or as a private cloud in one of DISA DECC centers is a matter of cost and reliability. Cloud hosting would allow scaling the e-mail services as other parts of DoD join the enterprise cloud e-mail offering. Microsoft, or its licensee, would manage the e-mail software while components would control user access rights.

As a short-term transition strategy migrating everyone to a standard Microsoft solution could be one of options how to proceed. It could enable migrating existing Microsoft operations to DoD-wide standards. Unfortunately, this approach is likely to be too lengthy, too expensive and managerially hard to execute. The variations and multitude of different versions in the existing e-mail and collaboration solutions are too diverse to allow the creation of uniform e-mail services. It would make more sense if DISA considers offering a “core” e-mail cloud based on commercial services. DoD components could then convert to these “core” services in incremental steps.

To attract participants to an off-the shelf “core” e-mail service DISA needs to operate a secure, low-cost, easy to use e-mail (and collaboration cloud) offering. Conversion costs for access to a “core” offering should be incurred by the user and not by the cloud utility. Conversion costs can grow without limit as local requirements are added. A computer utility, such as DISA, should offer standard services at low prices only, leaving to users to add unique features under software architecture controls. The incentive to convert to utility services should be with the user seeking lower total costs of ownership and not the utility whose has only the objective of delivering operating efficiencies.

 Meanwhile, DISA should be planning for an exit strategy from an exclusive Microsoft solution to an offering that allows multiple competing suppliers to bid for the DoD business. The prospective bidders must be also able to deliver greater flexibility to adapt to rapidly changing information technology choices. Of course, Microsoft should be in a position to offer its services but without an exposure that its services would constitute a “lock up”. Here are some of the elements that should be included in a viable exit strategy:

1. Allow for the conversion to non-proprietary protocols
Microsoft messaging uses exclusively the Application Programming Interface (MAPI) as the messaging architecture for transactions. This is a proprietary protocol for connecting Microsoft Outlook with Microsoft Exchange. A DoD enterprise solution should not use a protocol that is exclusive.

2. Adopt protocol that retains messages
Every vendor uses the Internet Message Access Protocol (commonly known as IMAP). It is a protocol that allows an e-mail client to access e-mail on a remote server. Instead of relying on MAPI all current user devices, regardless of manufacture, can process IMAP. This protocol then allows using every desktop efficiently, whether it is an Android or iPhone device.
There are two available e-mail protocols: IMAP and POP. When using IMAP a customer is accessing an inbox on a central mail server. Although messages appear on the user’s computer, they remain on the central mail server.
POP does the opposite. Instead of just showing you what is in the inbox on the mail server, it checks the server for new messages, downloads all the new messages and then deletes them from the server.
The DoD enterprise offering should be using IMAP. Records retention policies make this a requirement.

3. Plan for conversion strategy from Exchange Server
Microsoft Exchange Server is available in numerous versions. It is a proprietary client-server product developed for enterprise uses using Microsoft infrastructure products. It has limitations on its interoperability. During migration to a cloud service, the Exchange Server can be used as a transition solution but eventually must be replaced by an open source application.

4. Plan for conversion strategy for Active Directory
Active Directory (AD) is a proprietary directory offered by Microsoft. It uses a number of methods to provide a variety of network services, such as:
• Central location for network administration and security.
• Information security and single sign-on for user access to networked resources.
• Standardizing access to application data.
• Synchronization of directory updates across servers.
Active Directory stores all information and settings for a deployment in a central database. Active Directory allows administrators to assign policies, deploy and update software. Active Directory networks can vary from a small installation with a few computers to tens of thousands of users, many different network domains and many geographical locations.

The Active Directory features are one of the principal means for reinforcing a Microsoft control of enterprise e-mail.

SUMMARY
To standardize and then to unify hundreds and possibly thousands of separately maintained versions of Microsoft e-mail applications involves large expenditures. At present the costs of cleaning up what is already in place in order to conform to a DoD-wide e-mail cloud is difficult, particularly if the cloud provider pays for all conversions and migration costs because users will keep adding new requirements to retain legacy features.

Consequently, at the end of the current approach to the consolidations of all e-mails DoD will end up with Microsoft solutions that are locked-in.

While proceeding with e-mail integration, DISA should proceed with the selection of options that would be interoperable as well as offer competitive choice from multiple vendors. Technical choices that are made during the proposed migrations should comply with the requirement that each vendor also offers exit strategies that assure DoD enterprise solutions that remain flexible.