25 March 2009: ModelDriven.org Announces the Availability of a new Open Source Project: ModelPro. Model Driven Solutions to Provide Support
26 January 2009: Ed Seidewitz' Article "What Models Mean" Chosen Among IEEE Software Magazine's 25th-Anniversary Top Picks
16 April : Model Driven Solutions is a sponsor of the US Federal Government Industry Advisory Council (IAC) ArchitecturePlus Seminar in Washington, DC
27 April-1 May: Ed Harrington is presenting: "Open Source Tooling for Implementing OMG's new SoaML Standard" at the Open Group Quarterly Architecture Practitioners Conference in London, England, UK
31 May-2 June: Model Driven Solutions is a small business sponsor of the US Federal Government Industry Advisory Council (IAC) Management of Change (MOC) Conference, Norfolk, VA
2-5 June: Wen Zhu is leading a BOF and Dr. Walt Melo is presenting at JavaOne at the Mascone Center, San Francisco, CA
Model Driven Solutions
These are just some of the projects recently completed:
General Services Administration: Federal Acquisition Service (FAS) Service Oriented Infrastructure (SOI)
FAS faced challenges regarding agility, integration, security, standards-based technology implementation, and pressure to reduce expenditures. To address these challenges, FAS Office of Chief Information Officer (OCIO) decided to leverage a SOI approach which can be used to integrate legacy business systems, decouple functional from non-functional concerns. The FAS SOI project was an important step towards this direction.
In particular, SOI focused on the following technologies:
Enterprise Service Bus (ESB)
Java Business Integration (JBI)
Business Process Management System (BPMS)
In addition, the SOI project focused on open source SOA products, including:
We examined three open source ESB platforms and provided assessments from both architectural and functional perspectives. In particular, we focused on the role of JBI, the standard basis for Java-based ESB, in such areas as reusability, interoperability, and maintainability. We also documented recommendations and issues for achieving interoperability among ESB platform with standard based technologies such as web services and Java Messaging Service (JMS).
Reusing existing assets, including logic implemented in J2EE technologies is one of the main objectives for refactoring a J2EE application for the ESB platform. Within the scope of SOI, we refactored an FAS production application for each of the ESB platforms and recommended best practices for porting J2EE applications to ESB with little or no changes, while taking advantage of the various services provided by the ESB. While the refactored application retained the same functional interface, it leveraged ESB’s support for security, reliable messaging, web service transaction, and other quality of service capabilities. At the same time, the refactored applicaiton allows for better maintainability and interoperability.
We elaborated the relationship between SOI and BPM. As SOI provides the platform for loosely coupled composite applications, continuous business improvements through business process management now becomes possible. However, integrating BPMs and ESB is not an easy task, in part because there are numerous technology choices and the products often offer overlapping capabilities. To address these issues, we recommended an “Architecture Driven Approach” to build the IT infrastructure. Instead of starting from a vendor product, requirements for an SOA stack should be based on the capabilities needed to address business requirements. We demonstrated this approach by implementing BPM orchestration for the newly refactored services.
Last but not least, we recommend a “Model Driven Approach” to develop business services and processes, as MDA is the best approach to preserve IT investment in the face of rapid technology changes. In such an approach, the business services and focus on business concerns, not dependent on technology platforms.
Project Results and Benefits
By establishing an open source, open standard based platform for service-oriented integration, the SOI project helped FAS take a significant step in developing an enterprise SOA platform that promotes reusability, interoperability, and maintainability, including
Establishing principles and patterns for reuse, interoperability, and agility
Aligning with FAS SOA Reference Architecture
Providing open source ESB platform comparison and assessment
Elaborating the relationship of ESB and BPMS
An FAS SOA lab was setup with multiple ESB and BPMS products, including
General Services Administration: OSERA Enterprise Services - Service Registry
OES is part of the “OSERA” program of GSA. OSERA stands for “Open Source eGov Reference Architecture”. Significant deliverables of this project include:
An operational prototype of a standard-based Service Registry
A FEA SCM Service Taxonomy that provides the structure against which open source clients written in JAXR can execute queries
Publication and discovery of GSA Policies expressed as WS Policies Attachments
The Service Registry was delivered as an operational prototype. It has been installed, configured, and demonstrated using GSA Government Furnished Equipment. The Service Registry was populated with GSA FMEA-C services and FEA SCM Taxonomy. GSA FMEA-C Services have been classified according to this taxonomy. JAXR Clients have been built to demonstrate the Service Registry capabilities including, but not limited to, publication of services and WS Policies, discovery of services using standard and advanced search criteria (e.g., use WS Policies, FEA SRM taxonomy, etc.), classification of services against FEA BRM and SRM taxonomies, governance, etc.
Project Results and Benefits
The goal of this project was to enhance GSA’s role as an intermediary in the Federal supply chain. The main benefits that this project provided to GSA are the following:
The publish and find capabilities of the Service Registry can promote service reuse in GSA SOA enterprise applications by providing greater visibility of and easier access to existing services.
Enable enterprise governance by providing:
Access control: GSA can set up access-control rules that align with GSA business.
Service classification: GSA can classify services and related metadata into groups that are meaningful in the domain of the GSA organization and its customers and that align with GSA business needs, e.g., FEA SCM.
Impact analysis: GSA can better understand service relationships and (inter-)dependencies.
Service life cycle: GSA can define and enforce best practices for service life-cycle management with the ability to approve and deprecate services
Policy support: GSA can publish WS-policies that apply to its services. These policies can be enforced by GSA runtime infra-structure, e.g., GSA ESB will discribe how Government policies are published, discovered, and enforced among partners in the Federal supply chain ecosystem, by leveraging this service registry
General Services Administration: Integrated Portfolio Management
The goal of the Integrated Portfolio Management (IPM) project was to develop processes and a concept of operations to drive GSA’s transformation into an enterprise in which investment management strategy, tactics, and decision-making effectively and efficiently help achieve the Agency’s business goals and objectives. The effort considered how the existing Performance Management Process (PMP), Enterprise Architecture (EA), Capital Planning Investment Control (CPIC), Earned Value Management (EVM), and the System Development Life Cycle (SDLC) processes could be effectively integrated in an architecture-driven management approach. Originally entitled the Integrated Information Technology Portfolio Management project, it became clear that achieving the stated goal of the effort necessitated that a wider view be taken, resulting in a renaming of the effort to simply “Integrated Portfolio Management.”
The project employed the Object Management Group’s (OMG) Model Driven Architecture (MDA) set of standards and methods to fully elaborate the processes and concept of operations proposed for IPM. This included business process models using the EDOC Component Collaboration Architecture (CCA) and Business Process Modeling Notation (BPMN) and a conceptual entity model using the Unified Modeling Language (UML). The models produced treat the new IPM processes in the areas of Enterprise Business Management and Portfolio Management within the context of the overall GSA agency enterprise architecture, allowing for complete integration with previous EA work on Financial Management and Acquisition.
Key products from the project included the following.
Organizational Alignment Analysis (OAA). This analysis documents the observations and implications of the current state of GSA’s portfolio management processes based on GSA provided documentation and materials.
Business Process Analysis Model (BPAM). This model, developed using the EDOC CCA notation, formalizes the understanding of GSA’s current state derived through an analysis of the documentation provided and subsequent conversation with process stakeholders.
Organizational Alignment Recommendations (OAR). These recommendations, based on the observations and implications provided in the OAA, provide a foundation for GSA to develop a strategy to move towards a future state in a manner consistent with its organizational goals.
Business Process Model. This model, with equivalent versions developed in the EDOC CCA notation and BPMN, depicts the future state of an integrated portfolio management environment at GSA, based on the OAR. This model describes, in an organization-agnostic way, what activities need to be carried out and what artifacts produced in order to achieve the goal of IPM.
Concept of Operations. The Concept of Operations describes the realization of the Business Process Model within the framework of GSA’s organizations. It proposes roles and responsibilities for key organizations for carrying out future state processes and recommends a unified approach to governance to assure the successful application of IPM policies. The Concept of Operations is also supported by a model with versions developed in both EDOC CCA and BPMN that shows the allocation of work roles defined in the Business Process Model to organizations.
Methodology. The Methodology includes supporting material on how to carry out the activities defined in the Business Process Model, in the context of the Concept of Operations. This includes documentation of all artifacts produced in all IPM processes and supporting guides on Enterprise Architecture, Technical Architecture and Architecture-Based Acquisition, as well as a complete Glossary of terms tied to the conceptual information model.
Web Collateral. The recommendations, models, concept of operations and methodology are all highly inter-related and mutually supporting. The Web provides a natural technology for more effectively presenting this inter-linked material than flat text documents. The Web Collateral, developed in addition to the documents delivered, thus allows for easier exploration of the large amount of material produced, supporting stakeholder training and communication to promote understanding of the proposed target IPM environment.
Project Results and Benefits
The result of the project is an architectural and decision-making framework designed to advance GSA’s business needs and organizational strategic objectives. The proposed framework provides the means for optimizing the planning for information technology (IT) and non-IT assets and investments and the use of existing project and program resources. This is achieved through architecting, selecting, monitoring, and evaluating technology in support of business needs and enterprise business strategy, while identifying opportunities to improve services to customers, reduce costs and duplication, and support the shared use of information and solutions within GSA and across the Federal Government. This proposed approach has attracted attention across GSA and up to the Office of the Administrator, providing a strong foundation for the continuing effort at GSA to ensure that the agency thrives in its mission within the Federal government.
General Services Administration: Contract Writing Enterprise Architecture
The objective of the CWEA project was to assist the GSA OCIO, OCAO, Public Buildings Service (PBS), and Federal Supply Service (FSS) organizations in further elaborating the One GSA EA within the Acquisition discipline. After completion of the CIM business models, the project stakeholders decided to redirect the team's efforts away from the PIM and PSM, towards their more pressing need for a gap analysis between the CIM, the Comprizon contract writing system and the FSS Solicitation Writing System.
This project utilized the Object Management Group’s (OMG) Model Driven Architecture (MDA) set of standards and methods to fully elaborate the Solicitation Writing function in GSA.
In this project, DAT, using both Component-X (DAT’s OMG EDOC standards-based modeling tool) and UML, specified a target business model for Acquisition as a refinement of the One GSA architecture. This included:
Normalize the business process and target architecture across the organizations. The project team utilized a MDA-based approach to create a “top down” business focused vision by analyzing the Federal Acquisition Regulations, the Acquisition System Requirements, and a variety of other documents, interviewing subject matter experts (SMEs), and identifying the primary solicitation writing business services that PBS and FSS require for solicitation writing.
Develop the Solicitation Writing target architecture. The project team utilized a MDA-based approach to developing the Acquisition EA. Initially, with the assistance of team and GSA SMEs, the team developed a detailed business process model and conceptual business information model as a computation-independent model (CIM). These included all Acquisition functionality including Requirements Definition, Acquisition Planning, Solicitation Writing, Response Evaluation, Contract Award, etc. The team then drilled down into Solicitation Writing to fully specify its activities and conceptual information. The team validated the models with GSA SMEs.
Refine the One GSA architecture. Under DAT’s leadership, the project team updated and integrated the EA developed in this project with the One GSA EA, which includes FMEA. The team identified conceptual mismatches in the acquisition-related areas of the FMEA conceptual information model and made recommendations to further refine the FMEA conceptual information model.
Develop business requirements as part of the target architecture. The project team reverse engineered the purpose behind system requirements in the FSS Solicitation Writing System (SWS) and the Acquisition System Requirements (ASR) documents to create business requirements and supporting business rules using the vocabulary developed in the conceptual business information model. The team mapped those validated requirements to the business process model, mapped those requirements to the Solicitation Writing System Use Cases, and then, with the assistance of CACI, the Comprizon system vendor, mapped those requirements to the Comprizon system functionality. The team validated all of the business requirements and mappings with GSA SMEs. The level of detail required for success of this project necessitated involving, through interviews and work sessions, both business and technical GSA management staff who are engaged in or can affect the acquisition processes in GSA.
Project Results and Benefits
This project has provided the OCIO, the OCAO, PBS, and FSS with a detailed, normalized target architecture of the Acquisition discipline, especially within Solicitation Writing. It has also provided them with a list of gaps between the target architecture, Comprizon, and SWS. These organizations now know exactly what the current functionality of these systems is, why Comprizon was insufficient for writing schedule solicitations, as well where opportunities for further automation exist.
General Services Administration: Financial Management Enterprise Architecture and Line-of-Business
The General Services Administration (GSA), Office of the Chief Information Officer (CIO) and Office of the Chief Financial Officer (CFO) are developing a Financial Management line of business (FM LoB) to fully support the requirements of GSA and, potentially, other Government agencies. This project fully supports that effort in that it elaborates in detail the Financial Management Value Chain developed as part of the One GSA enterprise architecture (EA). The target is to be able to migrate from their legacy accounting systems to a modernized SOA platform that supports the business requirements of GSA and complies with federal financial standards.This project utilizes the Object Management Group’s (OMG) Model Driven Architecture (MDA) set of standards and methods to fully elaborate a servie oriented archtiecture (SOA) for the Financial Management function in GSA.
In this project, DAT, using both Component-X (DAT’s OMG EDOC standards-based modeling tool) and UML, specified a target business model, set of business processes, and supporting enterprise application components for financial management as a refinement of the One GSA architecture. This has included:
- Redesign of the business process and target architecture
- Analyze the FM legacy environment
- Develop FMEA target architecture
- Refine the One GSA architecture
- Prepare a sequencing plan and Business Case
The level of detail required for success of this project necessitated involving, through interviews and work sessions, both business and technical GSA management staff who are engaged in or can affect the financial processes in GSA. In addition, the team is interacting with the OCIO Enterprise Architecture Project Management Office (EAPMO), GSA Information Technology Council (ITC), and GSA Business Systems Council (BSC) as directed by the OCFO and OCIO to apprise them of the project progress in creating an enterprise that is truly One GSA.
Project Results and Benefits
This project is the first full elaboration of the One GSA EA from the top-level business focused CIM down through the component describing PIM and technology focused CIM. As such it provides GSA a model to develop fully elaborated EAs for each of the other major business areas and services.
This project has provided GSA, and especially the OCFO, with a fully detailed description of the functionality of the legacy NEAR system. This should prove invaluable as its functionality (Fixed Assets, Receivables and Billing) are newly implemented under the Financial Management EA.
This project should provide GSA the basis for maintaining its “Green” status with OMB and is being looked at as a template for a line of business service oriented architecture.
General Services Administration: One GSA Enterprise Architecture
The objective of this project was to develop the General Services Administration (GSA) Office of the Chief Information Officer (OCIO) One GSA Enterprise Architecture (EA). GSA has made significant progress developing EA products at the SSO level, but the depth, scope, and documentation varied widely. While GSA has a mature technical architecture that is used throughout the agency, GSA did not have a complete agency-level EA that would identify common business processes that could be shared across GSA business lines.
The One GSA EA consists of an agency-wide as-is EA, to-be or target EA, and sequencing plan (business modernization blueprint). Value-chain analysis (VCA) was used as a basis to engage business line subject-matter experts (SMEs) in discussions about their business processes and the data that support them. Some of the earlier EA projects did not explicitly use VCA but used a customer-focused approach to define business processes. One of the purposes of the One GSA EA project was to use VCA across the agency to normalize the large amount of existing EA information that has been generated during the past 4 years.
Throughout the organization, GSA has generated, through a number of previous EA efforts, vast amounts of unstructured EA data. Business processes have often been documented using a variety of office automation tools (Power Point, Visio, etc.) that have limited utility to those not closely associated with the particular project, and are difficult, at best, to update and maintain. This had resulted in a “paper tiger” EA.
GSA has now embraced the use of the Object Management Group’s (OMG) Model Driven Architecture (MDA) set of standards. This comprehensive business-to-model-to-execution paradigm has allowed GSA to overcome execution, simulation and documentation deficiencies of the previous paper EA work. MDA is a set of cohesive industry standards that provide for an EA semantic that expresses a business process- and service-oriented grammar, and makes the GSA EA more actionable. Key among these standards is Enterprise Distributed Object Computing (EDOC) which provides the basis for the tooling GSA has selected for its modeling environment: Component-X. Component-X was developed, is maintained and is owned by DAT.
The models developed in Component-X provide a business, role and collaboration view of GSA. This view has proved critical in validating the business requirements of the key business and support organizations that make up GSA.
One of the key accomplishments of the One GSA project was to create EDOC models that enable the simulation of business processes directly.
The One GSA EA method can be summarized as VCA + MDA on SOA = the One GSA EA.
At the conclusion of the project, GSA has developed an agency-wide target architecture using a consistent, standards-based method and tooling.
Project Results and Benefits
The “One GSA” EA will be the foundation for GSA to deliver its services effectively and efficiently now and in the future. The One GSA EA is a top down approach that forces technology decisions to be driven by business strategy. The One GSA EA will enable and facilitate process changes that will:
- make GSA easier to do business with
- reduce costs by eliminating duplicate systems
- reduce the costs of maintaining legacy systems and allow their replacement over time
- ensure continual alignment of technology investments to business processes
- improve GSA’s service performance levels
- promote the sharing of common services across the GSA
- provide a commonly understood point of departure for future strategic analyses
The One GSA EA is defined as a set of products that describe the current and desired relationships among and between GSA’s business lines and the IT that supports those relationships. The One GSA EA is a strategic asset that supports activities, such as strategic planning, performance measurement, human capital planning, competitive sourcing, and IT capital planning.
One GSA, as modeled in Component-X, supplies a full mapping to the various reference models (Performance, Business, Service and Technical – Data not having been released at the time) developed by OMB in support of the Federal Enterprise Architecture (FEA).
The One GSA project enabled the GSA OCIO to “Get-to-Green”.
National Archives and Records Administration: Functional Requirements and Attributes for Records Management Services
At the end of 2005, the National Archives and Records Administration (NARA) issued a report, jointly published by 18 Federal government agencies, entitled Functional Requirements and Attributes for Records Management Services. This report was the result of a year-long effort by these agencies as a community of interest in the area of records management. During this time, agency representatives first identified and described eight proposed records management activities supportable by software service components. Then, a subset of the group, along with NARA subject matter experts, held a series of workshops and meetings to produce a set of functional requirements and attributes in use case format. DAT participated in one of these workshops, providing expertise on the specification of service-oriented components, as part of a focus group of industry representatives.
Subsequently, NARA issued a formal Request for Information seeking comments on the draft functional requirements. A number of comments from this process were addressed in revising the draft requirements document, including a recommendation to produce Unified Modeling Language (UML) models to better document the attributes and data elements referenced in the use cases. DAT was asked to produce these models, present them to the inter-agency team, and incorporate the resulting comments. We developed a UML class model was developed for each of the seven major service areas described in the report, and the corresponding class diagrams are included as an appendix to the final report.
Project Results and Benefits
This NARA-lead effort has been exceptionally successful in facilitating a consensus between a large number of Federal agencies. The resulting report provides a shared vocabulary for records management, grounded in statute and regulation, and a common understanding of the essential requirements for supporting records management services. This will enable the consistent handling and exchange of records management information in pursuit of common goals, interests and business objectives across all the agencies involved -- and, perhaps, further across the Federal government and beyond.
The UML models developed by DAT as part of this project have been very well received. They are a first step toward further formalizing the consensus understanding reached during the project. DAT is now continuing to work with NARA representatives to write an Object Management Group (OMG) Request for Proposals for a complete Model-Driven Architecture (MDA) specification for components satisfying the requirements documented in the inter-agency report. Such a specification will provide a full set of process, behavior and data models for records management, which, once adopted by OMG, will be the first complete, cross-platform, service-oriented industry standard for records management.
General Services Administration: Open Source eGovernment Reference Architecture
OSERA is envisioned as a full actualization of the OCIO vision of the capabilities of One GSA: MDA + VCA on SOA = One GSA. But it is even more than that because it includes the longer term vision of providing a development and testing environment that could be effectively used across all of Government.
More specifically, OSERA is an OMG Model Development Architecture (MDA)-based development environment to enable the full life cycle of IT and application solutions that support GSA’s and the Government’s business objectives. As such, it spans everything from business requirements and capital planning to the runtime execution of solutions.
Technically, OSERA is being built on an evolving Open Source code/model base as a subset/plug-in to Eclipse. It utilizes a Services base (SOA) and will reside upon GSA’s Enterprise Service Bus (ESB).
It provides for the integration of the MDA standards and processes with the developing ontological based Semantic Web. It is being built on what is being called a “Semantic Core”.
Functionally it will support:
- Business Requirements Modeling that will capture requirements, responsibilities, plans and value chains at a high level. These will then be further elaborated through the MDA “stack”: detailed CIM, PIM and PSM, eventually to be deployed into a runtime execution platform.
- Structural Modeling capabilities that will support a number of modeling tools. The first iteration of tooling support targeted includes an extended version of Component-X supporting what is called EDOC++, Systems Architect and the Web Ontology Language (OWL). The goal here is to allow the interchange of models so that they may be viewed from a variety of “angles”.
- Ontological Modeling capabilities based on OWL that will allow the management of the vocabularies of architectures and assist architects in understanding and integrating those architectures. The target here is to have knowledge engineers enable the environment with an integrated set of extensible controlled domain vocabularies. Architects will be able to ground their architectures in this controlled vocabulary and use tools to transverse, query, integrate and understand these architectures.
The entire OSERA development environment will be grounded in a Meta Object Facility (MOF) and will support robust provisioning, transformations and versioning. Current web-based technologies (JBoss, BPEL, Java, XML, XMI, SOAP, etc.) are being used to build this model-based IDE.
DAT is the architect and major implementer of this project.
Project Results and Benefits
DAT has played the leadership role on both phases of OSERA. The first phase delivered a high-level model of the entire OSERA environment, both technological and business. This model provides detailed information that allows GSA to prioritize the “next steps” in building the entire infrastructure.
The current phase is targeting a “prototype” of some of the key elements of the OSERA platform. This prototype includes elements of the runtime and provisioning capabilities. It is planned that some of these capabilities will be demonstrated on November 15 at the OMG eGovernment Special Interest Group meeting being hosted by GSA and the National Archives and Records Administration.
Once fully realized, which is dependent upon additional funding and the continued support of GSA – and potentially others – OSERA will provide GSA and the Federal Government a full life cycle information technology modeling, development and management environment that is driven by the user’s business requirements.
US Army: MDA and Strategic Planning for PEO-STRI
PEO-STRI is reinventing itself to become more agile, effective, and customer focused. Integrated and interoperable solutions for simulating and training must be provisioned quickly and efficiently from a library of solution and technology components that can be composed to create targeted solutions to support the objective force warfighter.
The agility required for the objective force warfighter, combined with reduced resources and timelines, requires current methods for simulating and training be rethought. Multi-year development of stovepipe software solutions is not an option, solutions must be assembled from libraries of components that can be “plugged together” to provide solutions on demand. This project was to define the technology base and business plan to transform PEO-STRI into the organization capable of achieving these goals and delivering training and simulation solutions forthe objective force. The focus of the project is on a “model-driven component architecture”–
combining plug-and-play components with the power of a full life-cycle model based method.
The technical goal is to within 3 years have PEO-STRI products composed of 80 percent reusable common components.
The business goal is to within 3 years have PEO–STRI leading in technology and solutions in the armed services.
As part of this project, DAT collected existing information and interviewed both strategic and technical leadership in PEO-STRI. DAT participated in value method workshops and product design sessions that produced a plan for a model-driven-architecture- (MDA-) based “solutions factory,” which will reorient STRI deliverables into interoperable and reusable components. The current divisions between simulation domains and between simulations and tactical systems will be replaced with well-defined contracts between enterprise-scale components. The architectural focus embraces open standards, particularly those of the Object Modeling Group, including the EDOC enterprise collaboration architecture, Unified Modeling Language, and meta-object facility. DAT showed how to bring these standards together to support PEOSTRI’s strategic goals.
As part of our analysis, we identified the business drivers and organizational changes needed to embrace these goals and presented a plan for transforming the organization.
Project Results and Benefits
We defined and delivered a strategy and approach for applying MDA to achieve common components for all PEO STRI’s product lines. We also defined an architecture and approach for interoperability across simulation and tactical systems supporting joint network-centric warfare. In addition, we increased PEO-STRI’s ability to evolve and adapt domain models, rules, and processes.