An Excursion into Government Legacy IT Systems - II

2.     Stakeholders

2.1     OAI

We stipulate that OAI will play the role of smart buyer of IT systems for the government. To obtain cost-effective results, OAI will need to understand agency requirements, vendor products and services, and program constraints (such as cost and schedule). In the role of smart buyer, OAI will perform these functions:

·         set GS-21 requirements in close cooperation with the agencies;

·         request contractor proposals for system engineering (SE) development;

·         request vendor solutions within SE guidelines; and

·         conduct integration, test, evaluation, and acceptance of proposed solutions.

Critical point: since a variety of risks – from discontinuity of service to perceived favoritism – would be associated with turning over responsibility for Government IT to a private company, short of revoking its own charter, OAI does not have the option of refusing the smart buyer role.

2.2     Integrated Process Team (IPT)

IPTs are widely used throughout industry and government because they raise the probability that all stakeholders have input to project decisions. This lowers the risk of omitting critical factors from consideration. The IPT will be under OAI supervision, but the full value of the IPT can only be realized if OAI is responsive to IPT guidance. That guidance must reflect the full range of stakeholder concerns.

2.3     The initial customers – government agencies

OAI will work directly with selected government agencies, and agency leadership, to set program goals, schedules, and cost estimates. A common source of resistance to a new system lies with the workers who must use it. However, when those workers are invited to apply their experience to the benefit of the system design, they are much more likely to become system advocates. Therefore, OAI will work closely with internal agency-system users to get their buy-in and have the “wind at their backs.” These are the natural roles for agency users in conjunction with OAI:

·         Define system requirements and User Interfaces (UIs);

·         Conduct initial (Alpha) testing and recommend refinement;

·         Submit trouble tickets as appropriate;

·         Participate in testing, evaluating, refining, and accepting the system;

·         Periodically review system performance and recommend changes; and

·         Train users and user-trainers;

2.4     The ultimate customers – the public

The systems of certain agencies, such as the VA and OPM, will enable public access; other agencies, such as DHS, may not. For the former, it will be important to assess the user experience. Public satisfaction may or may not be a driving force, but public dissatisfaction can destroy morale and progress. Therefore, the OAI must ensure that sufficient time and attention are devoted to introducing and monitoring system access by the public.

2.5     System Engineering and Technical Assistance (SETA) Contractors

While OAI is a government agency, many OAI activities will require specialized contractor skills. To avoid potential conflict of interest, SETA contractors who directly support OAI and the GS-21 program must be “fire-walled” from developers and vendors; moreover, they may not hold OAI management positions.

Since innovation is part of OAI, it is recommended that OAI use innovation in contracting. For example, rather than issuing Requests For Proposals (RFPs) which focus on price (low bid), OAI should strongly consider issuing RFPs which solicit innovative approaches to tasks which OAI has already priced according to their budget. This approach would have several benefits:

·         OAI would quickly learn to price tasks realistically;

·         Proposal emphasis would be on quality and job performance;

·         Proposers would be encouraged to organize personnel based on ability to do the job rather than on cost;

·         The fixed-price contract would not generate cost over-runs;

·         Companies would have strong incentives to improve cost-effectiveness since they would retain any savings as profit.

2.6     Vendors / Private Companies

The heavy lifting of GS-21 development will fall on private companies. They will be invited to participate in several different ways:

·         Participate in the definition of the GS-21 architecture and standards;

·         Develop a GS-21 integration, test, and evaluation (ITE) Facility; and

·         Offer artifact (hardware and software) to implement GS-21 requirements within architecture and standards guidelines;

·         Integrate, test, and evaluate prototypes in the GS-21 ITE Facility.

An Excursion into Government Legacy IT Systems - I

Abstract

The Office of American Innovation (OAI), chartered by the administration to pursue "excellence in government," has an opportunity to modernize government IT systems. These systems, used by agencies that the American public relies on, are old, inefficient, and costly to maintain. President Trump has said that the cost of preserving legacy computer systems is “so high, it’s not even a believable number.” The challenge of modernizing legacy IT systems is not new and, unfortunately, prior efforts have little to show for the money. However, this grand challenge must be addressed because we cannot afford to allow our IT systems to continue to degrade and user morale to continue to suffer. The public would blame current leadership for such a failure.

The good news is that it can be done; an agency of government empowered to undertake that mission - let's stipulate that OAI is that agency - can modernize legacy-IT systems by combining sound business practices with system engineering. The resulting IT systems must be consistent in their designs, easy to use, and capable of evolving in response to increased demand, extended functionality, and new technology. To turn this vision into reality, OAI will need to carefully partition the problem, define the roles of stakeholders, build an Integrated Process Team (IPT), and avoid the minefields that have derailed previous efforts. This White Paper describes a path to success.

Introduction

The Office of American Innovation (OAI), chartered by the Trump administration to pursue "excellence in government," has an opportunity to address challenges posed by government legacy IT systems (systems developed years ago which still run). This is the first of ten posts in a White Paper explaining how to modernize these systems. Failure is not an option; the costs are too high. Moreover, government cannot simply turn this complex problem over to private industry; the risks are too high.

The legacy IT problem is serious, but not hopeless. The problem can be solved using management skill and resolve, system engineering, and sound business practices. There is more good news: it is possible to build an effective government-industry team such that OAI has the “wind at its back;” and it is possible do this job at a reasonable initial cost, a prelude to major long-term cost savings.

1.     Scope

This white paper addresses modernization of legacy government IT systems. The new family of government IT systems will be referred to as Government Systems-21 (GS-21).

1.1     What makes government systems different from private-sector systems?

Why is the government-IT-system problem so hard and why can’t we simply turn this job over to a successful private corporation? The private sector provides several types of IT systems: consumer devices and host software; enterprise systems such as database management systems; and software as a service that resides “in the cloud.” Vendors profit from selling products and services to as many customers as possible. Vendors may upgrade products at their discretion, and while they have strong incentives to make their products both state-of-the-art and upward compatible, they are under no legal obligation to do so. Likewise, they are under no obligation to refine their products or services in response to the needs of any one customer.

By contrast, government is a single customer whose requirements reflect the needs of the public and are dictated by the functions of and legal constraints on their agencies (privacy, security, persistence, etc.). Government agencies have typically contracted for systems built to their own, independent requirements and specifications. This has resulted in a variety of monolithic systems which lack consistency among the various agencies and, since they are unique, require very specialized knowledge to maintain and modify. We propose a new generation of IT systems, GS-21, which 1) observe interface and data standards over time and across agencies, 2) give highest priority to security, 3) support one-time data entry, data consistency, real-time transaction-based redundancy, and (authorized) access to data across systems, 4) can evolve in response to increased user demand, extended functionality, and new technology, and 5) are responsive and resilient in the face of high demand and various threats.

While GS-21 will be developed using commercial technology, adoption of “off-the-shelf” systems is not expected to be a viable GS-21 solution.

1.2     Agencies

Many federal agencies and offices have their own IT systems. Those that do include the Social Security Administration, the Office of Personnel Management, the Department of Homeland Security (which has several), the Internal Revenue Service, and the Department of Veteran Affairs. A challenge for OAI is to provide incentives for candidate agencies to sign on as early GS-21 adopters. Those incentives include

·         gaining influence in the GS-21 community,

·         being part of the early expression of GS-21 requirements, and

·         becoming trainers for later adopters.

1.3     Challenges

One attractive feature of a new system development is that we can start small, like a small business. However, this convenience should not mask these GS-21 challenges:

·         To seize the opportunity by acting with determination;

·         To enlist agency users in requirements definition, UI design, and data specification thereby making GS-21 their system and making them GS-21 advocates;

·         To invest in System Engineering from the start; and

·         To favor technical and programmatic decisions over political decisions.

Standards and Best Practices

Earlier posts discuss the Management Review (MR), a key element of the ISO 9001 Quality Assurance Standard; this post turns attention to the subject of standards in general. There are two primary motivations to seek certification for compliance with well-known standards such as ISO 9001. First, certification signals to potential customers that your company has convinced an auditor that you meet the standard; indeed, some government agencies and prime contractors may use compliance with standards as filters when awarding contracts, or at least may look favorably on compliance. Second, many elements of the standards represent “best practices” and adoption of these practices raises the probability of improved customer satisfaction, employee morale, and business conditions at your company. These two motivations are not mutually exclusive; they are not even independent. However, over time, they may become decoupled because, following initial certification, you may be tempted to do only the minimum required to renew certification. Moreover, because it is unlikely that all elements of any standard will be equally applicable to your company – elements which do not apply at all are generally identified in advance – it is also unlikely that you will give them all equal attention. The problem is that, unless you retain focus on the most relevant elements, doing the minimum needed for recertification may divert your attention from the pursuit of best practices.

In previous posts, consistent with the theme of this blog, I have made clear that the MR is an ISO 9001 gem; I am convinced that this is true for most companies. Depending on the nature of your company, there will be other elements within that standard of benefit to your company. In any event, whether you are pursuing certification or the efficient use of best practices, you will want to invest carefully. Since these practices are only effective when they receive regular attention, and since the investment of overhead resources can only be justified if it is cost-effective, one enabler is automation. For those pursuing certification, there is software on the market for that purpose. I would suggest that any company considering purchase of such software consider these factors: suitability; cost; ease of use; flexibility; security; and long-term support. Invariably, software developed for general use requires adaptation for specific users and uses.

More interesting for this blog is the case of companies pursuing selected best practices rather than certification; this viewpoint becomes more dramatic as the scope is expanded such that elements from more than one standard are adopted and elements not mentioned in any widely published standard (possibly unique to the company) are added. While those who write the standards may be “experts” across a broad range of practices, they do not know your company as well as you do. Even though certification may not be your goal, automation is no less important to the use and continual improvement of best practices. That said, “less may be more” with respect to software support. A couple of general questions come to mind with regard to this classic “make-or-buy” decision: Should you buy a commercial support package or build your own? Is it possible to tailor an off-the-shelf product to the organization, functions, and budget of your company? Or, would you be better off building your own support system, one that you own and control, and one which closely reflects the characteristics of your company (note: internal development, while it may offer advantages, may not be cheaper)? I will have more to say on these points in future posts.

"Management is doing things right; leadership is doing the right things...

There is nothing so useless as doing efficiently that which should not be done at all."

- Peter Drucker