Managing Defense Department information technology is going to require scrapping current architecture and acquisition processes for a new approach
One mandate of the Clinger-Cohen Act of 1996 was creation of the Information Technology Architecture. In subsequent 1999 guidance, the Federal Chief Information Officers Council defined the Federal Enterprise Architecture as the process for developing, maintaining and facilitating the implementation of integrated systems.
Chief information architects then were appointed at the federal and Defense Department levels. However, as of June 2011, the Government Accountability Office (GAO) reports that the enterprise architecture methodology was not deployed. Between 2001 and 2005, the GAO reported, the Defense Department spent hundreds of millions of dollars on an enterprise architecture development that was of limited value. None of the three military departments so far have demonstrated that they have made commitments to deploy an architecture needed to manage the development, maintenance and implementation of systems.
Senior defense information technology executives have stated that the development of an architecture methodology has been pushed back due to budget limitations. As yet, no time frames have been established for producing a Federal Enterprise Architecture (FEA). There is no specific date when the enterprise architecture would be delivered. The current focus is on other resource-intensive commitments.
Nevertheless, the use of well-defined enterprise architectures remains nowadays an attribute of managing information technology in successful commercial firms. A centrally directed architecture continues as the basis for system integration and for delivering lower information technology costs. In spite of the significant potential benefits, the enterprise architecture has not guided Defense Department systems over the past 15 years.
While the Defense Department was promoting departmental and agencywide enterprise concepts, actual implementation of integration was missing except in isolated cases. Consequently the department ended up lacking a coherent blueprint for creating a technology environment that would be interoperable, economically efficient and easily accessible for innovation. The absence of a working architecture has prevented the Defense Department from making progress at the same rate as leading commercial firms.
The absence of a guiding Defense Department architecture also opened the floodgates to excessive project fragmentation, to technology incompatibilities and to operations that were contract-specific rather than enterprise-integrating. That increased not only the costs of maintenance and of modernization upgrades, but also put the brakes on the ability to innovate, which would meet the rapidly rising demands to achieve information superiority. If there was innovation, it had to take place as stand-alone new projects and not as an enhancement to systems that could be improved at a lesser cost.
The Clinger-Cohen Act also passed to the chief information officers (CIOs) the responsibility for managing all information technology spending. That did not take place as originally legislated.
Currently, CIOs cannot be held accountable for the contracting decisions that are made by acquisition officers who use regulations found on 2,017 pages printed in small type. The management of information technology, as of March 2011, is split into 2,258 business systems with only spotty direct-component CIO oversight. Meanwhile, the ability of the Defense Department CIO to control rising costs continues to be limited.
There are also more than 1,000 national security systems that are not listed in the Defense Department Information Technology Portfolio Repository (DITPR). Such projects include intelligence systems, military command and control networks, and equipment included as an integral part of weapons. Whereas in the Cold War years, when national security systems could be set up as stand-alone applications, modern warfare conditions now require a real-time interoperability between national security systems and selected business applications such as logistics.
As the consequence of having no architecture as well as weak CIO control over information technology costs, the Defense Department ended up with largely isolated enclaves — silos — of projects.
Information technology projects now are managed as separate contracts. Applications are not interoperable across the department because they cannot share enterprisewide data. Information technology projects are run in more than 700 data centers as well as in an untold number of special-purpose servers that often have data center capabilities.
Such outcomes originally were not envisioned in 1996. The flawed outcomes, predicted in 1995 Senate hearings, pointed to the inadequacies of Clinger-Cohen to meet post-Cold War needs. The 1996 legislation did not offer changes in the organizational structure for managing information technology. It did not alter the Defense Department component-entrenched budgeting practices. It also did not set out to deliver a shared information technology infrastructure that would compare favorably with best commercial practices. Security was not as yet on the agenda. Rising Defense Department requirements then would be met with rapidly rising spending for information technology.
Given the current status where both policy and implementation are lacking, two fundamental questions must be answered immediately. First, is it still possible to complete the originally planned FEA to guide Defense Department systems development? Second, is it possible to realign the positions of the Defense Department CIOs for acquiring the budgetary and organizational controls that would allow the management of information technology spending?
The answer to both questions is negative. The assumptions that have been applied for 15 years do not work anymore. Fortunately, the rapid development in the delivery of information technologies as a shared service — cloud computing — now has opened new options for the Defense Department to start redirecting its information technology policies. What is needed now is a FEA2, an architecture for the placement of platform-as-a-service (PaaS) as the core around which to reorganize the conduct of information technology.
Instead of FEA1 trying to direct how thousands of separate projects would be designed and operated, FEA2 would define how to set up only a handful of PaaS cloud services. Staff located in remote locations away from where PaaS services are delivered would not develop FEA2. Instead, FEA2 staffs would be embedded where PaaS is executed.
FEA2 would be realized as an evolutionary process, not as a preset blueprint. The management of projects would not be split into stand-alone engineering, development, programming and operation phases assigned sequentially to separate organizations. Instead, in the spirit of the late Adm. Hyman Rickover, USN, programs would be managed as unified and tightly coupled ventures. FEA2 would concentrate on quarter-by-quarter migration to guide a rapid progression from the current legacy code to eventual arrival in the PaaS environment.
The planning horizon for FEA2 should be at least 10 years. Management of programs should be in the hands of senior, long-term officers, not rapid-rotation appointees. With information technology now classified as a weapon rather than as an auxiliary function, all senior appointments should qualify as information systems specialists.
FEA2 would provide guidance on how applications would be stripped gradually from their underlying infrastructures. The objective would be to convert each application into a form that can be delivered as a service on demand on any of the Defense Department's standard PaaS offerings. New applications would be placed on top of a standard PaaS instead of the existing proliferation of infrastructures.
FEA2 would define PaaS as addressing the following standard services to be used as shared capabilities: networking, storage management, management of servers, virtualization of the hardware, maintenance of operating systems, implementation of security assurance, middleware for managing the transition of legacy code and the design of run-time interfaces.
Security services, which will become the most critical part of all Defense Department systems, will be embedded primarily inside each PaaS and then updated in a relatively small number of software assets. Leaving security features — such as access authentication — within applications will make it possible to consolidate within a small number of PaaSs what presently are the most costly information assurance functions.
Excluded from PaaS would be the application codes and the applications-related data. Metadata directories would be managed as an enterprise asset to assure interoperability. The separation of PaaS services from the applications would be controlled by tightly defined standard interface protocols.
FEA2 largely would simplify how the Defense Department manages its systems and how it can reduce costs. Instead of thousands of contractor-designed and -maintained infrastructures that now account for an excessive 57 percent of all costs, the department will concentrate on maintaining only a handful of PaaS environments, probably at least one PaaS for each military service and for each agency. PaaS services would be available in the form of private or public clouds, though infrastructure-as-a-service (IaaS) always would be present as a transition offering on the path toward PaaS.
FEA2 will depend on a strict adherence to open standards to assure interoperability across PaaS clouds. A Defense Department memorandum of October 16, 2009, recommends a preferred use of open-source standards to allow developers to inspect, evaluate and modify the software based on their own needs, as well as to avoid the risk of contractor lock-in. The department cannot allow each contractor to define its own PaaS. Nor can it allow the operation of a hotel where guests can check in but never check out. Existing PaaS solutions offered by vendors such as Amazon and Microsoft Azure provide services that operate in this manner. To ensure competitiveness, only operations based on open-source standards can be allowed. An independent test of open-source interoperability would verify that applications could be relocated from one PaaS to another.
The roles of the CIOs and the acquisition personnel would be enlarged to oversee the rates charged by PaaS services. To assure competitiveness and for comparability of charges, the transaction pricing structure for each service would have to be uniform for every PaaS provider. The ultimate test of FEA2 will be cross-platform portability. Defense Department customers should be able to relocate any application from any one PaaS to another with only minimal transfer expenses.
The technical aspects of PaaS can be described as a method that allows a customer's unique data and applications to be placed on top of a defined computing "stack." The PaaS stack takes care of every infrastructure service. The customer can be left to worry only about applications and data.
The Defense Department will have some diversity in PaaS offerings because various components will make progress at different speeds. This will require the placement of a software overlay on top of the existing information technology coding stacks. Such overlays will act as intermediaries between what belongs to the customers — the services and agencies — and what belongs to the PaaS during the progression from legacy systems to PaaS. The placement of an intermediation software layer between the PaaS and the applications will allow for the diversity of applications during the long migration it will take to reach the ultimate goal. It may take a long time for such migration to take place as legacy systems eventually are replaced with PaaS-compatible solutions.
The PaaS arrangement makes it necessary for applications and data to be constructed using standard development frameworks. Such standardization is necessary to enable applications to relocate easily from one PaaS cloud to another, whether these clouds are private or public. With such standardization applications and data, users can relocate to take advantage of competitive offerings from different PaaS vendors.
To prevent PaaS contractors from offering cloud solutions that capture customers by means of proprietary run time and middleware solutions, it is necessary to control the interoperability across several PaaS services as well as across any interim IaaS solution. To accomplish this goal, the Defense Department must establish a policy to ensure that interfaces depend on open-source solutions that can be verified for interoperability.
Achieving PaaS standards only through policy is insufficient. The PaaS technologies are global, whereas the reach of the Defense Department is limited by spending less than 1.5 percent of the global information technology costs. The ability of customers to migrate from one PaaS vendor to another PaaS vendor must be preserved. This can be assured if the department works with commercial firms to adopt standards that prevent lock-ins by large prime contractors — the type of lock-ins that could prevent smaller firms from offering PaaS services.
The insertion of a limited number of PaaS services into the Defense Department will result in large cost reductions. Contractors will be shifting to proprietary PaaS services to gain larger profit margins unless the department sees to it that competition can prevail.
Transferring applications to a cloud offers enormous benefits. It also can be a trap. After placing an application on IaaS to take advantage of virtualization of servers, such a move can be wedged into a unique software environment. For all practical purposes applications cease to be transportable from any one IaaS to another IaaS and certainly not to PaaS.
Hundreds of cloud services already operate in a proprietary manner, and the Defense Information Systems Agency is now considering such moves. Defense Department policy must require that all migration moves fit the ultimate objective of operating as a PaaS. IaaS solutions are useful in offering raw computing power but may not be sufficiently flexible to enable redeployment when conditions change.
PaaS services therefore must offer the following features. First, the interface between customer applications and the PaaS must be in the form of open-source middleware, which complies with approved IEEE standards or prevailing industry best practices. Standard open-source middleware must allow any application to run on any vendors' PaaS cloud. Regardless of how an application was coded, it should remain transportable to any Defense Department-approved PaaS cloud, anywhere.
Second, the isolation of the customer's applications from the PaaS software and hardware is necessary to permit the retention of the Defense Department's intellectual property rights. This must apply even if the department chooses to host some of its applications on a public cloud.
Third, the cloud provider must certify that applications will remain portable regardless of configuration changes made within its PaaS. This includes assurances that applications will retain the capacity for fail-over hosting provided by another PaaS vendor.
Finally, there must be assurances that the customers' application code will not be altered when hosted in the PaaS cloud, regardless of the software framework used to build it.
Any Defense Department plans to migrate systems into a PaaS environment henceforth will have to consider the ready availability of off-the-shelf software that will make the migration to PaaS feasible at an accelerated pace.
Commercial software that is already available aims to allow developers to remove the cost and complexity of configuring an infrastructure and for a run time environment that allows developers to focus on the application logic. This streamlines the development, delivery and operations of applications. It also enhances the ability of developers to deploy, run and scale applications into the PaaS environment.
The objective of FEA2 is to deploy an application without becoming engaged in set-ups, such as server provisioning, specifying database parameters, inserting middleware and then testing that it is all ready for operations after coordinating with the data center operating personnel.
With a redirection of Defense Department information technology to a new architecture and with focusing on PaaS services, the department can overcome its budget limitations while freeing funds for attaining information superiority.
The final installment in Paul A. Strassmann's series on defense information technology, in the November issue, will examine how to transition to platform-as-a-service computing.