1. Orientation to the Potentials and Realities of SOA, In Light of the DRM 2.0 and OASIS Service-Oriented Architecture Reference Model (SOA-RM) Joseph Chiusano Rebekah Metz Chris Porch Booz Allen Hamilton Collaboration Expedition Workshop Washington, DC January 24, 2006

2. 1 Table of Contents  Orientation to Service-Oriented Architecture (SOA)  What is a Reference Model?  The OASIS Service-Oriented Architecture Reference Model (SOA-RM)  The OASIS SOA Adoption Blueprints TC  Relating the OASIS SOA Reference Model and the FEA Data Reference Model (DRM)  Questions

3. 2  Orientation to Service-Oriented Architecture (SOA)  What is a Reference Model?  The OASIS Service-Oriented Architecture Reference Model (SOA-RM)  The OASIS SOA Adoption Blueprints TC  Relating the OASIS SOA Reference Model and the FEA Data Reference Model (DRM)  Questions Table of Contents

4. 3 Key Enablers: People, Process, IT and Physical Infrastructure Information Technology (IT) enables an organization to achieve its mission People (e.g., organization structure, human capital) Business Processes IT (e.g., systems) Physical Infrastructure (e.g., facilities, workplace environment) Goals Objectives Services Strategy selection Value Proposition development Long term vision alignment Critical success factors for customers and service offerings Specific definition functional performance Mission Strategies Value Propositions Capabilities

5. 4 IT is not growing toward an organization’s mission However, current IT architectures do not fully support changing needs Agility  IT assets cannot be quickly repositioned in response to strategic decisions  Decision cycles are unnecessarily lengthened by data stovepipes  More demand for intra- and inter-organization information sharing  IT assets cannot be quickly repositioned in response to strategic decisions  Decision cycles are unnecessarily lengthened by data stovepipes  More demand for intra- and inter-organization information sharing Process  Systems and organizations duplicate work  Data used across an organization is often inconsistent and potentially inaccurate  Information stovepipes require point-to-point integrations that limit flexibility and create maintenance overhead  Systems and organizations duplicate work  Data used across an organization is often inconsistent and potentially inaccurate  Information stovepipes require point-to-point integrations that limit flexibility and create maintenance overhead Interoperability  More time spent patching systems together than adding mission critical capabilities  Difficult to determine “what exists” and “what data means” fosters duplicate applications and data  Inability of applications to interoperate due to platform incompatibility  More time spent patching systems together than adding mission critical capabilities  Difficult to determine “what exists” and “what data means” fosters duplicate applications and data  Inability of applications to interoperate due to platform incompatibility Costs  Integrating data stovepipes is expensive and wasteful  Operations and maintenance costs are a rising percentage of the budget  Duplicate data entry and manual data reconciliation create higher labor costs  Integrating data stovepipes is expensive and wasteful  Operations and maintenance costs are a rising percentage of the budget  Duplicate data entry and manual data reconciliation create higher labor costs Lack of agility, process redundancy, inefficient system interactions, and increasing costs

6. 5 SOA is an approach to organizing and using IT to match and combine needs with capabilities in support of the overall mission of an enterprise Capabilities performed by one for another to achieve a desired outcome Functionally aligning architecture to enable a collection of independent services to be linked together to solve a business problem The fundamental organization of a system embodied in its capabilities, their interactions, and the environment Architecture Oriented Service The solution: A paradigm that encourages organizations to re-think how their IT capabilities are organized S O A

7. 6 Traditional approach to software architecture Traditional software architecture vs. Service-Oriented Architecture: A simple sandwich-making analogy No Agility to make a new combination quickly A Process that is duplicative and inefficient No Interoperability; difficult to maintain consistency Costly to operate and maintain Agility to create new combinations quickly A Process that is efficient Interoperable; easy to maintain consistency Cost effective to operate and maintain Service-Oriented Architecture Customer goes to a different station for each sandwich Customer goes to one station for all sandwiches “Separate Station” model“Service-Oriented” model Sandwich maker selects from ingredients according to the recipe

8. 7 SOA benefits uniquely address a rapidly changing environment Agility  Focus more on core competencies and missions by creating a network of producers- suppliers with intense interactions  Improve access to information to enable faster cycle times  Enable enterprises to be more agile and respond quickly to business needs  Focus more on core competencies and missions by creating a network of producers- suppliers with intense interactions  Improve access to information to enable faster cycle times  Enable enterprises to be more agile and respond quickly to business needs Process  Increase business flexibility through plug- and-play architecture and re-use of existing services  Ensure system change is not a constraint on business or mission change  Allow interoperation with other systems & partners without customization  Increase business flexibility through plug- and-play architecture and re-use of existing services  Ensure system change is not a constraint on business or mission change  Allow interoperation with other systems & partners without customization Interoperability  Facilitate integration with multiple solutions via open IT standards  Remain platform, language, and vendor independent to remove IT barriers for using best-of-breed software packages  Facilitate integration with multiple solutions via open IT standards  Remain platform, language, and vendor independent to remove IT barriers for using best-of-breed software packages Costs  Reduce development costs by acquiring pre-built capabilities  Leverage previous IT investments through re-use of assets  Lower maintenance costs and TCO through fewer “instances” of a function, and fewer software licenses  Reduce development costs by acquiring pre-built capabilities  Leverage previous IT investments through re-use of assets  Lower maintenance costs and TCO through fewer “instances” of a function, and fewer software licenses IT alignment with an organization’s mission Improved agility, focus on core competencies, IT efficiencies, and ROI for IT assets

9. 8 The potential of SOA: Shape today’s capabilities to fit tomorrow’s needs The Iron Bridge, Ironbridge, UK Source: http://en.wikipedia.org/wiki/Image:Iron_Bridge.JPG

10. 9 Table of Contents  Orientation to Service-Oriented Architecture (SOA)  What is a Reference Model?  The OASIS Service-Oriented Architecture Reference Model (SOA-RM)  The OASIS SOA Adoption Blueprints TC  Relating the OASIS SOA Reference Model and the FEA Data Reference Model (DRM)  Questions

11. 10 What is a Reference Model?  A reference model is: –A framework for understanding a domain –Based on a small number of unifying concepts –A representation of significant relationships among the entities of the domain –Not tied to specific standards and technologies  The FEA consists of a set of interrelated reference models –Data Reference Model (DRM) 2.0 approved by OMB in December 2005  More concrete reference architectures can be produced from a reference model  Example: A “housing” reference model would include the concept of “eating area”, while a housing reference architecture would include a more concrete realization of this concept called “kitchen”

12. 11 Table of Contents  Orientation to Service-Oriented Architecture (SOA)  What is a Reference Model?  The OASIS Service-Oriented Architecture Reference Model (SOA-RM)  The OASIS SOA Adoption Blueprints TC

13. 12 The OASIS Service-Oriented Architecture Reference Model Technical Committee (SOA-RM TC) was chartered in February 2005  Charter: Developing a core reference model to guide and foster the creation of specific service-oriented architectures  Objectives: –Publish a reference model for SOA –Publish one or more reference architectures based on the reference model  Home page: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rmhttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm –See “Documents” section for latest version of specification  Participating organizations include: –Adobe- Computer Associates –BEA - Department of Homeland Security (DHS) –Boeing - Fujitsu –Booz Allen Hamilton- Lockheed Martin An OASIS Committee Draft was approved on 01/09/06

14. 13 The OASIS SOA Reference Model is centered around the notions of “needs” and “capabilities”  SOA is “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains” (OASIS SOA Reference Model Committee Draft)  Entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business –Just as one person’s needs may be met by capabilities offered by someone else  There is not necessarily a one-to-one correlation between needs and capabilities –The granularity of needs and capabilities are driven by the business, therefore they vary from fundamental to complex –Any given need may require the combining of numerous capabilities, while any single capability may address more than one need  Examples: Using a hammer, purchasing a house The perceived value of SOA is that that it provides a powerful framework for matching needs and capabilities, and for combining capabilities to address those needs The perceived value of SOA is that that it provides a powerful framework for matching needs and capabilities, and for combining capabilities to address those needs

15. 14 The following are the principal concepts of the OASIS SOA Reference Model  Central concept: “Service”  “Visibility”, “Interaction”, and “Effect” provide the dynamic perspective for interacting with services

16. 15 “Visibility” refers to the capacity for those with needs and those with capabilities to be able to see each other and interact  This is a key prerequisite for SOA  Those with needs can be referred to as “service consumers”, while those with capabilities can be referred to as “service providers”  Typically accomplished through providing descriptions for such aspects as: –Functions –Technical requirements –Related constraints and policies –Mechanisms for access or response

17. 16 “Interaction” is the activity of using a capability  Interaction is typically mediated by the exchange of messages –The interaction proceeds through a series of information exchanges and invoked actions  All interactions are grounded in a particular execution context  The result of an interaction is an effect (or a set/series of effects)  Interactions may be public or private –Private interactions involve behind-the-scenes implementation details –Public interactions involve a “shared state“ between a service provider and a service consumer

18. 17 The purpose of using a capability is to realize one more “real world effects”  Real world effects are expressed in terms of changes to the shared state between a service provider and a service consumer  The expected effects form an important part of the decision on whether a given capability matches described needs  It is not possible to describe every possible effect that may result from using a capability –A cornerstone of SOA is that one using a capability does not need to know all the details

19. 18 The remaining principal concepts support those concepts discussed thus far in various ways Represents the information needed to use a service (“Visibility”) Set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction A contract represents an agreement between two or more parties regarding use of a service A policy represents constraints or conditions on the use, deployment or description of a service

20. 19 Services are the mechanism by which needs and capabilities are brought together  A service is provided by one entity – the service provider – for use by others  A service is a mechanism to enable access to a set of one or more capabilities  This access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description  The eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider  A service is the union of the static aspects of the service description, contract & policy, and execution context with the dynamics of visibility, interaction and real world effects

21. 20 High-level example of SOA-RM concepts  A federal agency has a capability that it would like to make available to other federal agencies  The federal agency develops and/or leverages one or more services that provide this capability  The agency publishes information about the capability on its Web site that explains in detail various functional and technical aspects of that capability and the services that provide the capability (visibility, service description)  The federal agency engages in interactions with other federal agencies and industry partners via the services (interaction, contract & policy, execution context)  As a result of these interactions, there is a change in the state of one or more entities belonging to the federal agency and/or the federal agencies/industry partners with which it interacted (real world effects) –Example of real world effects: A decrement of inventory level, a change in balance of a financial account

22. 21 SOA and Processes

23. 22 SOA provides a foundation for robust integration of applications, data sources, and business processes Data Server Service Server Application & Data Tier Service Oriented Tier Business Process Acquisition Business Process Human Resources Business Process Grants Management Business Process Customer Service Business Process Budgeting and Forecasting Process & Orchestration Tier Service  Business processes are supported by services, and also represented as services

24. 23 The process-related aspects of interacting with a service are represented by a service’s Behavior Model  Processes can themselves be represented as services  The extent of the Process Model of a service is not completely defined in the SOA Reference Model –It is being left to future work (“Process-Oriented Architecture”) –Represented by the “Process & Orchestration” tier shown earlier  A service interface is comprised of an Information Model and a Behavior Model –The Information Model characterizes all of the information that may be exchanged with a service –The Behavior Model encompasses:  Individual actions invoked against a service  Responses to those actions  Temporal dependencies between those actions  The order(s) in which actions and events associated with service interactions may occur

25. 24 The following depicts the placement of the Behavioral Model within the SOA Reference Model

26. 25 It is envisioned that the OASIS SOA Reference Model will be used as a mechanism for enabling greater interoperability between implementations of service-oriented systems  This will be accomplished through the Reference Model’s standard means of representing and describing those concepts that are most fundamental to service-oriented architectures  The SOA-RM TC anticipates that any design for a system that adopts the SOA approach will: –Have capabilities offered as services as defined by the OASIS SOA Reference Model –Have descriptions associated with services –Be able to identify:  How visibility is established between service providers and consumers  How interaction is mediated  How the effect of using services is understood  The elements required in an execution context to support interaction  How policies are defined and how contracts may be modeled and enforced  The ease with which the above elements can be identified within a given service-oriented system could have significant impact on the scalability, maintainability and ease of use of the system

27. 26 Table of Contents  Orientation to Service-Oriented Architecture (SOA)  What is a Reference Model?  The OASIS Service-Oriented Architecture Reference Model (SOA-RM)  The OASIS SOA Adoption Blueprints TC  Relating the OASIS SOA Reference Model and the FEA Data Reference Model (DRM)  Questions

28. 27 The OASIS SOA Adoption Blueprints Technical Committee was chartered in August 2005  The focus of the SOA Adoption Blueprints TC is on SOA business requirements  Its purpose is to develop, publish, and maintain a set of example business profiles or "adoption blueprints" that serve as generic, vendor-neutral instances of service-oriented solutions for real business requirements  An SOA Blueprint may include: –A vision statement of the business problem to be solved –A business domain model –A description of the affected organizational structure and how the units relate –A business use-case model –A services model (enterprise-level or for a specific project) –Other items  The SOA Adoption Blueprints TC began with multiple contributions, to include the "Generico" blueprint from The Middleware Company

29. 28 The work of the OASIS SOA Adoption Blueprints TC complements that of the SOA Reference Model TC  An SOA Blueprint is leveraged earlier in the SOA lifecycle process than the SOA Reference Model –An SOA Blueprint would be leveraged during the business requirements phase, while the SOA Reference Model would be leveraged during the architecture phase  An SOA Blueprint leverages concepts defined in the SOA Reference Model  An SOA Blueprint contains elements that can be applied to an actual business problem, while the SOA Reference Model is abstract  The SOA Adoption Blueprints TC has agreed to rely on definitions available in the SOA Reference Model

30. 29 The following figure better depicts the relationship between the SOA Adoption Blueprints TC’s work and that of the SOA Reference Model TC

31. 30 A high-level process for generating SOA Blueprints currently exists  This process may be found at the SOA Blueprints TC Wiki: –http://blueprints.jot.com/WikiHomehttp://blueprints.jot.com/WikiHome  The process steps are: –Step 1: Define blueprint business architecture  Cap Gemini’s “Methodology for Service Architecture” has been donated for consideration as the basis for this step –Step 2: Apply best practices, patterns and antipatterns  Infravio has made a contribution in this area –Step 3: Generate requirements document  Requirements document should realize the business goals and embed best practices and pattern  It will provide an implementable, vendor- and technology-neutral road map for SOA implementation  These process steps will be refined during the SOA Blueprints TC collaboration duration

32. 31 Table of Contents  Orientation to Service-Oriented Architecture (SOA)  What is a Reference Model?  The OASIS Service-Oriented Architecture Reference Model (SOA-RM)  The OASIS SOA Adoption Blueprints TC  Relating the OASIS SOA Reference Model and the FEA Data Reference Model (DRM)  Questions

33. 32 The Data Reference Model (DRM) is one of the five FEA reference models  The DRM is a framework that supports data architecture, data management, and data sharing  The primary purpose of the DRM is to enable information sharing and reuse across the federal government via the standard description and discovery of common data and the promotion of robust data management practices  The DRM is comprised of three “standardization areas”:  DRM 2.0 was released by OMB in December 2005 –DRM Management Strategy is in OMB review Data Sharing Query Points and Exchange Packages Data Description Data and Data Assets Data Context Taxonomies Source: DRM 2.0

34. 33 DRM 2.0 describes the use of Data Access Services for the implementation of data access capabilities  Examples of such services are: –Data Query Services: Enable a user, service or application to directly query a repository within a collection –Content Search and Discovery Services: Enables free text search or search of metadata contained within the documents in a repository –Context Awareness Services: Allow the users of a collection to rapidly identify the context of the data assets managed by a Community of Interest (COI)  Due to the DRM’s incorporation of services, as well as its various service-related aspects (e.g. Exchange Package), it is possible to relate the DRM and SOA-RM by mapping across concepts  Such a mapping can combine the strengths of both reference models, to enable “service- oriented information sharing”  4 mapping scenarios will be presented

35. 34 Scenario #1: DRM supports representation of SOA-RM’s Information Model SOA-RM’s “Interaction” Concept Group DRM’s “Data Description” Standardization Area is-represented-according to

36. 35 Scenario #2: SOA-RM’s “Service” is categorized according to the DRM’s representation of context SOA-RM’s Principal Concept Group DRM’s “Data Context” Standardization Area categorizes

37. 36 Scenario #3: Access to DRM’s “Data Asset” is enabled through SOA-RM’s “Service” SOA-RM’s Principal Concept Group DRM’s “Data Context” Standardization Area accesses

38. 37 Scenario #4: DRM’s “Supplier” and “Consumer” have mutual visibility SOA-RM’s Principal Concept Group DRM’s “Data Sharing” Standardization Area has

39. 38 Table of Contents  Orientation to Service-Oriented Architecture (SOA)  What is a Reference Model?  The OASIS Service-Oriented Architecture Reference Model (SOA-RM)  The OASIS SOA Adoption Blueprints TC  Relating the OASIS SOA Reference Model and the FEA Data Reference Model (DRM)  Questions

40. 39 Questions?

41. 40 Contact Information Joseph Chiusano Booz Allen Hamilton Washington, DC (202) 508-6514 chiusano_joseph@bah.com Rebekah Metz Booz Allen Hamilton McLean, VA (703) 377-1471 metz_rebekah@bah.com Robert “Chris” Porch Booz Allen Hamilton Atlanta, GA (404) 589-7082 porch_robert@bah.com