Summary
This is a high-level summary of the GS-21 family of new
government systems. Details may be found in earlier posts.
1 Scope
This white paper proposes a comprehensive approach to modernizing legacy government-IT systems. Government-system requirements reflect the needs of the
public and are dictated by the functions of and legal constraints on government agencies (privacy, security, persistence, etc.). IT modernization is a Government challenge; Government cannot move that responsibility to the private sector.
We propose a new family of IT systems, Government Systems-21 (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) evolve in response to increased user demand, extended
functionality, and new technology, and 5) are resistant to external and internal
threats. While GS-21 will be developed using commercial technology, adoption of
“off-the-shelf” systems will not be a complete GS-21 solution. Rather,
commercial technology will be adopted or adapted within the GS-21 architecture.
It is proposed here that the requirements of individual federal
agencies be addressed in a consistent way within GS-21. To get user “buy in,”
agency users will be part of the GS-21 design and test process. To assure
success, system engineering principles will be adhered to throughout design and
development. To assure viability, all GS-21 decisions will be made with respect
to technical and programmatic criteria; political decisions will be
counter-productive.
2 Stakeholders
The Office of American Innovation (OAI), chartered to pursue "excellence
in government," is designated herein as the smart buyer of IT systems for the government. OAI will 1) set GS-21
requirements, 2) request contractor proposals for system engineering (SE)
development, 3) request
vendor solutions within SE guidelines, and 4) conduct integration, test,
evaluation, and acceptance of proposed solutions.
An Integrated Process Team (IPT) will include a representative cross-section of stakeholders
and will offer guidance to OAI which reflects stakeholder concerns.
OAI will work with Government
agencies and the IPT to set program goals, schedules, and cost estimates.
OAI will work with agency-system users to 1) define requirements and User
Interfaces (UIs), 2) test, evaluate, refine, and accept systems, and 3) train
users.
OAI will devote time and attention to monitoring system
access by the public.
System Engineering and Technical Assistance (SETA) contractors will directly support
OAI in the administration of the GS-21 program. They will be “fire-walled” from
vendors and will not hold OAI management positions.
Much of GS-21 development will fall to vendors who will 1) participate in the definition of the architecture
and standards, 2) develop a GS-21 integration, test, and evaluation (ITE)
Facility, 3) offer hardware and software to implement requirements, and 4) integrate,
test, and evaluate prototypes in the ITE Facility.
3 Action Plan
OAI, the smart buyer
for the agencies, will conduct workshops, forums, and industry days to make
stakeholders a part of GS-21 planning. Workshops will be open, goal-directed by
the IPT, and well-advertised by OAI. Customers, potential (SETA) contractors,
and vendors will be invited. The IPT will submit design and development
concepts for critical comment.
OAI will gather and manage requirements from agency managers
and system users (customers). This open process will assure coverage, allow for
extensibility, and help to prevent requirements “creep” (the continual addition
of new requirements).
Inclusion is the key to getting the wind behind OAI;
marketing based on visible progress is the key to keeping it there. The IPT will
manage and refine requirements, report progress, promote cost-sharing, and conduct
inter-agency information exchanges.
GS-21 development will start small and build the confidence,
consensus, and momentum necessary to success. In system development, motion is
not the same as progress; it takes time to build working relationships and
trust such that stakeholders are pulling in the same direction.
4 Current State (Baseline): legacy systems
Many legacy government IT systems include outdated hardware
and software and rely on a decreasing number of programmers and system experts
to implement changes. Systems of different agencies are generally not
standardized or connected and use different UIs, programming languages,
data models, and documentation guidelines.
5 Goal State
GS-21 will be characterized by a layered architecture,
standardized interfaces, and stable data models, and supported by clear
system-engineering (SE) guidelines, and an Integration, Test, and Evaluation (ITE)
Facility.
The layered architecture will 1) enable transition through
incremental updates, 2) enforce modularity and reduce technical risk, and 3) enable concurrent improvements.
Standardized, stable
User Interface (UIs) clarify functional requirements.
Standardized data models enable one-time data entry across
systems as well as data validation and authentication. [Note: Collecting and
protecting data in the Person class may
have the potential to reduce identity theft, simplify census-taking, and
clarify who is in the country.]
SE Guidelines include approved object-oriented development
languages and DBMS standards. The ITE Facility will be used to integrate, test,
demonstrate, and evaluate new code and to assure that the new code meets SE
Guidelines.
6 Transition
Step 1: break the direct connection between the user and his
legacy system and reconnect the user through a newly designed UI and a
temporary interface. This will validate UI viability while preserving legacy-system
operational capability.
Step 2: replace legacy-system code under SE guidelines. Incremental
installation of new software (and removal of the temporary interfaces) will be
open to vendors; requirements, standards, and SE guidelines will be made public
and vendors will be free to offer solutions.
7 Requirements and Constraints
Functional
requirements start with activities,
what users do. Activities will 1) be defined in cooperation with agency-system
users, 2) cover legacy functionality, and 3) be upgraded as needed. Functional
requirements also include functions,
what systems do to carry out activities. Activities will request functions
across an interface. Functions will be built on Objects.
Quality requirements
establish how well the system must perform activities and functions. Examples
include availability, reliability, scalability, ease of use, security, and survivability.
Constraints
include costs, schedules, physical aspects (size, weight, etc.), and on-line
help.
8 System Engineering (SE)
The GS-21 will include a layered architecture (based on the
ISO OSI model) and standardized interfaces. SE guidelines will define
interfaces between layers, UIs, and data models. The data model defines formats
for data that must be retained, kept current, and protected. Changes to formats
will affect many records and be made only when necessary.
Each data class will be controlled by a single agency to
assure that objects in that class are protected from unauthorized access. Data
models and schemas will be embodied in a database-management system (DBMS). The
DBMS will be protected physically, data survivability will be assured through
redundancy (primary and backup copies of the DMBS), data will be protected
through permission-based access restrictions and privacy mechanisms implemented
in the development language, and data integrity will be protected through a
transaction paradigm.
To ensure a useful, maintainable family of systems, a
well-documented set of guidelines and standards must be observed. These include
approved programming languages, data formats specified for the DBMS of choice,
clean separation of vendor development from OAI test and evaluation; and a
preference for parameter tailoring over code tailoring.
9 Modeling, Measurement, and Continual Improvement
GS-21 systems will characterized / prototyped using the ITE
Facility. Characterization is unambiguous documentation which clarifies how
user activities and system functions work.
As an Alpha test site, the
ITE Facility will support critical experiments prior to production.
The ITE Facility will support 1) separation of vendor
development from OAI test and evaluation, 2) software certification, and 3) regression testing to validate changes.
10 Risk and mitigation
Risk 1: An appearance of partisan political decisions.
Mitigation: Decisions will be based on technical and
cross-agency programmatic criteria.
Risk 2: Resistance to change.
Mitigation: Users will be an integral part of requirements management, test, evaluation, and training.
Risk 3: Skepticism.
Mitigation: Impartiality, transparency, and an incremental
approach.
Risk 4: Impatience.
Mitigation: Allocate sufficient time to Team building,
Planning, Socialization, Requirements definition, Architecture definition, Standards
specification, Feedback, Response, Test, and Evaluation. Celebrate successes
and plan following steps deliberately.
Risk 5
Leadership gap.
Mitigation: A team-oriented, apolitical, disinterested
leader with the ability to stay on task and the courage to take risks, admit
mistakes, and credit successes to the team.
Risk 6: Funding
Mitigation: Start with a “bare bones” budget, build the
team, and request more funding as needed. Promote cost sharing with agencies.
Risk 7: The schedule may be too ambitious or too cautious.
Mitigation: The Road Map must be a living document, kept
current as the effort proceeds.
Risk 8: Technical setbacks.
Mitigation: make the ITE Facility a Center of Excellence,
open for critical experiments. Work to keep the Road Map current and to level
expectations among stakeholders.
Risk 9: Innovation doesn't work in government; DARPA and ONR
rarely transition anything.
Mitigation: Invest in high-quality SE and rigidly enforce
layering and interface standards.
Risk 10: Security threats.
Mitigation of external threat: Accept inconvenience – tight,
well-protected pathways to data, defense in depth to include physical protection,
partial isolation, and trusted processes and personnel. Security measures must
themselves be protected (classified).
Mitigation of internal threat: verification of insider
trustworthiness, access logs, redundant cross checks, data and access
partitions, rotation of admin privileges.
Mitigation of data loss/destruction threat: continual data
backup; geographic distribution of redundant data; a transaction paradigm; and
elimination of single points of vulnerability.
