1. Copyright © 2008 Model Driven Solutions. Model Driven Enterprise Architecture for Government OMG's Government Information Days Cory Casanave cory-c (at) modeldriven.com March 2008 A division of Data Access Technologies, Inc.

2. Copyright © 2008 Model Driven Solutions. Does the Government need Model Based Architectures? And what does MDA add to “classical” modeling? And Why Models are not Diagrams. What is the Modeling thing Anyway?

3. Page 3Copyright © 2008 Model Driven Solutions Why “Paper Architectures” don’t cut it Complexity –Government problems are to large, interrelated and complex for an ad-hoc approach. Engineering discipline is required. Maintenance –Paper and PowerPoint architectures have to be manually evolved and kept in-sync. Result is that few such architectures are consistent Analytics –Paper architectures can’t be validated, simulated or analyzed with any automated information processing capability Derived Value –The value of paper architectures ends with a fuzzy warm feeling – there is no way to turn them into actionable results Repurposing –Information in a paper architecture is “trapped”, there is no way to repurpose or evolve it for other needs or stakeholders.

4. Page 4Copyright © 2008 Model Driven Solutions Why Architecture & Modeling? Life-cycle What is to be achievedHow models helps Setting Agenda Start with some agenda, initiative or goal Coming up with the goals is a human process, models can help capture the results & reasons Planning There is some plan or architecture to achieve it Rendering a plan as a model makes it easier to evolve, relate and actualize. Validation The plan is validated with facts and analytics Tools can be used to help validate and simulate the model, showing that it can work and have the desired effects. Communication The plan is communicated to get buy- in, support and/or consensus Models serve as a reliable communications mechanism Actualization The plan is executed – made to happen Information in MDA® models can be repurposed as acquisitions (MBA), workflows, specifications or technology implementations Evaluation Plan metrics are compared with reality – may result in a new agenda Tools can compare measured results with assumption for testing and analytics

5. Page 5Copyright © 2008 Model Driven Solutions Actionable Enterprise Architecture Architecture Models Time Line Trends Critical Success Factors Time Line Trends Critical Success Factors Simulation & Test Business Models Workflow SOA Interoperability Contracts Information Management Documentation &Training Business Drivers Current Processes FAR Current Systems Trends Initiatives Business Services Information Models Implementation Technology Finances

6. Page 6Copyright © 2008 Model Driven Solutions Point solutions don’t work either Many Solutions – “I have a product for that” –Business Processes –Service Oriented Architecture –Information & Data –Business Rules –Governance & Compliance –Acquisition –Analytics –Budgeting –Vocabularies and Ontologies All about the Same Enterprise –We can’t treat these as stovepipes, aspects of the enterprise architecture are interrelated –We can’t use stovepipe solutions to solve stovepipe problems Enterprise solutions require longevity, scope and interoperability

7. Page 7Copyright © 2008 Model Driven Solutions Model Driven Enterprise Architecture Focus on Pervasive Problems Collaboration –Federation & Integration of People, Organizations and Systems –It’s a connected world. Connect! Agility –Being able to address problems and take advantage of opportunities quickly and effectively. –Remain relevant, transform, evolve! Costs –Reduced development & Operating budgets are the norm. –Reduce Redundancy. –Do more with less!

8. Page 8Copyright © 2008 Model Driven Solutions Enterprise SOA Applying Enterprise MDA to SOA at the Enterprise level Enterprise SOA Integrates –Business and Operations Viewpoints – The Business SOA A lattice of business services cooperating for a mission – about the business, the mission and the operation – not about the technology. Includes roles & processes of stakeholders inside and outside an organization. –Technology Viewpoints – The Technical SOA A lattice of technology components, serving the business and the mission – based on the business SOA. Includes services inside and outside the technical environment. Enterprise SOA –Puts the business and mission first, defines technology based on business goals, drivers and processes. –Provides a solid system of systems technical architecture independent of technology –Produces technology specifications and implementations that collaborate based on the SOA architecture

9. Page 9Copyright © 2008 Model Driven Solutions Example Enterprise Level Services

10. Page 10Copyright © 2008 Model Driven Solutions The Service Oriented Enterprise –Parts of the enterprise must be independent & loosely coupled –While being able to interoperate with each other using services –Making the enterprise a lattice of cooperating services SOA Enterprise Components –Enterprise Components must be independent & loosely coupled –While being able to interoperate with each other using services –Making the information system a lattice of cooperating components Service

11. Page 11Copyright © 2008 Model Driven Solutions Service Trust and Validation Clear, Trusted and Validated Service Effects Under All Conditions Service Contract

12. Page 12Copyright © 2008 Model Driven Solutions FMEA Example US Federal Government General Services Administration GSA Office of the Chief Financial Officer One GSA EA Federal EA FMEA Financial Management Line of Business

13. Page 13Copyright © 2008 Model Driven Solutions U.S. GSA Transition To A Federated Environment* Enterprise Solutions GSA Construction Space Assignment and Leasing Infrastructure Policy HR Finance Marketing Multiple Customer Perspectives Physical Bldg Maintenance PBS Telecom IT Acquisitions Global Supply FTS Fleet Acquisition Fleet Management E-Travel Personal Travel Freight Transport FSS FAS Current Solutions One Customer Perspective * Based upon the One GSA Enterprise Architecture approach which provides a unified set of business services with supporting shared services. One GSA EA is intended to be a primary enabler of the Presidents Management Agenda (PMA), the Federal Transition Framework, and the ongoing demand from GSA customers to provide unified and customer focused services. The transition, as demanded by GSA’s customers, is to present GSA services as a unified solutions framework supported by vertical horizontal lines of business. DOD Agencies GSA General Supplies and Services OCAO OCFO OCIO OCHCO Staff Offices Construction Space Assignment and Leasing Physical Bldg Maintenance Integrated Technology Services Assisted Acquisition Services Travel, Fleet, and Card Services One-GSA Solutions Focus

14. Copyright © 2008 Model Driven Solutions. See More Thursday To see in more detail how to do Enterprise MDA with SOA, Attend the tutorial Thursday Summary of Example

15. Page 15Copyright © 2008 Model Driven Solutions Business Concerns Goals Policy Customers Costs Agility Technology Specification JMS, JEE, Web Services WSDL, BPEL, XML Schema Technology Specification JMS, JEE, Web Services WSDL, BPEL, XML Schema Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data Business Focus Using Model Driven Architecture One GSA/FMEA Business Model Enterprise Services (e-SOA) Roles, Collaborations & Interactions Process & Information One GSA/FMEA Business Model Enterprise Services (e-SOA) Roles, Collaborations & Interactions Process & Information Refinement & Automation Line-Of-Sight Computation Independent Model Platform Independent Model Platform Specific Model MDA Terms

16. Page 16Copyright © 2008 Model Driven Solutions Incorporating Legacy Analysis

17. Page 17Copyright © 2008 Model Driven Solutions Value derived from the architecture Component Acquisition Specification Technology Interfaces Test & Simulation OMB 300 FEA/FTF BRM SRM DRM* Business Driven Technology Facilitating Business Processes Adapters Components DataDeployment

18. Page 18Copyright © 2008 Model Driven Solutions Focus on the Business Model Business Concerns Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data One GSA/FMEA Business Model Business Services (e-SOA) Roles, Collaborations & Interactions Process & Information

19. Page 19Copyright © 2008 Model Driven Solutions The enterprise as services Think about the enterprise as a set of interacting roles providing and using services to enable agility, cost savings and an effective transition framework Externally –The enterprise is part of the global supply chain, providing services to customers and using the services of suppliers Internally –Consider parts of the enterprise as providing services to other parts of the enterprise, and in term using the service of others –Like everything was outsourced as a service, it just happens to be done inside the organization. Business is modeled in terms of interacting roles – providing and using services – the essential concepts of enterprise SOA

20. Page 20Copyright © 2008 Model Driven Solutions Financial Management Enterprise Context External enterprise level participants The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants. This is the use of A service contract specification This is the use of A service contract specification Our Focus

21. Page 21Copyright © 2008 Model Driven Solutions Financial Management Enterprise Context External enterprise level participants The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants. This is the use of A service contract specification This is the use of A service contract specification Our Focus

22. Page 22Copyright © 2008 Model Driven Solutions Enterprise Services can be Complex Financial Management is responsible for providing a number of Acquisition Accounting services.

23. Page 23Copyright © 2008 Model Driven Solutions Receivables Management Activities Workflow is modeled using UML Activities. Received event Activity Sent event Information flow

24. Page 24Copyright © 2008 Model Driven Solutions Information Model This means “zero or more” This means “one or more” This indicates a compositional (as opposed to referential) association. This is a constraint that defines the sub-classification. A term in the vocabulary represents a class of things to be described. Attributes specify descriptive information having simple types. Entities may be described as having a unique identity. A relation between terms is described by an association between classes. A class may be specialized into sub- classifications. An un-shaded class is not detailed on this diagram.

25. Page 25Copyright © 2008 Model Driven Solutions Information Model: What Is It For? Business transaction The information model details the vocabulary of the business entities and transactions used in the process model. The process model describes how business activities are (or are to be) carried out. State changes due to the activities Workflow Activities Implicit memory of business information

26. Copyright © 2008 Model Driven Solutions. CIM Summary The CIM is a model of the business, not the information system

27. Page 27Copyright © 2008 Model Driven Solutions Business Concerns Producing the logical model Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data One GSA/FMEA Business Model Business Services (e-SOA) Roles, Collaborations & Interactions Process & Information

28. Page 28Copyright © 2008 Model Driven Solutions FMEA Systems Architecture (High Level)

29. Page 29Copyright © 2008 Model Driven Solutions From Business Architecture to System Architecture Financial Management Discipline Protocols Enterprise Roles Work Roles Activities Information Model Classes Financial Management Discipline Protocols Enterprise Roles Work Roles Activities Information Model Classes Core Financial System Specification Service Interfaces Work Components Service Manager Components Behavioral Specifications Message Specifications Data Manager Components Persistent Data Specifications Core Financial System Specification Service Interfaces Work Components Service Manager Components Behavioral Specifications Message Specifications Data Manager Components Persistent Data Specifications Business Architecture Logical System Architecture

30. Page 30Copyright © 2008 Model Driven Solutions Service Interfaces from Service Contracts The Participant Types act as the Service Interfaces.

31. Page 31Copyright © 2008 Model Driven Solutions Receivables Management Component Architecture Explicit component for scheduling triggers Explicit cross- transactional coupling via the data tier Implements the Establish Customer Order activity. Implements the Generate Recurring Receivable and Establish and Accrue Revenue activities.

32. Copyright © 2008 Model Driven Solutions. PIM Summary The PIM is a model of the system and how it realizes the business requirements, but the technology decisions and details are abstracted out

33. Page 33Copyright © 2008 Model Driven Solutions Business Concerns Technology Architecture Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data One GSA/FMEA Business Model Business Services (b-SOA) Roles, Collaborations & Interactions Process & Information

34. Page 34Copyright © 2008 Model Driven Solutions Core Financial System Specification Service Interfaces Enterprise Components Work Components Service Manager Components Behavioral Specifications Data Model Message Specifications Data Manager Components Persistent Data Specifications Core Financial System Specification Service Interfaces Enterprise Components Work Components Service Manager Components Behavioral Specifications Data Model Message Specifications Data Manager Components Persistent Data Specifications Platform Specific Model Core Financial System Implementation Web Services Enterprise Information Systems System Components System Functions Data Definition XML Schemas Data Bases Data Base Schemas Core Financial System Implementation Web Services Enterprise Information Systems System Components System Functions Data Definition XML Schemas Data Bases Data Base Schemas Platform Specific Model (PSM)Platform Independent Model (PIM)

35. Page 35Copyright © 2008 Model Driven Solutions Derived Value – Technology Interfaces public class Asset_Record_Establishment_ProviderAsset_Record_Establishment_Provider_InterfaceInternal { …… static public Document establish_asset_record(Document request) throws CheckedException { … // for an inbound operation, determine if we delegate or execute return gov.gsa.fmea.Asset_Record_Establishment_Transaction_Manager. Asset_Record_Establishment_ProviderAsset_Record_Establishment_Provider_InterfaceInternal. establish_asset_record(request); public class Asset_Record_Establishment_ProviderAsset_Record_Establishment_Provider_InterfaceInternal{ … static public Document establish_asset_record(Document request) throws CheckedException { … // for an inbound operation, determine if we delegate or execute return ServiceFactory.getPipeline("Asset_Record_Establishment_Transaction_Manager. Asset_Record_Establishment_Provider.establish_asset_record.Pipeline").execute(request); }

36. Page 36Copyright © 2008 Model Driven Solutions Example Transaction Message XML Document … … … … … … … … … … … …

37. Page 37Copyright © 2008 Model Driven Solutions Derived Value – Generated Components public class Asset_Completion_Establishment_ConsumerAsset_Completion_Establishment_Provider_InterfaceInternal { … static public Document establish_asset_completion(Document request) throws CheckedException { …… return gov.gsa.fmea.Asset_Record_Manager. Asset_Completion_Establishment_ProviderAsset_Completion_Establishment_Provider_InterfaceInternal. establish_asset_completion(request); }

38. Page 38Copyright © 2008 Model Driven Solutions End result – this executes Service representing delegated responsibility for interaction with an external participant. Service representing interaction with another participant within Financial Management. Roles of participants inside of finance

39. Page 39Copyright © 2008 Model Driven Solutions On this infrastructure

40. Page 40Copyright © 2008 Model Driven Solutions What Does the FMEA Example Show? FMEA is a general architecture of the federal financial services domain, done for GSA by Model Driven Solutions. It supports both internal GSA needs as well as the “line of business”. It uses MDA, SOA and BPM to provide a business centric architecture, drilling down to technology models. Artifacts can be generated for model based acquisition, the FEA, testing, service interfaces, data management, workflow and components. FMEA is entering the next phase of acquisition and implementation. All assets to produce this application are being donated to ModelDriven.org as open source.

41. Page 41Copyright © 2008 Model Driven Solutions Model Driven Enterprise Architecture Architected Solutions Summary Enterprise Architecture as the Architecture of the Enterprise –Focus is on how the enterprise provides value and operates. –I.T. Systems are one aspect of the equation Supported by cross-functional models –Crucial enterprise knowledge can’t be trapped in proprietary tools and stovepipe solutions. Encompass Services, Rules, Processes, Information, Governance, Budget… Repurpose Enterprise Knowledge for Leverage –Enterprise Planning –Enterprise Transformation –Model Based Acquisition –Process Reengineering –Knowledge acquisition., management and dissemination –I.T. System Specification and Implementation Federating people, Organizations & Systems