The following is an exerpt from the Executive Summary of "A Model of OS-ERA: Open Source eGovernment Reference Architecture"

Index

1.    Executive Summary

1.1.      OS-ERA Software Packages

1.1.1.      Integrated Modeling Environment (IME)

1.1.2.      Service-Oriented Integration Platform (SOIP)

1.1.3.      Configuration Management Facility

1.1.4.      Ecosystems

1.1.5.      Open Source Code, Open Source Models

1.1.6.      Domains and Components

1.1.7.      OS-ERA Software Package Summary

1.2.      OS-ERA Governance

1.2.1.      Basic Governance and Management Roles

1.2.2.      Memberships

1.2.3.      Projects

1.2.4.      Releases

1.2.5.      Reviews

1.2.6.      The OS-ERA Public License (OPL)

2.    Technical Documentation of the Model

2.1.      OSERA Package

2.1.1.      OSERA Package Class Diagrams

2.1.2.      OSERA Classes

2.2.      FunctionalDecomposition Package

2.2.1.      FunctionalDecomposition Class Diagrams

2.2.2.      FunctionalDecomposition Classes

2.3.      Governance Package

2.3.1.      Governance Class Diagrams

2.3.2.      Governance Classes

2.4.      EAML&SemanticCore Package

2.4.1.      EAML&SemanticCore Class Diagrams

1.  Executive Summary

The purpose of OS-ERA is to make open-source software available to government agencies to helps them develop, integrate, and reuse components for service-oriented e-Government systems.  The potential for efficiencies that e-Government portends, along with the cost savings associated with open-source software that has been properly tested and validated, have the potential to substantially lower the cost of government.  Much of the open-source software is expected to be developed through one of the already-flourishing open-source communities, such as Eclipse, Apache, and so on. 

Among the deliverables for the first phase of the OS-ERA initiative is a formal model of OS-ERA.  The model has two main parts.  One part defines, at a high level, the make up of the software packages that the OS-ERA initiative will release.  The other part defines, also at a high level, the governance and management roles and functions that OS-ERA will require, and describes how projects that develop and release OS-ERA software packages will be organized. 

This executive summary is a synopsis of these two parts of the OS-ERA model, for the benefit of IT executives.[1]  The balance of this document contains the technical documentation of the model.

1.1.        OS-ERA Software Packages

An OS-ERA software package is a set of open source software components, packaged with supporting consultation, training, and stakeholder orientation services.   The key software components that an OS-ERA software package includes are:

*         An integrated modeling environment (IME)

*         A service-oriented integration platform (SOIP)

*         A configuration management facility

The following subsections provide more detail about these key components, and explain some other important characteristics of OS-ERA software packages.

1.1.1.     Integrated Modeling Environment (IME)

An IME is a next-generation integrated development environment (IDE).  The principal difference between an IDE and an IME is that, with an IME, developers use models that are less technical and more business-oriented than traditional Java, C++, or C# programs to design, develop, deploy, and integrate software components. 

An IME is an aggregation of:

*         A modeling tool or tools—An IME may contain more than one modeling tool, since different stakeholders in a software system see the system from different viewpoints.  For example, business analysts use business process modeling tools, database administrators use data modeling tools, security specialists use security-modeling tools, and so on.

*         A provisioning facility—Creates the artifacts and allocates the resources required to implement models over an SOIP.  The artifacts that a provisioning facility creates include:      

§         Source code for implementing models

§         Scripts for compiling the source code into executable components

§         Machine-readable instructions for automated component deployment tools

A provisioning facility includes:

§         Programs that generate the artifacts to be provisioned

§         Tools for configuring the generators

§         A model-based debugging facility that makes it possible to debug the provisioned artifacts and the models from which they are generated.

§         A resource allocator that allocates resources in the service-oriented integration platform (SOIP)

*         A metadata management facility—Another important component of an IME, which manages models (models are metadata), and includes:

§         A component that makes it possible to use XML to exchange models among tools.

§         A component that manages models in a repository (that is, in a database). 

§         An interface to the model repository that makes it possible for tools to deposit models in the repository and retrieve them as well.

§         A tool for browsing and searching models in the repository

1.1.2.     Service-Oriented Integration Platform (SOIP)

An SOIP is a runtime infrastructure that combines the functionality of:

*         A service-oriented application server—Manages many of the complications of component-based, distributed, service-oriented systems that support internal operations and electronic commerce.

*         A deployment facility—Manages the deployment of software to machines

*         A security facility—Controls access to system resources and components.  Many security facilities operate on the principle of role based access, which assigns permissions to roles, while people are assigned to fill roles and thus acquire permissions assigned to those roles.  Additional features help to control software's access to resources and components, as opposed to people's access.

*         A runtime operations management facility—Consists of:

§         A service-level agreement (SLA) monitor— Monitors compliance with service-level agreements (SLAs) that are part of the contract between trading partners in a service-oriented architecture.  Ultimately it should be possible to generate such components from formal models of service agreements between the trading partners

§         A resource manager—Manages resources such as server and client machines, processes, threads, database connections, and so on.

An SOIP ties these facilities together into a coherent whole while hiding some of their technical minutia.  The complexity hiding makes it easier for programmers to make use of the combined functionality.  Crucially, it also makes it easier for the provisioning facility of an IME to generate components that use all of these facilities.  Model-driven development stands on two pillars.   

1)       Raising the level of abstraction of development languages, by using abstract models rather than Java, C++, and C# as the central, machine-processable description of software behavior. 

2)       Raising the level of abstraction of platforms.  An SOIP that hides minutia from programmers hides it from provisioning facilities as well.  This makes it easier to write the generators that produce source code and other artifacts required to execute a model

In its most advanced form, an SOIP is a business process virtual machine (BPVM), which simulates and executes relatively high-level business process and electronic commerce models. 

1.1.3.     Configuration Management Facility

A configuration management facility manages software configurations.  The following quotation from  R.S. Pressman & Associates, Inc., (http://www.rspa.com/spi/SCM.html), provides an excellent definition of such a facility:

"Software configuration management (SCM) is a set of activities that are designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling changes that are imposed, and auditing and reporting on the changes that are made."

A configuration management facility consists of:

*         A version control facility—Maintains and tracks multiple versions of components, lessening the burden on system administrators who need to control which versions of which components are available in which software packages.

*         A check-in check-out facility—Mediates access to models and other artifacts by multi-person teams.

*         A development process manager—Enforces a development process.  Some development process managers make it possible to customize the development process model that is enforced. 

*         A change auditing facility—Produces audits of the changes that have been made to software packages over multiple releases.

*         A change impact analyzer—Projects the impact that changes to designated software components would have on the system or systems within which those components reside and function

1.1.4.     Ecosystems

OS-ERA’s architecture is component based.  Some of the components that OS-ERA software packages contain are called ecosystems. An ecosystem is an executable component that is extensible via a coherent plug-in architecture. 

Eclipse is an example of an ecosystem.  It is built from the ground up to be extensible, via an architecture that provides a way for new components to “plug in” to the ecosystem.

An integrated modeling environment (IME) is an ecosystem, because it is built from the ground up to make it possible to plug in new modeling tools, metadata management facilities, provisioning facilities, and so on.  A service-oriented integration platform (SOIP) is an ecosystem, because it is built from the ground up to make it possible to plug in new executable components, deployment facilities, security facilities, and so on. 

Some of these components of IMEs and SOIPs are ecosystems in their own right.  For example, a provisioning facility is an ecosystem that makes it possible to plug in new generators that create code, deployment scripts, and other such artifacts.

1.1.5.     Open Source Code, Open Source Models

OS-ERA introduces the concept of open source models.  The notion of open source models expands upon the concept of open source code.  In addition to making auto-generated and manually written source code publicly available, OS-ERA plans to make available models that were used to design and generate the executable software, including UML models, high-level business process models, models of service-level agreements for e-commerce, and so on. 

OS-ERA will also make available the source code and specifications for the provisioning facilities that provisions executing systems from models.

As mentioned earlier, many of the components of OS-ERA software packages will have been developed by open source communities such as Eclipse and Apache.  Source models for such software may not be available to include in OS-ERA software packages.  However, software developed specifically for OS-ERA will include source models.

1.1.6.     Domains and Components

Each component included in an OSERA software package will be tagged with information about the domain that the component addresses.  There are three kinds of domains:

*         Generic business—Examples of generic business domains include business process, value chain, business information, and so on. 

*         Line-of-business—Examples of line-of-business domains include: procurement, currency options, radar stations, retail banking, and so on.

*         Technical—Examples of technical domains include persistence, latency, distribution, and so on. 

1.1.7.     OS-ERA Software Package Summary

Figure 1 summarizes the contents of an OS-ERA software package.

Figure 1: The Contents of an OS-ERA Software Package

1.2.        OS-ERA Governance

The main aspects of the governance model are:

*         Governance and management roles—The roles and responsibilities that organizations and people must assume in order to for OS-ERA to function.

*         Projects and releases—How OS-ERA projects are formed, managed, and reviewed, how projects lead to the release of OS-ERA software packages.

*         Memberships—The different ways that organizations can be members of OS-ERA

1.2.1.     Basic Governance and Management Roles

Figure 2 depicts the main organizational and human roles required to govern and manage OS-ERA.  The business plan being submitted along with the OS-ERA model suggests which organizations and people should play those roles.

An organizational role is a role played by an organization.  A human role is a role played by a person, who is a member of an organization.  For our purposes, membership in an organization on the part of a person includes being an employee of or performing work on contract for the organization.  The same organization can assume more than one organizational role, and the same person can assume more than one human role.

The OS-ERA organizational role represents the overall OS-ERA organization.  Were OS-ERA to incorporate, the corporation would play this role.

The Governance organizational role represents the legal governance of OS-ERA.  Were OS-ERA to incorporate, a Board of Directors would play this role.  If OS-ERA does not incorporate, a lesser organization could play this role, such as a policy council.  The Governance role is executed by a number of Governors.  Were OS-ERA to incorporate, members of the Board of Directors would play the Governor role.  The General Manager is accountable to the Governance organization.

The Management organization is staffed by a number of Managers (people), including a Marketing Manager, a Finance Manager, and an Asset Manager.  The Asset Manager is responsible for physical facilities and for the maintenance of the OS-ERA membership rolls.  Managers have dotted line accountability to the General Manager, but work at the pleasure of the Management organization.

The organization that assumes the Management role is ultimately responsible for planning releases of OS-ERA software packages, and for reviewing the architecture of prospective releases.  However, Planning and Architecture Review are broken out as separate roles, because the Management organization will probably delegate planning and architecture review to other organizations. 

The Planning role could be assumed by a new organization, such as an OS-ERA Planning Committee.  This is the likely outcome, as explained in the business plan, but the model itself leaves open which organization will assume the role.  The model also allows for a pre-existing organization, such as the GSA, to assume the role.  The Architecture Review role could be assumed by a new organization such as an OS-ERA Architecture Board.  This is the likely outcome, but, again, the model itself leaves open which organization will assume the role.

The Planning organization is staffed by Planners (people), one of whom is designated as the Planning Coordinator.  The Architecture Review organization is staffed by Architecture Reviewers (people), one of whom is the Architectural Coordinator.

The governing organization is responsible for formulating a set of by laws.  The by laws include a statement of goals for OS-ERA, and mandate certain documents that must be produced, maintained, and approved.  The planning organization is responsible for the Roadmap document, which describes an overall plan for achieving the goals stated in the by laws.

 

Figure 2: Basic Governance and Management Roles

1.2.2.     Memberships

Organizations can be members of OS-ERA.  There are four basic kinds of membership:

*         Contributing member—Contributes human resources to staff OS-ERA projects

*         Financing member—Contributes financial resources to fund OS-ERA projects

*         Academic member—Contributes student interns and academic liaisons to staff OS-ERA projects

*         Premier member—Contributes human and financial resources to staff and fund OS-ERA projects

The formulas for the exact requirements for human and financial resource contributions have yet to be worked out.  However, it is worth noting that the OS-ERA model makes it possible to enter the formulas formally into the model, whereupon software can be generated that helps to enforce the formulas.  In that sense, OS-ERA governance and management will itself be model-driven, to some extent.

Membership in OS-ERA confers certain privileges, including:

*         Seats in the Governance organization

*         Seats in the Management organization, which, as Figure 2 illustrates, could include Managers, Architectural Reviewers, and Planners

*         Direct access to the OS-ERA repository.   Although OS-ERA releases will be publicly available, the general public will not have direct access to the OS-ERA repository, allowing members to review work-in-progress.  Write access will be more sharply restricted than read access.

The formulas for allocating the number of seats permitted to various members have yet to be determined.  Again, these formulas can be entered into the model and generated software can help enforce them.

1.2.3.     Projects

Although projects are ultimately owned by the Management organization (see Figure 3), OS-ERA member organizations kick projects off by producing a Project Plan, which must be reviewed and approved.  The Project Plan must explain how it helps to achieve at least one of the goals outlined in the by laws. 

For each project, a Project Management Organization (PMO) is created.  Various project management personnel, including a Project Lead and Developers, staff the PMO.  It may also be staffed by liaisons to academic institutions (institutions that are OS-ERA Academic members) and by academic Interns.  Interns are responsible to the Project Lead, with dotted line responsibility to the liaison for their institution.

 

Figure 3: Project Management Roles

1.2.4.     Releases

A project leads to the release of OS-ERA software.  There may be multiple releases per project, where each successive release represents a new version of the software.

A release consists of one or more OS-ERA software packages.  The packages of a particular release differ from each other only in which platforms they support.  For example, one package in a release may support Windows, another may support Linux, and yet another may be platform-independent.  A platform-independent package may contain platform independent-models that were used to create the software. 

The planning organization is responsible for maintaining a Comprehensive Release Plan that sequences the releases and provides a rationale for sequencing.  The Comprehensive Release Plan is dependent upon the Roadmap, in that it must demonstrate how the plan fits into and advances the Roadmap.

1.2.5.     Reviews

The Roadmap, the Comprehensive Release Plan, individual Project Plans, and releases have to be approved by the Planning,, Architecture Review, and Governance organizations.  

Basically, the Planning organization reviews first; however, in the case of the Roadmap and the Comprehensive Release Plan, the Planning organization is responsible for these documents, and thus, when it has prepared and approved a draft, the planning review is considered to have been completed.  In the case of Project Plans and releases, a rejection by the Planning organization means that the item in question goes back to its creators for further work.  As mentioned earlier, member organizations prepare Project Plans for review.  Project Management Organizations prepare releases for review.

Once an item has been approved by the Planning organization, the Architecture Review organization reviews it.  If it rejects the item, it goes back to its creators for further work and starts the review cycle over again; that is, the item must once again be reviewed by the Planning organization before it can be submitted to the Architecture Review organization again.

Once an item has been approved by the Architecture Review organization, the Governance organization reviews it.  If the Governance organization rejects the item, it goes back to its creators for further work and starts the review cycle over again.  Approval by the Governance organization means that the item has completed all required reviews successfully.  In case the item being scrutinized is a release, the Architecture Review organization is responsible for testing the release as part of its review responsibilities.  However, it may delegate testing to another organization.

1.2.6.     The OS-ERA Public License (OPL)

A release carries the OS-ERA Public License (OPL).  The OPL will have to take into consideration the fact that OS-ERA software packages aggregate other open-source components, each of which carries some form of public license. 

Some of the licenses of the constituent components may be viral and others may be non-viral.  A viral open source license requires developers of derivative products to make the source available for the derivatives.  A non-viral open source license does not impose this obligation.

The OPL will have to take a stand regarding the viral or non-viral nature of software that is specifically developed by an OS-ERA project, as opposed to software created elsewhere that is aggregated in the releases.  It will also have to avoid violating the terms of the externally-developed components' licenses, especially regarding the viral or non-viral nature of those licenses.  Furthermore, the OPL will probably have to provide indemnity that other open source public licenses do not provide.  Finally, the OPL will have to take into account the fact, explained earlier (see the section entitled Open Source Code, Open Source Models), that OS-ERA is not only an open source code initiative, but is also an open source model initiative


 

[1] The model also includes a smaller, less developed model of some advanced OS-ERA components, called EAML (Enterprise Architecture Modeling Language) and the Semantic Core, which may be available in the medium to long term.  This executive summary does not cover EAML and the Semantic Core.