Saturday, April 9, 2011

How to Fit DoD into the Cloud Environment?

It is now an OMB policy that DoD should start migrating into an architecture that is based on cloud-like concepts. * There are leaders who have suggested that transporting DoD applications into a Google-like environment would solve persistent problems with security, interoperability and cost.

Before anyone can subscribe to a cloud-centered solution it may be useful to examine the current state of DoD applications. What we have now is fractured and often broken, non-standard, custom-fitted and without a shared data environment.

To move thousands of such systems into a well-ordered Platform-as-a-Service or Infrastructure-as-a-Service will require enormous expenditures. It will require restructuring how systems are designed, how they can run and in what data centers they can operate.

To gain a better understanding, in a constrained budgetary environment, it may be useful to examine what are the “as-is” conditions of the existing systems before making “to-be” projections. Most importantly any plans need to be supported by funding commitments and a realistic schedule.

The OSD Deputy Chief Management Officer has defined the scope of work that needs to be done. ** It includes a list of 2,319 systems costing $23.6 billion, which represents 69% of the total DoD IT spending in FY11. *** Of the 2,319 listed systems 1,165 systems are obsolete (e.g. "legacy" or "interim"). 1,154 were labeled as systems that will survive (e.g. "core").

The following statistic shows the number of DoD business systems plotted against their respective FY11 budgets: ****

94% of the DoD 2.319 systems have budgets of less than a $20 million, with most operating with budgets of less that $1 million in FY11.

Most of these applications are categorized either as “legacy” systems to be phased out, or as “interim” systems, which have a limited life expectancy. There are 1,165 such systems, or 55% of the DoD total, which are obsolete and require ultimate replacement.

How DoD systems are distributed is illustrated in the following table. Each of these systems will contain numerous applications:

The above table shows that about half of all systems are in Financial Management and in Human Resources areas. The Business Transformation Agency, now discontinued, had spent six years attempting to unify these applications, but a large number remain in place nevertheless.  Numerous independent Agencies also control 613 systems systems. Such diversification into different organizations will make any consolidations very difficult.

The current proposals to ultimately merge 1,165 obsolete systems into 1,154 “core” systems may not be executable. The problem lies not with the proliferation of systems (each supporting many applications) but in the contractual arrangements for small systems, each possessing its unique infrastructure. Most of the current 2,319 systems have been built one contract at a time over a period of decades. Limitations on funding have worked out so that most of these systems ended up will  unique configurations of operating systems, diverse application codes, incompatible communications and data bases that are not interoperable. With over 76% of software maintenance and upgrade in the hands of contractors incompatibilities were then a natural outcome. Meanwhile, DoD's high turnover in managerial oversight resulted in a shift of architectural control over system design to contractors.

There is no reason why the Army should not have 252 human resources systems and even more applications. There is no reason why the Navy should not have 92 financial systems with hundreds of diverse applications to manage its affairs. The issue is not the number of reporting formats - that must server diverse user needs - but the costs of funding completely separate systems to deliver such variety.

Over 60% of the current costs for Operations and Maintenance are consumed in supporting hundreds and possibly thousands of separate communications, data management and security infrastructures. Instead of such great multiplicity of infrastructures, we need only a few shared infrastructures that  should be the support all  of DoD's systems.

If DoD can acquire a Platform-as-a-Service or an Infrastructure-as-a-Service capability, the Army, Navy, Air Force and Agencies will be able to generate and test quickly many inexpensive (and quickly adaptable) applications to be placed on top of a few shared infrastructures. Such an arrangement would results in much cheaper applications.

DoD should not proceed with the re-writing of existing systems as has been proposed. DoD should not proceed with the consolidation of existing systems into a smaller number of surviving systems. Consolidations are slow, expensive and take a very long time,

Instead, DoD should re-direct its efforts to completely separate its infrastructure and data management from applications. The new direction should be: thousands of rapidly adaptable applications, but only a few secure cloud infrastructures for support.

* U.S. Chief Information Officer, Federal Cloud Computing Strategy, February 8, 2011
** (Master List of Systems)
*** DoD IT spending excludes the costs of the military and civilian IT workforce.
**** There are only eight projects reported with budgets greater than $500 million.


  1. Very true. If Google's cloud offering for govt is anything like the Google app engine it would require virtually all legacy DoD apps to be completely rewritten to work with it. The reason being for this is that google currently doesn't support a relational database model which almost all current apps use.

    However, services like Amazon's EC2 which gives access to an entire OS in the cloud would be a much better fit for legacy applications. If you setup a virtual OS in the same way that the OS is setup on the servers the legacy apps are currently running on it would require very minimal rewrite of legacy applications to get them into the cloud environment.

    Not that it would be painless as anybody who has migrated servers before knows it would still take a large amount of work and a lot of things can go wrong in the switch over. However if you look at the current costs associated with DoD hosting(even their current "cloud" offerings) as opposed to the costs of commercial hosting you'll pretty quickly see why there's a push towards services like the ones that google and amazon provides.

  2. The key point here is that we should not migrate nor consolidate legacy DoD applications to a new architecture -- Cloud in this case. That makes good sense, and DoD has had challenges doing such in the past (NECC is a good example).

    But, we should consider opportunities between fullscale consolidation/rearchitecture and IaaS/Paas. This middle ground is the Cloud hosting of those select applications where DoD has standardized on an application. It matters not whether this standardization was intentional or not. Defacto standardization is fine. Some examples of this might include: sharepoint, email back end, Directory Services, & map servers. Some have called these type of applications "core services" or "common applicatinos." Some might argue whether they are SaaS or PaaS, but whatever their label, they provide another set of Cloud opportunities for DoD.


For comments please e-mail