EPAs SOA Strategy

1
EPAs SOA Strategy

• Web Services Work Group January 29, 2007

2
Overview of the SOA Strategy

• Service Oriented Architecture (SOA) is an
  approach to capture, define, and expose a
  collection of services and service components
  available throughout an organization.
• SOA strives to achieve economies of scale in the
  development and implementation of business
  solutions via the reuse of services and service
  components.
• Effecting the transition to SOA will not be
  simple or immediate. It will involve changes in
  both IT development and business process planning
  and management. Phasing in these changes may
  require several years.

from Strategy for Implementing Service-Oriented
Architecture (SOA) at EPA
3
Enterprise Architecture versus SOA

• Enterprise Architecture is the appropriate tool
  for implementing SOA across an enterprise, but EA
  is not SOA
• EA is a tool for analyzing organizations and
  managing change
• SOA is a particular business strategy that EA can
  implement

4
Current Status of SOA at EPA

• Because it is a recognized IT best practice, SOA
  has taken root in the EPA IT development
  community on its own
• This strategy supports this trend in the IT
  arena, and seeks to expand SOA by degrees into
  the business community
• Reaping the benefits of SOA in the non-IT arena
  will be an ambitious and lengthy task

5
Origins of SOA
1970s 1980s
1990s Early 2000s
TODAY
?
?
?
?
?
Reuse through function-oriented
programming(sub-routine and function reuse
Reuse through object-oriented programming(class
reuse)
Reuse through distributed object technologies and
component based architectures(CORBA/DCOM/DCE
and component reuse
Reuse through early service orientation (reuse
of web services)
Service-Oriented Architectures(SOA)
The future of software development will likely
consist of complete assembly of applications from
services and components often referred to as
true software manufacturing. Services and
Component-Based Architectures, CIO Council,
January 2006
6
Background the Service Reference Model
For EA modeling, the SRM as a bridge between the
business-driven top half and the
technology-driven bottom half of the FEA
7
Four Principles of EPAs SOA Strategy

• Services can include both business processes and
  IT services and can exist at all levels of the
  architecture
• All EPA services must map to the FEA SRM
• Service components are characterized by how well
  they meet the SRMs definition of a service
  component, and by their level of complexity
• Services, service components, and service level
  agreements (SLAs) should be defined, cataloged,
  and published

8
Principle 1 Services Exist across Levels of the
Architecture

• The SRM defines a service component as a
  self-contained business process or service with
  predetermined functionality that may be exposed
  through a business or technology interface
• Business service e.g. bank teller
• IT service e.g., timesheet
• Combined business/IT service e.g., CDX

9
Principle 2 All EPA Services must Map to the FEA
SRM

• Consistent with FEA requirements, all services
  must map to the FEA SRM.
• This permits the community of users to search for
  and find services that they require to conduct
  their business.

10
Mapping to services
Architecture Elements
FEA SRM, Extended
Any object in the model may be connected to any
SRM service
SRM Domains and Service Types areinherited by
the lowest service level applicablefor BCSs,
this may be at the Type level
11
Principle 3 Service Components are Defined by
SRM Definition and Level of Complexity

• The SRM defines a service component as a
  self-contained business process or service with
  predetermined functionality that may be exposed
  through a business or technology interface
• This second EPA SOA principle distinguishes a
  service from a component
• It will allow EPA to track its progress in
  converting non-SOA systems to SOA systems
• Lower-level services often aggregate into more
  complex, high-level services, with components
  calling each other at multiple levels of
  aggregation

12
Definitions of Component-ness

• SRM Definition
• self-contained with predetermined functionality
• exposed through a business or technology
  interface

• As elaborated in Service Component-Based
  Architectures V 2.0, components are
• Encapsulated
• Consumable
• Extensible
• Standards-based
• Well-documented
• Follow industry best-practices
• Provide a cohesive set of services
• Have well-defined license or service level
  agreement

13
Levels of Granularity

• The SRM defines four levels of granularity in the
  component hierarchy
• Distributed Component (DC) A software element
  that can be called at run-time with a clear
  interface and a clear separation between
  interface and implementation.
• Business Component (BC) Consists of all the
  technology elements (software, hardware, and
  data) necessary to express, implement, and deploy
  a business concept as an autonomous, reusable
  element of a large information system.
• Business Component System (BCS) A BCS is a set
  of cooperating business components assembled to
  deliver a solution to a business problem.
• Federated Component (FC) An FC is a set of
  cooperating system-level components federated to
  resolve the business need of multiple end users
  often belonging to different organizations.

14
Mapping to Levels of Granularity
Architecture Elements
FEA SRM, Extended
Objects in the Business Layermap only to FCs and
BCSs.Objects in the Data, Application,and
Technology Layers map to BCSs, BCs, and DCs.
15
Principle 4 Services, service components, and
SLAs should be Defined, Cataloged, and Published

• Identify, catalog, and publish all services used
  within the Agency
• Implementation of EPAs SOA strategy will combine
  the following
• Service level agreements (SLAs) that define the
  relationship between the provider and the
  consumer of a service, especially for high-level
  services.
• A business service catalog used to publish and
  discover services. This catalog will contain
  business information relating to the service, but
  will drill down to a service component registry
  (described below).
• A service component catalog (OMB calls this a
  platform), consisting of many service
  components representing business processes and
  technology service components that provide
  varying levels and types of services.
• The service components that provide these
  services.

16
(No Transcript)
17
Metis Mapping MethodologyPutting SOA Strategy
into ART
18
Purpose of SOA Mapping Methodology

• Create a consistent language and notation for
  discussing services, service components, and SOA
• Integrate SOA with the FEA Service Reference
  Model
• Apply to EPAs EA using ART and EPAs Metis
  metamodel
• The metamodel is the toolkit of objects and
  relationships used to described the Enterprise

19
Goals of Mapping Methodologyg

• Depict both IT and business service components,
  and the relationships and dependencies between
  them
• Resolve ambiguities of SOA terminology to
  accommodate both the CPIC-level
  (investment/architecture) view of SOA, and the
  developers IT view (e.g., J2EE)
• Make choices of how deep to go in developing SOA
  models
• Find the right breakpoint between EA modeling and
  SLC-level IT development
• Make modeling choices based on the expected use
  of the model

20
Problems to be Solved CPIC and Developer SOA
Views Differ

• CPIC and other investment- or management-level
  views of services tend to be general and loosely
  defined
• The developers view is analytic and logical,
  usually disaggregated and technical

Developers View of SOA Geospatial Visualization
CPIC View of SOA Geospatial Visualization
21
Problem to be Solved Services are built from
Multiple Components
EPA Portal Component View

• Granularity becomes a problem how can we
  represent levels of granularity within a single
  object?
• A single object needs to represent the highest
  level of the service the service to which all
  other components are aggregated

Source Lockheed Martin
22
Approach for EA Modeling Using the SRM
Component Granularity
Service Definition
Basic concept Separate component-ness from
service.
23
Approach for EA Modeling Using the SRM
Service
Potential IT Exhibit 300s
Component Granularity
Service Definition
Basic concept Separate component-ness from
service.
24
An Example CDX mapped in SOA
25
EPA Portal
26
EPA Portal
27
EPA Portal
28
EPA Portal
29
EPA Portal
30
EPA Portal