Questions about the Cloud Consolidation Policy

The main problem with migration into a cloud environment is siloed management. There are 3,000 separately funded IT projects in DoD. In each case there is hardly any funding available for cloud innovation. Contractors are overburdened while trying to serve customers to keep up with rising demands. The responses to requests for switching to cloud computing are slow while the poor utilization of $22.2 billion FY 13 O&M resources have the potential of funding such transformation. Meanwhile the processing capacity of DoD is sufficient to satisfy total needs. We have a good cloud migration strategy, but cannot progress further without a blueprint how to accomplish such a huge transformation.

DoD realizes that to gain economies of scale, it must share resources and automate configuration management at the enterprise level. Individual components are starting to turn to cloud vendors that provide solutions that promise to turn their operations into private clouds, such as Amazon EC2. Unfortunately that would creates only another isolated silo, even though a local CIO can then claim that progress is made in the desired direction.

DoD has too many business units that individually control their project budgets. Projects have different architectures. Projects have separate cost centers, versions of regulations, established policies and restricted funding. For instance there are 60 major programs in place that have matured over ten years, with total annual spending of $16 billion. These projects each contain numerous sub-contracts to support unique needs that cannot be satisfied by standard solutions that would be delivered through DISA brokerage.

Existing projects suffer from a lack of development and testing capacity. Each silo needs computing capacity quickly, but only for a short time. The testing and development capacity requirements differ depending on lease terms and locations.

Existing silos would be unable to share computing capacity for production. Compliance with supported software revision levels and patch management, such as offered by BMC, CA, Microsoft, HP, IBM and others, would prohibit the sharing of existing configurations.

Due to the relatively high cost of data center storage and desktop capacity existing silo administrators would be inhibited from deploying a standard approach to streaming a multiplicity of divers application software to a variety of virtual desktops. The diversity of over 500 data centers would prevent that without a massive data center consolidation effort that would have to precede cloud migration efforts.

Though virtualization of servers is only a partial step in the direction of cloud computing, that would not make it possible to share data from thousands of different databases. Any attempts to proceed with silo-level efforts virtualization would deliver only varying levels of automation, each with different scripts and a variety of incompatible vendor tools. When “cloud” capabilities are then enhanced for self-service inquiries that would have to fit rapidly changing data center resources. Shared cloud tools would have to include a level of policy, governance and automation to enable the cloud. This is so primarily because any cloud solution would have to be built in the context of a particular silo infrastructure, some of which is embedded in more than decade-long architectures. While this looks good on paper, such solutions would severely limit the scope how to operate across DoD.

One approach would be to include every cloud in a DoD-level service catalog. That would be replicated for each of the silos, creating a management nightmare when it comes to maintaining the service catalog for enforcing interoperability.

Regardless of the challenge of having to create a unified DoD configuration catalog, that would offer only a single standard set of interfaces to assure DoD-wide interoperability. Some systems and processes would have to be thrown out in favor of dumbed down cloud solutions that result from acquisitions that try to fit all needs. In all likelihood, most of such silo-level cloud solutions will have to fall out of the automation process due to variants that are needed to fulfill local needs, such as improvised social computing. With DISA designated exclusively only as the “broker” for making cloud acquisition choices, the chances are high that DoD will end up with new silos, each claiming some cloud capabilities but certainly not interoperable.

Consider the differences between how each DoD silo operates, the office of the DoD CIO will be faced with the enormous task of coordinating – through an elaborate committee structure - the details about software versions, machine naming, data definitions, network configuration, resource allocation, service levels, data center location and which management functions a user can perform after the silo has been completely restructured. There are hundreds of other attributes that will differentiate each silo as it migrates to cloud computing, but will remain incapable of enterprise-wide resource sharing.

SUMMARY

The just published “Cloud Computing Strategy” is an excellent policy-level document. It has not defined the specific steps that must be taken to proceed with implementation. What we have so far is not sufficient. Without implementation directions the current way of proceeding with silo-level clouds as well as with yet undefined DISA brokerage mission, the strategy is unlikely to achieve what is expected.

However, there are approaches that have already emerged how to set up a very large enterprise to operate with multiple cloud solutions.  In blogs that will follow, the operations