Tuesday, May 16, 2017

An Excursion into Government Legacy IT Systems - X



10.     Risks and Risk Mitigation

10.1     Politics

Risk: GS-21 must be a technical effort guided by an impartial government entity (OAI?). If GS-21 takes on the appearance of a partisan political effort, it will die from distraction. In that regard, any appearance of crony capitalism or congressional or activist interference could kill the effort.
Mitigation: GS-21 will require high cover from the White House to make clear, at every challenge, that this effort is meant to 1) improve working conditions for government workers, 2) improve service to the American public, and 3) save taxpayer money and therefore needs to be allowed to succeed. GS-21 decisions must be based on technical and cross-agency programmatic criteria. Political decisions will be very difficult to defend.

10.2     Internal resistance

Risk: Workers, agencies, and users all dislike change. Resistance to GS-21 can be expected from all directions.
Mitigation: OAI must make users an integral part of the development process.

10.3     Skepticism

Risk: On one hand, there have been failures. On the other hand, some are terrified that, even if OAI succeeds, someone may benefit unfairly.
Mitigation: Impartiality, transparency, and a careful incremental approach are necessary.

10.4     Impatience

Risk: Big projects tend to allocate too little time to Team building, Planning, Socialization, Requirements definition, Architecture definition, and Standards specification. During design
·         too little attention is given to Community feedback, Comment review, and Response,
·         too little time is left for Alpha and Beta test and refinement, and
·         there is a temptation to take on too much at once – too many layers, agencies, or activity domains.
Mitigation: Celebrate successes and plan following steps deliberately.

10.5     Leadership

Risk: GS-21 is an enormous undertaking. Project leaders may be
·         Slow to make vital decisions,
·         Unable to resolve team disagreements,
·         Unable to motivate the team on behalf of program sponsors,
·         Unable to defend the team and the program to program sponsors.
Mitigation: GS-21 will need clear goals and a team-oriented, apolitical, disinterested leader with the courage to take risks, admit mistakes, and credit successes to the team.

10.6     Funding

Risk: Money will be closely watched. Underfunding could choke off vital operations; and overfunding could breed waste and make the effort a target for cancellation.
Mitigation: GS-21 should start with a “bare bones” budget, build the team, and request more funding as needed. Since agencies have a stake in GS-21 success, cost sharing has the potential to significantly reduce funding risk.

10.7     The Roadmap

Risk: The schedule may not be quite right. If it is too ambitious, the team may miss deadlines and look bad. If it is too cautious, the work may slow to meet expectations.
Mitigation: The Roadmap must be a living document, kept current as the effort proceeds.

10.8     Technical setbacks

Risk: Not everything will go as planned. GS-21 represents innovation and new development.
Mitigation: make the ITE Facility a Center of Excellence, open for critical experiments (needed to mitigate technical risk) and for demonstrations on short notice – keep it Great.

10.9     Innovation never works in government

Risk: Even when they spend millions of dollars, DARPA and ONR rarely transition anything. Although this is not entirely fair, those agencies generally rely on others to make transition happen.
Mitigation: Invest in and insist on high-quality system engineering. The innovation must be proscribed “within the layers,” observant of standardized interfaces

10.10     Security, security, security

Risk: the external threat ranges from mischief to crime and espionage; the internal threat represents a violation of trust and presents a related, but separate set of challenges.
Mitigation of external threat: Inconvenience – maximum convenience results in maximum risk – there must be tight, well-protected pathways to data; data must be accessible, but access must be tightly controlled. Defense in depth must include physical protection, partial isolation, and trusted processes and personnel. The ITE Facility must be accessible to critical security experiments, where live data are not exposed. Security measures must themselves be protected (classified). Inconvenience raises costs for all: system developers; authorized users; and unauthorized users.
Mitigation of internal threat: verification of insider trustworthiness can help, but as we have learned from double agents, is not foolproof. Access logs, redundant cross checks, data and access partitions, rotation of admin privileges, and (admin) term limits can help, but the insider threat will continue to be a difficult challenge.
Mitigation of data loss/destruction threat: continual data backup; geographic distribution of data; a transaction paradigm; and elimination of single points of vulnerability.
R&D: investment in detection. ID, pursuit, and prosecution to raise the cost to hackers.

Sunday, May 14, 2017

An Excursion into Government Legacy IT Systems - IX



9.     Modeling, Measurement, and Continual Improvement

9.1     System/Software Characterization and Prototyping using ITE Facility

·         Characterization as unambiguous documentation. It makes clear how the user activities and system functions actually work.
·         As an Alpha test site, the ITE Facility supports critical experiments and tests prior to release to users.

9.2     Test, Evaluation, and Acceptance (of activity implementations)

·         Integration, test, demonstration, and conformance filter – in other words, the ITE Facility is a tool for enforcing the standardization process;
·         The ITE Facility supports the clean separation of vendor development from OAI test and evaluation;
·         The ITE Facility also supports software certification.

Saturday, May 13, 2017

An Excursion into Government Legacy IT Systems - VIII



8.     System Engineering (SE)

The Goal State (Section 5) describes the high-level vision for GS-21. This includes a layered architecture and standardized interfaces. More specifically, SE guidelines must define, in detail, interfaces between layers, UIs, and data models.

8.1     Layered Architecture

Since layered architectures have been in use for many years, it is not premature to state that the GS-21 will be based on both the ISO OSI model for communications and on a layered computing model such as the DoD Architecture Framework (DoDAF). As an aside, by connecting user activities to system functions to facilitate requirements definition and activity test, it may be possible to adapt parts of DoDAF to GS-21 needs.
OAI would do well to examine the Internet architecture and how free-market upgrades respond to published standards and consumer demand. While layers and even interfaces between layers may experience change, the layered network and computing architectures have been a bedrock of system-engineering stability for more than 50 years.

8.2     Data Model

The data model defines the formats for the data that must be retained, kept current, and protected and must stand the test of time. Changes to these formats will affect countless records and must be kept to a minimum; it will be easier, at least at first, to add fields than to change them. However, we need not count this as a major risk area since we will begin from legacy-system baselines. The formats of the data maintained by those systems need to be examined, but because they have been tested over time, there is reason to believe that the formats will not need major changes.
Each data class will be controlled by a single agency to assure that objects in that class are protected from unauthorized users (government users from other agencies request but may not directly change such data). This paradigm offers the intriguing possibility of solving three difficult problems at once. One agency, owning the class person, could be tasked to accumulate and keep current data on every person in the country. This would enable these government actions: document every person (to end the uncertainty of undocumented residents); make the census more current and far less costly to update; and protect citizens from identity theft (through restricted access to person data).
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 the transaction paradigm.

8.3     Policies and Resources

The architecture may need to include 1) a policy manager to address quality of service and security and 2) a resource manager for systems where resource allocation applies. These concepts are described in Multipurpose Activity Definitions and Interfaces to Support Operational Needs (MADISON), by Maniel Vineberg, 2002 (available on line and on request). While computer technology has advanced dramatically over time, general principles regarding quality of service and resource allocation have endured.

8.4     GS-21 Guidelines and Standards

To ensure a useful, maintainable set of systems, a well-documented set of guidelines and standards must be observed. These include the following:
·         Approved programming languages, for example
o   HTML for web-programming,
o   Object-Oriented Programming Languages such as Java, Python, and C# for implementing system functions, and
o   SQL for database management system (DBMS) programming;
·         Data formats specified in the DBMS of choice;
·         Clean separation of vendor development from OAI test and evaluation; and
·         Priority of parameter tailoring over code tailoring to reduce the required level of programmer specialization and the cost to make user activity or system function changes.