service planning engagement overview slideshare

Independent Guidance for

Service Architecture and Engineering

www.everware-cbdi.com

www.cbdiforum.com

Engagement Process Overview

Service Planning

© 2008 Everware-CBDI Inc

Topics

Engagement summary

Service Planning overview

Engagement approach

Key tools and deliverable

examples

Appendix

Critical success factors

Customer resources required

Preparatory work required

Why Everware-CBDI

This presentation outlines the

process of delivering a Service

Porfolio Plan, containing a

Service Architecture

If you would like to engage

Everware-CBDI or our partners

to help you with this activity,

please contact Everware-CBDI

http://www.cbdiforum.com/feed

back.php3

+353 (0)28 38073 (Ireland)

703-246-0000 or 888-383-7927

(USA)

http://www.cbdiforum.com/feedback.php3



Service Planning

- Engagement Summary

Objectives • Produce a Service Portfolio Plan that includes the identification of Services and their descriptions, and their organization in a Service Architecture – for a given planning scope

• Results in a consistent service architecture which all the different participants covered by the scope of the plan will work to, whether provisioning the services, building their implementations, or assembling them into solutions

Deliverables • Service Portfolio Plan

• Service Architecture, Service Descriptions

Participants • Business Analysts

• Program Managers

• Senior Architects

Engagement

Profile

• Depends on the scope of the plan

• A large scope – such as enterprise-wide - may be covered in several increments.

© 2008 Everware-CBDI Inc4

What is Service Planning?

CBDI Forum developed architectural process that:

Identifies the Service Portfolio

the collection of software services required (the portfolio)

Designs a Service Architecture

Classified by type and arranged into layers (an architecture)

Spanning specification to deployment

Defines or adopts the Policies

that govern how service planning and provisioning will proceed

Delivers a Plan to work to, not software!


Requirement for Service Planning

To prevent service anarchy

Duplicated effort

Overlapping and inconsistent functionality

Different standards being used, making services more difficult to maintain

To provide a layered structure that encourages

Service sharing by many solutions and businesses processes

Flexibility of a composable, modular architecture

A 360° view of each business resource. Providing consistent processing,

data and business rules for the major business resources

A choice of service suppliers

Standardization (lower layers of architecture) and customization (upper

layer)


The scope of the Service Plan can vary, and

may evolve in increments

Project SOA

Enterprise SOA

Ecosystem SOA

Industry SOA

Project delivers fragments

of enterprise Service Plan

Project uses

enterprise services

Enterprise progressively

defines enterprise

Service Plan

- Coordinates project

use and reuse

- progressively adopts

ecosystem and

industry schemas

- May develop in

increments, such as

by business domain

Ecosystem develops enterprise service plan for

collaborative processes (procurement, information

sharing . .. . )

Industry group develops common service specifications

that facilitate industry wide business processes

Increasing scope provides for greater consistency and opportunities for sharing

Increasing

scope takes

more effort and

time to deliver,

and achieve

consensus


Service Plan Content

The Service Plan scope could be for the whole enterprise, but developed business domain or

solution/project at a time – according to business priorities

Focus is on services and service scope; candidate/prototypical operations only are identified

Specific operations are defined as needed by solution developers and then assigned to appropriate

service

Plan is updated to reflect as-is after each solution project

Over time, the Plan includes acquired services as well as proposed services

Plan could be held in a Service Catalog, along with Service Specifications, SLAs, etc

1. Introduction

Background

Business Goals

for SOA

Objective &

Scope of Plan

Audience for

Plan

Responsibilities

Progress To

Date

4. Structure

of

Architecture

Diagram of

Domains

Domain

Definitions

2. Policies

Tactics &

Triage

Sourcing and

Commercial

Policies

Service Life

Cycle Policies

Architecture

Policies

Design

Policies

Default

Service

Standards

3. Quality

Expectations

Performance

Expectations

Security

Expectations

5.1 Service

Architecture for

<name1> Domain

Progress

Specification

Architecture

Implementation

Architecture

Deployment

Arch.

Transition

Approach

5.2 Service

Architecture for

<name2> Domain

Progress

Specification

Architecture

Implementation

Architecture

Deployment

Arch.

Transition

Approach

5.3 Service

Architecture for

<name3> Domain

Progress

Specification

Architecture

Implementation

Architecture

Deployment

Arch.

Transition

Approach

6.

Development

Schedules

Service

Planning

Schedule

Releases

Provisioning

Schedule

Solution

Development

ScheduleAppendices

Service Descriptions

Automation Unit

Descriptions

Technical Architecture


Engagement Approach

A typical Service Planning engagement depends on the scope of the plan. A

large scope – such as enterprise-wide - may be covered in several increments.

Business Models

Current System Models

Agree vision, scope for

Service Plan

Identify Utility

Services

Identify Capability Services

Identify Process Services

ServicePlan

Publish Service

Plan

Define or Adopt

Planning Policies

Strategies, priorities

Service Planning Policies

Identify Utility

Services

Identify Core

Business ServicesIdentify

Instances of scope

(increments)

Prepare Service

Specification Architecture

Perform Triage

(prioritization) Actions

Prepare Service

Implementation Architecture

Prepare Service

Deployment Architecture

Identify Automation

Units


Existing or 3rd

Party Services

Technology, Network Architecture


Service Specification Architecture

AU Descriptions

Service Implementation Architecture

Service Deployment Architecture

Define Transition Approach


Existing Systems


Example Engagement Work Plan

Specific tasks and timeframes may vary for each customer

0 5 10 15 20 25 30

Agree Vision & Scope for the Service Plan

Define or Adopt Planning and Provisioning Policies

Identify instances of scope

Perform Triage Actions

Decide Scope of Next Planning Increment

Refine Planning and Provisioning Policies

Identify Core Business Services and Dependencies

Identify Process Services and Dependencies

Identify Capability Services and Dependencies

Identify Utility Services and Dependencies

Identify Underlying Services and Dependencies

Prepare Service Specification Architecture

Identify Automation Units and Dependencies

Prepare Automation Unit Descriptions

Design Service Deployment Architecture

Liaise with Service Infrastructure Architects

Define Transition Approach for Increment

Gain Approval for next release of Service Portfolio Plan

Publish Latest Service Portfolio Plan


The Service Architecture consists of three

sub-architectures

10

Orders Service

Accounts Receivable APIProducts Service

<<SOAP over JMS>>

applicationServer

EJB Container

Order Fulfillment

Stock Manag’t

Product Manag’t

Mainframe

TP Monitor

Ordering CompPurchasing CoSales & Bill’gAccounting Pk.

Stock

ReorderingOrdering

Component

Stock

Movements

Product

ManagementProducts

Service

Orders

Service

Service Specification

Architecture

Provides a “logical” architecture of

services and their dependencies

Service Implementation

Architecture

Shows how Services are realized

by Automation Units (collections

of software artifacts)

Service Deployment

Architecture

Details how the Services and

Automation Units are deployed

to the physical network


First, the Services are organized into layers and

domains in the Service Specification Architecture

11

Process Services(orchestration layer)

Order FulfillmentService

Core Business Services

(“backbone” layer)

Underlying Services

Stock MovementsProductsService

Orders Service

Stock Management Service

Purchasing(from highly generic component)

Order System

Stock ControlApplication

Product DevSystem

Solution Layer

(presentation and dialog)

Utility Services(high reuse layer)

CurrencyConverter

AddressFormatter

AccountsReceivable(from legacy Accounting System)

Stock PurchasesCustomers

Service

Sa

les

& B

illi

ng

Inve

nto

ry


The identification of Services is driven from various

business models, and models of current systems

SUPPLY

SCHEDULING &

TRACKING

SHIPMENT UNIT

DISTRIBUTION

CONTRACTINGCUSTOMERS

RESOURCESFINANCE

FACILITIES

ACTIVITY MODEL

SHIPMENT

UNIT

PIECE

TRANSPORTATION

UNIT

BASIC

SHIPMENT

UNIT

replaces

SUPPY

BASIC

UNIT

REQUISITION

DETAILS

REQUISITIONMATERIAL

ITEM

ROLE

COMMERCIAL

BILL OF

LADING

RS STOP EVENT

LOCATION

Conveyance

Fixed

Airports, Seaports,

GELOC, LATLON . . . Voyage Air

Mission

Point

ORGANIZATION

UNIT

SHIPMENT UNIT

SCHEDULING &

TRACKING

SUPPLY

CONTRACTING

DOMAINS

PROCESS SERVICES

CORE BUSINESS SERVICES

UNDERLYING SERVICES

GLSSSS

XYZ

CRM

UTILITY SERVICES

Reference DataRules Engine

RequisitionTransportation Unit

Load ConveyanceProcess Cargo

LOGICAL DATA MODEL

REQUISITION

DETAILS

LOGISTICS

REQUISITION

MATERIAL

ITEM

METADATA REPOSITORYINTERFACE

TRANSFORMATION SCHEMA SCHEMA

DESIGN

GOVERNANCE

Note: All data shown is for illustration purposes only

ERP

Load

Conveyance

Manage

Lift

Execution

Move

Conveyance

Process

Shipment at

Transhipment

Point

Load

Conveyance

Process

Cargo For

Shipment

Generate

Shipment

Documents

Incheck

Passengers

& Cargo

FGHABC

PLM

123

CURRENT SYSTEM MODEL

BUSINESS TYPE MODEL

© 2008 Everware-CBDI Inc14

Next, the Services are mapped to Automation Units

in the Service Implementation Architecture

Process Services(orchestration layer)

ProductLifecycleServices

Core Business Services(the backbone layer)

Products Service

Sales Process Services

Solution Layer(UI, dialog

management)

« component »

Products Life

Cycle Component

« component »

Sales Process

Component

« aggregator »

Products

Component

Customers Service

OrdersService

«component»

Sales

Component

Underlying Services

Products InManufacturing Sys

Products InInventory Sys

«legacy»

Manufacturing

System

«wrapper»

ProductsAPI2

Wrapper

«legacy»

Inventory

System

Utility Services(high reuse layer)

AddressFormatting Service

«external»

Undefined

indicates an embedded data store

OrderingApplication

BillingApplication

Product LifeCycle System


Appendices


Automation Unit Descriptions


Tools and Templates Provided

Property Value

Automation Unit Name As depicted in the Implementation View

Purpose Narrative

Services Provided List of Service Names (1 or more)

Services Required List of Service Names (0, 1 or more)

State if dependency is implementation-only

Other Dependencies Non-service bearing automation units or other artifacts (e.g. data

stores) that this automation unit depends upon.

Sourcing mechanism E.g. Subscription to External Service, Legacy System Wrapping, etc.

Independence Level UI- or business process- or enterprise independent

Runtime Platform Technology and Comms Protocol used to access (e.g. Web Service

(SOAP on HTTP), Active X (DCOM), CS/3 component (MQ series)

Structure (modules,

etc.)

A narrative description of how the implementation could be realized,

or a list of modules/components it will be built from. Not required for

an external service.

Other Information Anything else that the author needs to communicate to readers.

Automation Unit Description Template

Property Value

Service name (business) Natural language name that business will use for service

Aliases Other names for the service, which might be used by someone

searching for this service.

Purpose of the service Narrative – to describe the service scope and benefit

Business Domain The business domain that the service belongs to. Leave blank when

not assigned to any business domain.

Business Owner Person who approves this service & any changes

Target Consumers Organizations and/or developers roles that service is intended for

Business Process

Support

List of end-to-end Business Processes supported by some release of

this service.

Distinguish between planned/expected support and current/actual

support achieved by an existing production release of this service.

Business Objective

Support

List of formally defined business objectives or strategies or targets that

this service will support.

Stability (over next …

years)

Predicted changes need within next (n) years, and/or

Expected life, if this is a temporary service

Service Description Template

1. Introduction

Background

Business Goals for

SOA

Objective & Scope

of Plan

Audience for Plan

Responsibilities

Progress To Date

2. Policies

Tactics & Triage

Sourcing and

Commercial

Policies

Service Life

Cycle Policies

Architecture

Policies

Design Policies

Default Service

Standards

3. Quality

Expectations

Performance

Expectations

Security

Expectations

4. Structure of

Architecture

Diagram of

Domains

Domain

Definitions

5.1 Service

Architecture for

<name1> Domain

Progress

Specification

Architecture

Implementation

Architecture

Deployment Arch.

Transition Approach

6. Development

Schedules

Service

Planning

Schedule

Releases

Provisioning

Schedule

Solution

Development

Schedule

Service Plan Template

Tactics

Sourcing Policies

Architecture and Design Policies

Commercial Policies – govern buying or selling from 3rd parties

Service Life Cycle Policies

Default Standards to be used

Default Quality of Service expectations

Starter Policies


Plus: a full set of models can be produced

using the CBDI-SAE UML profile for SOA

Note: All data shown is for illustration purposes only

Off

ice

«P

roc

es

s R

ole

»

Se

nd

er

«P

roc

es

s R

ole

»

New Day

«Elementary P...

Raise Inv oices

Due

:Inv oice

«Elementary P...

Rev iew Inv oice

:Payment

«Elementary P...

Register Payment

:Shipment

[acknowledged]

:Customer :Payment

[rece ived]

BUSINESS TYPE MODEL

Showing DOMAINS

SERVICE IMPLEMENTATION ARCHITECTURE

Showing SERVICES and AUTOMATION

UNITS, assigned to ARCHITECTURE LAYERS

SERVICE

DEPLOYMENT

ARCHITECTURE

Showing

DEPLOYMENTS

PROCESS DIAGRAM Showing SWIM LANES


Key Deliverables (1 of 2) – High Level

Examples

Appendices


Automation Unit Descriptions


1. Introduction

Background

Business Goals for

SOA

Objective & Scope

of Plan

Audience for Plan

Responsibilities

Progress To Date

2. Policies

Tactics & Triage

Sourcing and

Commercial

Policies

Service Life

Cycle Policies

Architecture

Policies

Design Policies

Default Service

Standards

3. Quality

Expectations

Performance

Expectations

Security

Expectations

4. Structure of

Architecture

Diagram of

Domains

Domain

Definitions

5.1 Service

Architecture for

<name1> Domain

Progress

Specification

Architecture

Implementation

Architecture

Deployment Arch.

Transition Approach

6. Development

Schedules

Service

Planning

Schedule

Releases

Provisioning

Schedule

Solution

Development

Schedule

1. The Service Plan (or increment of)

- containing all the other deliverables

Property Value


Aliases Other names for the service, which might be used by someone searching for this service.


Business Domain The business domain that the service belongs to. Leave blank when not assigned to any

business domain.



Business Process Support List of end-to-end Business Processes supported by some release of this service.

Distinguish between planned/expected support and current/actual support achieved by an

existing production release of this service.

Business Objective Support List of formally defined business objectives or strategies or targets that this service will

support.

Stability (over next … years) Predicted changes need within next (n) years, and/or


4. Plus a set of Service Descriptions

Property Value





business domain.







support.



Property Value





business domain.







support.



3. A Service Specification Architecture

Tactics

Sourcing Policies

Architecture and Design Policies

Commercial Policies – govern buying or selling from 3rd parties

Service Life Cycle Policies

Default Standards to be used

Default Quality of Service expectations

2. A set of Planning

Policies (that can be

used in subsequent

iterations, or service

plan projects


Key Deliverables (2 of 2)

Property Value


Purpose Narrative




Other Dependencies Non-service bearing automation units or other artifacts (e.g. data stores) that this automation unit depends upon.



Runtime Platform Technology and Comms Protocol used to access (e.g. Web Service (SOAP on HTTP), Active X (DCOM), CS/3 component (MQ series)

Structure (modules, etc.) A narrative description of how the implementation could be realized, or a list of modules/components it will be built from. Not required for



6. Plus a set of Automation Unit Descriptions

Property Value


Purpose Narrative











Property Value


Purpose Narrative











Domains

(any business

type)

Bus. Process

Cam

paig

n

Cam

p.

Actio

n

Pro

duct

Pro

duct

Term

s

Mark

et

Segm

ent

Com

petito

r

Pro

motio

n

Perfo

rmance

Ship

men

t

Ware

house

Subcontra

ct

or

Orig

in

Destin

atio

n

Sender

Shipment

Lifecycle

R R R R U C R R C C C

Truck

Maintenance

Truck

Scheduling

R U R R R

Run Promotion C R C U

New Product

Development

C R C R R

Product

Management

R U C R R R R R

Execute

Marketing

Campaign

C C R R C R R

Prepare

Periodic

Financial

Statements

8. Various matrices

that may have been

produced to aid

understanding and

demonstrate

relationships between

business model

elements and service

architecture elements

5. A Service Implementation Architecture 7. A Service Deployment Architecture

Independent Guidance for

Service Architecture and Engineering


www.cbdiforum.com

Additional Discussion/

Appendix Slides

Next Steps


Critical Success Factors

Well defined scope

That is manageable in size

And is possible to reach consensus on

Participation of relevant stakeholders across the Service Plan

scope

Representing both business and IT interests

The Service Plan is not just an IT deliverable

Consensus of relevant stakeholders across the Service Plan scope

Agreement of Service Plan

Agreement to conform to Service Plan

Access to suitable business models

Business models may require improvement before Service Planning

can commence


Customer Resources Required

Business Analysts

Who understand business requirements and business models

IT Architects

Who know the current systems and the technology architecture

Suitable Models as input

Business models

Current system models

Technology architecture


Preparatory Work

Customer

Ensure availability of key resources for the duration of the

workshop(s)

Acquire, or prepare suitable business models

Everware-CBDI

Educate customer team in Service Planning

Assess quality of business models


Why Everware-CBDI ?

Independent specialist SOA

methodology firm

Merger of established

UK and US companies in 2006

27,000+ subscribing architects

worldwide

Enabling structured, enterprise levelSOA

Facilitating SOA standards

Defined, documented SOA methodology

Widely used best practices, referencearchitecture, repeatable processes

SOA Solution Business including

Education, Consulting, Knowledge

products

www.cbdiforum.com


http://www.cbdiforum.com/

http://www.everware-cbdi.com/




Everware-CBDI - World Wide Reputation

Over 12 years of experience in applying Service Oriented concepts,

methodology, and best practices have established the Everware-CBDI as a

leader in SOA adoption.

Partial list of credentials and achievements: CBDI Forum Portal - 27,000+ member architects worldwide

Keynote Speakers on SOA on recent industry conferences including Microsoft Architect’s Councils

(US, Europe), IBM Architect’s Councils, SAP User Group, Open Group, IDG SOA Europe, and

many more

SOA Metamodel Submission to OMG

Active membership of the OMG UPMS Joint Submission team

IAC EA-SIG/Services Committee Chair

OMG GovDTF Co-Chair

Publications:

CBDI Journal - over 100 Editions published

White Papers (e.g., CIO Council, IAC, Lead Role in Practical Federal Guide for SOA)

Books (e.g., Service Orientation, Information Modeling)


+353 (0)28 38073 (Ireland)

703-246-0000 or 888-383-7927 (USA)


service planning engagement overview slideshare

Technology

independence

target consumers

critical success

runtime platform

background

business owner

legacy system

identify capability