# Presentation: 417361

## EPA’s SOA Strategy

**Web Services Work Group: January 29, 2007**

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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

## Four Principles of EPA’s 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 SRM’s 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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

## 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 are****inherited by the lowest service level applicable;****for BCSs, this may be at the Type level**

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

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

- Approach for Modeling SOA in ART

## Mapping to Levels of Granularity

**Architecture Elements**

**FEA SRM, Extended**

**Objects in the Business Layer****map only to FCs and BCSs.****Objects in the Data, Application,****and Technology Layers map to ****BCSs, BCs, and DCs.**

- Approach for Modeling SOA in ART

## 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 EPA’s 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.

- Approach for Modeling SOA in ART

- Approach for Modeling SOA in ART

## Metis Mapping MethodologyPutting SOA Strategy into ART

- Approach for Modeling SOA in ART

## 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 EPA’s EA using ART and EPA’s Metis “metamodel”
- The metamodel is the toolkit of objects and relationships used to described the Enterprise

- Approach for Modeling SOA in ART

## 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 developer’s 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

- Approach for Modeling SOA in ART

## Problems to be Solved: CPIC and Developer SOA Views Differ

**Developer’s View of SOA Geospatial Visualization**

**CPIC View of SOA Geospatial Visualization**

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

- Approach for Modeling SOA in ART

## Problem to be Solved: Services are built from Multiple Components

**EPA Portal: Component View**

**Source: Lockheed Martin**

- 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

- Approach for Modeling SOA in ART

## Approach for EA Modeling Using the SRM

**Basic concept: Separate “component-ness” from “service.”**

**Component Granularity**

**Service Definition**

- Approach for Modeling SOA in ART

## Approach for EA Modeling Using the SRM

**Basic concept: Separate “component-ness” from “service.”**

**Component Granularity**

**Service Definition**

- Service

**Potential IT Exhibit 300s**

- Approach for Modeling SOA in ART

## An Example: CDX mapped in SOA

- Approach for Modeling SOA in ART

## EPA Portal

- Approach for Modeling SOA in ART

## EPA Portal

- Approach for Modeling SOA in ART

## EPA Portal

- Approach for Modeling SOA in ART

## EPA Portal

- Approach for Modeling SOA in ART

## EPA Portal

- Approach for Modeling SOA in ART

## EPA Portal

- Approach for Modeling SOA in ART