Modular Development is Not the Answer

The “25 Point Implementation Plan to Reform Federal Information Technology Management” issued by the U.S. Chief Information Officer on December 9, 2010 states that “… OMB found that many IT projects are scheduled to produce the first deliverable years after work begins, in some cases up to six years later. In six years, technology will change, project sponsors will change, and, most importantly, program needs will change. Programs designed to deliver initial functionality after several years of planning are inevitably doomed.”

The House Armed Service Committee has further elaborated on the current situation in DoD:  *
1. Only 16% of IT programs are completed on time and on budget.
2. 31% are canceled before completion.
3. The remaining 53% are late and over budget, with the typical cost growth exceeding the original budget more than 89%.
4. Of the IT programs that are completed, the final product contains only 61% of the originally specified features.

To deal with this situation the Office of the Federal CIO advocates the adoption of a modular approach to systems development, defined as “… delivery in shorter time frames … based on releases of high level requirements and then refined through an iterative process.” This would require deploying systems in release cycles no longer than six to twelve months, with initial deployment to end users no later than 18 months after the program is authorized.

The problem with such guidance is the disregard of typical time-lines for information technology projects. Constructing the Metadata for DoD databases is continuous. It is never finished and requires continuous investments that forever.

The time to develop a communications infrastructure for DoD takes decades. It may then take more than several decades to migrate into a new communications environment.

DoD has core business applications, such as in Finance or Human resources that remain in place with little change for many years.

Tactical applications have an extremely short life, which may be only a few hours while a mission lasts.

Attempting to solve DoD’s development problems with rapid paced modular development does not recognize that enterprises need to solve some long-term problems before short-term solutions can be implemented.

The following diagram illustrates the differences in the timing of programs:

Global:
Global standards take a very long time to evolve. DoD must select only a minimum of technical standards and enforce them across all applications. Emphasis placed on assuring interoperability with the least migration costs. Proprietary solutions must be avoided.

Enterprise:
Enterprise standards must be followed. Control over databases, over shared communications, security and survivability should never be included as an integral part of a development program. Enterprise directions should hold steady for decades. A DoD cloud is clearly a shared enterprise program, not a functional investment.

Process:
Functional processes, especially in business applications, should not be managed as modular releases, but planned and funded as multi-year programs. Core features of functional processes should be extracted by Services and Agencies as “plug-in” add on.

Business:
Businesses should be built as applications that have only unique and specific uses. There should not be multiple logistics, personnel or financial systems within a Service or an Agency.

Application:
Application Development and Maintenance can be decentralized to meet local needs.  Standard modular code should be used to compose programs that take advantage of an in-place infrastructure, thus minimizing the amount of investment that is required to deliver results. It is only here that the six to twelve month modular development schedule would apply.

Local:
Local applications should be composed from parts available from the Enterprise, Functional and Business levels. Depending on the capabilities of the DoD networks, local applications should be assembled in a very short time, often in hours.

Personal:
Personal applications should be totally separated from the DoD business to protect privacy. They should be subject to only records management controls.

SUMMARY
DoD projects that last more than six year, or be terminated only to be restarted again reflect the prevailing program management practices. What we have are programs that are attempting to develop their own unique infrastructure, with little dependence on Enterprise or Process services. Such an approach is expensive and time consuming. This situation is compounded by a limited enforcement of global standards.

DoD programs should not be cut into pieces that are launched incrementally. Programs should be fitted into an overall architecture in which complexity is solved by means of programs that have multi-year stability. That would leave short-term execution to depend on pre-fabricated modules that depend on the simplicity of using only minimal amounts of code while most of the code is extracted from the long lasting shared infrastructure.

* www.esi.mil/Uploads/HASCPanelReportInterim030410%5B1%5D.pdf