An Excursion into Government Legacy IT Systems - VII

7.     Requirements

This chapter is devoted to explaining the types of requirements and constraints which will be levied on the systems.

7.1     Functional Requirements

Functional requirements describe what the systems will do. They start with activities, what the users will do. The baseline for functional requirements will come, as expected, from the legacy systems. These steps apply to defining activities:

·         Define activities in close cooperation agency-system users, because they know their jobs, and (where applicable) the public;

·         Cover legacy activities because the new system cannot be less capable than the legacy system;

·         Add new activities as needed; and

·         Assure upward compatibility (continued support) of activities.

Functions are what systems do to carry out activities. For example, to implement an activity such as display employee record, a system might have to verify an access permission, locate the employee object, verify identifying data, retrieve the record in question, and package the data for display to the user. In general,

·         Activities will request functions across the Layer/Layer interface,

·         Functions will build (within a layer) on Objects, and

·         The system will cover legacy functions (immediately through interfaces).

7.2     System Quality Requirements

Quality requirements establish how well the system must perform activities and functions. Examples of quality requirements are

·         Speed of operation / latency

·         System availability

·         System scalability

·         Data and design consistency across agencies

·         Ease of system use to facilitate training, reduce operator errors, and upgrade user productivity.

·         Security, which includes object privacy, encryption, authorization, authentication, and access permissions,

·         Integrity, which may be transaction-based (as for financial systems) and

·         System and data survivability, enabled by redundancy

7.3     Constraints

In general, constraints have important but indirect influence on system development and operation. Constraints will include

·         Costs

·         Schedules

·         Physical aspects such as size, weight, power use, etc.

·         Documentation and model standards and

·         On-line help

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.

An Excursion into Government Legacy IT Systems - V

5.     Goal State

GS-21 will almost certainly be characterized by a layered architecture, standardized interfaces, stable data models, clear system-engineering (SE) guidelines, and an Integration, Test, and Evaluation (ITE) Facility.

5.1     Layered architecture

The following principles and motivations of layered architectures apply to GS-21:

·         They enable transition through incremental updates (one layer at a time);

·         The International Standards Organization (ISO) Open Systems Integration (OSI) model has been around a long time – we know how to do this;

·         Low-level design decisions are hidden, reducing risk; and

·         Layering enables concurrent improvements and free-market updates.

o   The Internet serves as a prime example.

5.2     Interfaces

·         Stable inter-layer interfaces enable modularity, reducing technical risk;

·         Standardized, stable User Interface (UIs) minimize re-training and clarify functional requirements.

5.3     Data Models

Standardized data models, which in many cases reflect the formats of data regarding the public, enable

·         Single data entry across systems (where applicable)

·         A Person class, controlled by a single agency, has transformation potential

·         Cross checking (for validation, authentication, etc.)

5.4     SE Guidelines

·         Approved, object-oriented development languages

·         Approved DBMS languages

·         Documentation standards

5.5     Integration, Test, Evaluation (ITE) Facility

·         Integrate and test GS-21 Mod 0 using the ITE Facility

·         Immune to external hacking (disconnections)

·         Protected from internal threats (sample data only)

·         Requirements and interface standards are open

o   To promote innovate tech upgrades

·         Headquartered in mid-country, Denver? and remotely accessible.