Federal Government Needs a Federal Enterprise Architecture

Given the current status where both policy as well as implementation is lacking we have two fundamental questions that need to be answered now: First, is it still possible to complete the originally planned FEA to guide DoD systems developments henceforth?

Second, is it possible to re-align the positions of the DoD CIOs for acquiring the budgetary and organizational controls that would allow the management of IT spending?
The answer to both of the above questions is negative. The assumptions that have been attempted to apply for fifteen years do not work any more. Fortunately, the rapid development in the delivery of information technologies as a shared service – cloud computing – has now opened new options for DoD to start redirecting its IT policies.

What is now needed is primarily a FEA2, a DoD architecture for the placement of Platforms-as-a-Service (PaaS) as the core around which to reorganize the conduct of IT.
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.
FEA2 would be developed not by staff that is remote from where PaaS services are delivered.  Instead FEA2 staffs would be embedded where PaaS is executed.

FEA2 would be realized as an evolutionary process, not as a pre-set 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 Admiral Rickover, 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 ten years. The management of programs should be in the hands of senior long-term officers, not with rapid rotation appointees. With IT 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 gradually stripped 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 DoD’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 DoD 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 PaaS what presently are the most costly information assurance functions.

Excluded from PaaS would be the application codes and the applications related data. Meta Data directories would be managed as an enterprise asset to assure interoperability. Separating PaaS services from the applications would be controlled by tightly defined standard interface protocols.

FEA2 would largely simplify how DoD manages its systems and how it can reduce costs. Instead of thousands of contractor-designed and contractor-maintained infrastructures that now account for an excessive 57% if all costs, DoD 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 DoD Private or Public Clouds, though Infrastructure-as-a-Service (IaaS) would be always present as a transition offering on the path towards PaaS.

FEA2 will depend on a strict adherence to open standards in order to assure interoperability across PaaS clouds.  DoD memorandum of October 16, 2009 offers guidance a preferred use of open source standards in order 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. DoD cannot allow each contractor to define their own PaaS.  DoD cannot allow the operation of a hotel where guests can check in but can never check out.

Existing PaaS solutions offered by vendors such as Amazon and Microsoft Azure offer services that operate in this manner. To assure competitiveness only operations based on open source standards can be allowed.  An independent test of open source interoperability would verify that applications can 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. DoD customers should be able to relocate any application from any one PaaS to another with only minimal transfer expenses.

The technical aspects of a PaaS can be best 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.

DoD 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 IT coding “stacks”. Such overlays will act as intermediaries between what belongs to the customer’s, such as the Army, Navy, Air Force 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 are eventually 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 can relocate to take advantage of competitive offerings from different PaaS offerings.

To prevent PaaS contractors from offering cloud solutions that capture customers by means of proprietary runtime and middleware solutions it is necessary to control the interoperability across several PaaS services as well as across any interim IaaS solution. That must be done by DoD policy that will assure that interfaces depend on open source solutions that can be verified for interoperability.

Achieving PaaS standards only through the DoD policy is insufficient. The PaaS technologies are global whereas the reach of DoD is limited by spending less than 1.5% of the global IT costs.  The ability of customers to migrate from one PaaS vendor to another PaaS vendor must be preserved by an OSD that works with commercial firms to adopt standards that prevent lock-ins by large prime contractors that could prevent smaller firms from offering PaaS services.

The insertion of a limited number of PaaS services into DoD will result in large cost reductions. Contractors will be shifting to proprietary PaaS services to gain larger profit margins unless DoD 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.  There are hundreds of cloud services that operate in a proprietary manner and DISA is now considering such moves. OSD policy must see to it that all migration moves must 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 must therefore offer the following:
1. 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 how an application was coded it should remain transportable to any DoD approved PaaS cloud, anywhere.
2. The isolation of the customer’s applications from the PaaS software and hardware is necessary to permit the retention of the DoD’s intellectual property rights, regardless of cases where DoD may choose to host some of its applications on a public cloud.
3. Certification by the cloud provided 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.
4. Assurance that the customers’ application code will not be altered when hosted in the PaaS cloud, regardless of the software framework used the build it.
Any DoD plans to migrate systems into a PaaS environment will henceforth 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 already available aims to allow developers to remove the cost and complexity of configuring an infrastructure and for a runtime environment that allows developers to focus on the application logic. This streamlines the development, delivery and operations of applications, enhances the ability of developers to deploy, run and scale applications into the PaaS environment.

The objective of FEA2 is to get an application deployed without becoming engaged in set-ups, such as server provisioning, specifying database parameters, inserting middleware and then testing that it’s all ready for operations after coordinating with the data center operating personnel.

SUMMARY
A new Federal Enterprise Architecture should be based on a separation of the underlying infrastructure (PaaS) and applications. This call for a complete reorganization of the way how the Federal Government proceeds with building the systems that are needed.