Joseph Chiusano Rebekah Metz Chris Porch Booz Allen Hamilton

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

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

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

However, current IT architectures do not fully support changing needs Agility Process Interoperability Costs • 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 • 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 • 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 • 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 IT is not growing toward an organization’s mission Lack of agility, process redundancy, inefficient system interactions, and increasing costs

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 The solution: A paradigm that encourages organizations to re-think how their IT capabilities are organized Service S Capabilities performed by one for another to achieve a desired outcome Oriented O Functionally aligning architecture to enable a collection of independent services to be linked together to solve a business problem Architecture A The fundamental organization of a system embodied in its capabilities, their interactions, and the environment

Traditional software architecture vs. Service-Oriented Architecture: A simple sandwich-making analogy Traditional approach to software architecture Service-Oriented Architecture “Separate Station” model “Service-Oriented” model Sandwich maker selectsfrom ingredients according to the recipe Customer goes to a different station for each sandwich Customer goes to one station for all sandwiches • Agility to create new combinations quickly • A Process that is efficient • Interoperable; easy to maintain consistency • Cost effective to operate and maintain • 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

SOA benefits uniquely address a rapidly changing environment Agility Process Interoperability Costs • 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 • 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 • 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 • 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

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

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”

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

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-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

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 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

“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

“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

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

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

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, andexecution context with the dynamics of visibility, interaction and real world effects

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 servicesthat 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 servicesthat 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

SOA and Processes

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

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

The following depicts the placement of the Behavioral Model within the SOA Reference Model

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

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

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

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

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/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

Data Sharing Query Points and Exchange Packages Data Description Data Context Taxonomies Data and Data Assets 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 Source: DRM 2.0

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

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

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

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

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

Questions?

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

Joseph Chiusano Rebekah Metz Chris Porch Booz Allen Hamilton