An Excursion into Government Legacy IT Systems - VI

6.     Transition between Current State and Goal State

While incremental and spiral development will help us maintain forward progress and avoid major technical failures and cost over-runs, the transition step, where GS-21 implementation gets serious, presents two clear risks and two related opportunities for innovation.

6.1     Step 1: interface new User Interfaces (UIs) to legacy systems

We assume that each agency legacy IT system is currently operating according to specification. The first implementation step is to break the direct connection between user and legacy system and reconnect the user through a newly designed UI. These are the steps and associated risks and opportunities:

·         Design new UIs that allow users to specify all current activities;

·         Develop Interfaces to legacy code

o   Risk: This is a cost and schedule risk – although the technical risk is low, since this is no more and no less than a programming task, the time required to build and validate the interface will depend on the design and modularity of the legacy system.

o   Precedent: PA Charles de Gaulle (France); SENIT 8 combat-system designers, to re-use legacy shipboard systems, built interfaces from the new shipboard network to each legacy system. This allowed them to get SENIT 8 operational on schedule and within budget and to delay legacy-equipment upgrades until new hardware became available.

o   Opportunity: Each time a new interface is developed, the risk will decline. Over time, innovation will engage and OAI will be able develop a “best practice” for interface development and test. At that point, a critical piece of IT modernization will be in place.

·         Connect the new UIs to legacy-system code to build GS-21 Mod 0. This first step enables a test of UI viability while preserving vital legacy system operational capability.

6.2     Step 2: Implement new lower layers under interface standards

Once UIs have been constructed and joined to the legacy system through an interface (which will  remain in place as long as needed), implementation of new software may begin. That software, will respond to the requirements described in the next chapter of this white paper. Functional requirements are expected to incorporate, at a minimum, all legacy system functions. The plan is to implement, step-by-step, all user activities using modern programming languages. This process will be open to vendors – the requirements, standards, and guidelines will be made public and vendors will be free to offer solutions within the architecture layers.

In this step as well, OAI will face risks, but there are precedents and opportunities.

·         Risk: In principle, open competition for the best technical implementations will lead to high-quality solutions; in practice, OAI will face the challenge of constructing a process which attracts solutions from private vendors. The ITE Facility will be made available to vendors as part of this process.

·         Precedent 1: One precedent for innovating within layer boundaries is that of “Code-Division Multiple Access” (CDMA), a scheme for obtaining network access within the Data-Link Layer of the 7-layer OSI network architecture. CDMA quickly overtook earlier Time and Frequency Division MA protocols and was a factor in the success of Qualcomm, Inc. The inter-layer interfaces, still in place today, were resilient enough to accommodate the upgrade.

·         Precedent 2: Another precedent for innovating within layer boundaries is illustrated by the Microsoft Office Suite, built on both the Microsoft DOS and Windows operating systems. The Word, PowerPoint, Excel, Access, and Outlook software are within the application layer of the computing model and have seen numerous improvements over the years while remaining, for the most part, upward compatible.

·         Opportunity: Addressing initial system implementations will reveal an opportunity which standardization enables, namely re-use.

o   Some of the programming classes, such as citizen (in object-oriented programming, there may be many citizens, instantiations of the class citizen), need only be defined once for all systems. While it is true that every agency does not need all data about any one citizen, the relevant data can be stored (and protected) in a single place for authorized access by any system.

o   Other classes, such as account, may be defined in a standardized way as descendants from “parent” classes. This means that as development progresses from early to later adopters, it will become more rapid and less costly. This re-use curve should encourage vendors to join the development process.

6.3     Taking tips from Internet planners on governance

There is much to be learned about governance by observing the success of the Internet. The following from Wikipedia will be important background for OAI.

·         Internet Architecture Board (IAB): Responsible for defining the overall architecture of the Internet, providing guidance and broad direction to the IETF.

·         Internet Engineering Task Force (IETF): The protocol engineering and development arm of the Internet.

·         Internet Engineering Steering Group (IESG): Responsible for technical management of IETF activities and the Internet standards process.

6.4     Training

While user training is critical to the success of any system, it is expected that implementation will fall to the agencies using training processes already in place.