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.
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.
No comments:
Post a Comment