The OsEra roadmap is organized as a set of business driven initiatives that are supported by the various OsEra projects. The actual tasks will be based on the interest of the OsEra stakeholders in pursuing each initiative.
Executable Enterprise Architecture Initiative
A major theme of OsEra is to support the executable enterprise architecture of major organizations with the GSA's enterprise architecture effort being both a driver and foundation. EA for such an organization requires that multiple efforts by multiple organizational units using multiple contractors with multiple tools be able to synchronize their efforts as part of a unified effort over time, integrated with a federated EA repository. The OsEra prototype already shows how this will work, the next steps will be to turn it into an open environment. The roadmap items supporting this are as follows in an order based on priority and dependencies:
Architectural information is developed based on a variety of tools, standards and methods. To enable semantic integration of this information the organization needs a common model and repository standard in which to bring together and integrate this information. The common model is represented as the subset of the semantic core required for the EA methodology. This same repository becomes the integration platform for design tools used in the EA process. The common model, combined with metadata management technologies provides the conceptual end technical platform for EA. For the needs of GSA, establishing this model is the key requirement for supporting a wide-scale EA effort.
Status: Core modeling concepts are currently provided in EDOC++, UML and a requirements database. The Semantic Core model is defined but not et integrated into the MDA infrastructure
Next Steps: Use of the semantic core as the integration hub
A well architected and documented methodology that is sufficiently defined to support the common goals but sufficiently flexible to accommodate individual organizations methods and tools is required to support unifying the efforts across the organization. The EA methodology, combined with the appropriate governance plan, provides standards by which EA is performed in the organization. Documenting the methodology is required to enable multiple organizations to produce a coordinated enterprise EA.
Status: There are multiple architecture documents and presentations but they are not well integrated.
Next Steps: Integrate the current documents and provide an overall architectural vision and plan
Components need to be provided under the integrated development environment to integrate the information produced and consumed by common standards, file formats and tools. Adapters are provided to transform information between these tool models and the common model, providing for tool integration without point-point integration. Integration projects include:
Status: UML and EDOC is implemented as well as a large number of technology specific models (E.G. XML Schema).
Next Steps: Produce adapter components for the common model
The information developed using the methodology and represented in the common model must be able to be both shared and developed by multiple parties. While "file system" based tool are sufficient for individual efforts, an enterprise repository is required to enable multiple organizations to have multiple simultaneous related architecture efforts. The current repository is based on the Eclipse-EMF environment backed by standards configuration management (CVS or Subversion). The file/CVS approach is sufficient for smaller efforts but does not scale to enterprise needs. Next generation repositories will provide for distributed, federated and shared management of EA assets.
Status: OsEra is currently implemented on Eclipse-EMF and CVS as a "development environment"
Next Steps: Choose a MOF or RDF infrastructure and implement an open, shared repository for OsEra models.
Business Process Simulation
Business process simulation enables process architectures to be simulated across the enterprise to provide for better understanding of the architectures, estimation of the benefits based on metrics and validation of candidate components. The simulation capability complements the overall EA environment by providing the first level of executeability.
Status: Simulation is provided through Component-X™
Next Steps: Development of a OsEra integrated simulation capability
Federal Enterprise Architecture Support
OsEra supports the FEA though integration of the FEA reference models as part of the OsEra Modeling paradigm.
Model Based Integration Platform Initiative
The model based integration infrastructure initiative connects enterprise architecture with model driven systems architecture to provide a platform for developing and deploying application components that help realize the business processes. The combination of the EA capabilities with the integration infrastructure complete the "Model to Integrate" vision.
The enterprise service bus, or ESB, provides the common infrastructure onto which application components can be deployed into a service oriented architecture (SOA). Application components deployed in this infrastructure that are based on the enterprise architecture are able to interact across inter and intra enterprise boundaries to realize business processes. The processes defined in the architecture help coordinate and integrate these components into an orchestrated solution. The ESB provides the middleware and other technical infrastructure required for execution and interoperability. The ESB is also the "technology target" of the MDA provision capabilities. OsEra includes a reference ESB implementation based on jBoss, but can interoperate with other ESB implementations, such as those developed on Microsoft Windows® based on open middleware standards such as web services.
Status: The jBoss based ESB is part of the OsEra demo, however the underlying technology is not ready for production use.
Next Steps: Evolution of the BPEL infrastructures to enable production capabilities
The MDA provisioning engine provides the general capability for OsEra to produce and consume external artifacts. One of the primary uses of this engine is the production of the technical artifacts required to support an ESB. The provision engine combines the capabilities of model transformation, process automation and import/export to support fully automated MDA capabilities. This generic capability then needs to be used to produce provisioning components for specific external technologies.
Status: The provisioning engine is a mature part of the prototype OsEra capability.
Next steps: Integrate model based transformation and process automation.
The model driven ESB components complete the "model to integrate" chain by providing a path from the architectures in the common model to the execution infrastructure. These components utilize the MDA provisioning engine to produce the artifacts specific to a particular ESB implementation. The ESB provisioning components are produced within the same project as the subject ESB.
Status: MDA provisioning for jBoss based on the architecture is implemented in the current OsEra demo.
Next Steps: In combination with making the ESB "production ready", make the provisioning capability production ready to support model driven application components for a service oriented architecture.
The semantic integration initiative provides for the integration of systems and information within and outside of the enterprise. This addresses the widespread requirement for the integration of legacy interfaces and information repositories. While the executable EA provides for an "architected solution", semantic integration enables independently defined systems to be integrated more quickly, cheaply and reliable based on semantic technologies. Semantic integration builds on many of the "model to integrate" capabilities of OsEra but goes a step further to provide for semantic analysis and integration of independently architected solutions. The sub-projects for this initiative are covered in this white paper.
The "full" semantic core is required for semantic integration since it will be representing information in external artifacts, not just those based on the OsEra methodology. The semantic core provides the capability to have a common representation for specifications developed in different tools, standards and methods. The semantic core is then used to support a "virtual repository" of that information.
Status: The semantic core is defined in the abstract but has not been tested
Next Steps: Validate the SC model and develop integration components for external artifacts of interest
Create integration components
Create the technology components to allow the reference and/or integration of external specifications into the OsEra environment and link these with the semantic core. This will provide a common view of common specification/architectural semantics so that they may then be understood, analyzed and integrated within OsEra.
Create/Import reference Ontologies
Analyze existing upper and reference Ontologies to be used as a basis for "grounding" the terms in existing architectures based on ontological definitions. Existing work such as Cyc, Sumo and Wordnet® can be used as a baseline. The terms in these Ontologies will be connected to the imported specifications to aid in integration.
Create "Semantic Grounding" tools
Semantic grounding tools assist architects and domain experts in relating the terms in their legacy architectures to concepts in the reference Ontologies. This process of making the connection between the "strings" in the typical model and concepts in the semantic grounding process and the basis for automating integration. The semantic grounding components will also allow for the extension of the set of reference concepts in a user friendly environment that does not require a background in ontology.
Create Integration Enabling Tools
The integration tools use the information in the semantically grounded specification to assist an architect in specifying adapters between the specifications. Common concepts and relations between those concepts allow semantically aware components to suggest adaptations and allow the archit4ct to add or correct information and validate the adapters using instances.
Connect adapters to the model based integration infrastructure
The adapter specifications become source models for technology adapters to be deployed in the integration infrastructure as detailed above.