What is the Age of DoD Silos?

Last month we reported that there were 2,904 separately funded FY12 IT budgets. Many of these would be set up to operate their own and incompatible networking, storage, server, operating systems, middleware or control commands.

Silos have a long history in DoD. They often stretch for decades. During a long development time they create distinctive formats that keep reducing the interoperability with other solutions. The enclosed tabulation of some long-term projects accounts for 18% of total IT spending, This illustrates up to 35 years during which program managers and contractors keep developing silo-specific features.  

 Over a decade any IT investment will lock in unique codes and interface formats. Programs will be continually re-written for updating information technologies. To maintain connections will requires continuous modification of the supporting infrastructures of two or more silos. Format translations and compatibility bridges for files will have to be constructed and maintained. That adds large amounts of support costs and increases the problems of maintaining security. Contractors will be kept permanently busy just keeping the various reporting arrangements consistent.

DoD cannot afford supporting the continuous stream of maintenance costs associated with decades long software development cycles. As an immediate remedy it is now in a position to acquire software that will accelerate the adoption Information-as-an-Infrastructure (IaaS) solutions. There are now hundreds of cloud services firms that offer such technologies, though they range from proprietary (such as Amazon, Microsoft and Google) to open source (such as VMare) solutions.

Instead of keeping up separate infrastructures for each silo, DoD can start migrating to a much smaller number of infrastructures. This can be done by evolutionary migration. Each legacy silo applications can be “encapsulated” into a virtual package so that it can now run on its own virtual computer.

Such virtual computers can take advantage of pools of shared servers, of disk memory and of a shared communications environment. Capacity utilization will then increase. Security policies will be enforceable across an entire range of virtual computers. The conversion to IaaS services will become one of the principal means for delivering the projected reductions in the number of data centers that is presently receiving widespread attention.

Though a reduction in the number of data centers will result in cuts in expenses for brick and mortar facilities as well as for managerial overhead, the major gains will come from the pooling of processing capacity for better utilization and for sharing of disk memories that will offer reductions in the required disk space. Hard to quantify gains will come, however, from the consolidation of security services. Formerly costly security enforcement means, such as expert manpower and specialized security appliances will now be available for more consistent control of security measures.

Instead of elongating project schedules for individual silos, DoD should be able evolve in very short order to a much smaller number of enterprise infrastructures, each subject to central controls for assuring data and communications interoperability. Existing silo budgets for separate infrastructures will have to curtail further spending on infrastructure to fund a much smaller number of pooled enterprise solutions. Such migration could start in the next fiscal year by shifting processing of parts of some applications from legacy silos to a limited number of commercial public clouds from where they would support as “hybrid cloud” solutions without users seeing much of a difference. After sufficient experience is gained, parts of such solutions could then relocate into DoD owned and operated private clouds.

DoD will have to find a method for extracting funds from increasingly obsolete legacy programs to Joint enterprise projects that offer a shared infrastructure. Such a move will allow DoD components to concentrate on applications, but without their prohibitively expensive custom-made infrastructures.

The original 1992 intent for creating DISA was to make it a shared provider of enterprise services. The fiscal mechanism for delivering such services has been long available as working capital funds that can be used to charge individual users not as allocations of fixed costs, but as a fee for services used. Transaction-based pricing will have to be instituted in this new environment so that components can make competitive comparisons as they shifts cloud workloads between cloud services in a hybrid environment.