Service Planning Engagement Overview Slideshare

Independent Guidance for
Service Architecture and Engineering

Service Planning
Engagement Process Overview

www.everware-cbdi.com
www.cbdiforum.com

Topics

 Engagement summary  This presentation outlines the
 Service Planning overview process of delivering a Service
 Engagement approach Porfolio Plan, containing a
Service Architecture
 Key tools and deliverable
examples
 If you would like to engage
Everware-CBDI or our partners
 Appendix to help you with this activity,
 Critical success factors please contact Everware-CBDI
 Customer resources required
 Preparatory work required  http://www.cbdiforum.com/feed
 Why Everware-CBDI back.php3

 +353 (0)28 38073 (Ireland)
 703-246-0000 or 888-383-7927
(USA)

© 2008 Everware-CBDI Inc

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 • Depends on the scope of the plan
Profile • A large scope – such as enterprise-wide - may be covered in several increments.


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!

4 © 2008 Everware-CBDI Inc

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

Industry SOA Industry group develops common service specifications
that facilitate industry wide business processes

Ecosystem SOA Ecosystem develops enterprise service plan for
collaborative processes (procurement, information
sharing . .. . )

Increasing Enterprise SOA Enterprise progressively
scope takes defines enterprise
more effort and Service Plan
time to deliver, Project SOA - Coordinates project
and achieve use and reuse
consensus - progressively adopts
Project uses ecosystem and
enterprise services industry schemas
- May develop in
increments, such as
by business domain
Project delivers fragments
of enterprise Service Plan

Increasing scope provides for greater consistency and opportunities for sharing

Service Plan Content

1. Introduction 2. Policies 3. Quality 4. Structure 5.1 Service 6.
 Background  Tactics & Expectations of Architecture for Development
 Business Goals Triage  Architecture <name1> Domain
5.2 Service Schedules
for SOA  Sourcing and Performance  Diagram of  Progress
Architecture for  Service
 Objective & Commercial Expectations Domains  Specification
<name2> Domain
5.3 Service Planning
Scope of Plan Policies  Security  Domain  Progress
Architecture
Architecture for Schedule
 Audience for  Service Life Expectations Definitions  Implementation
 Specification
<name3> Domain Releases
Plan Cycle Policies  Progress
Architecture
Architecture  Provisioning
 Responsibilities  Architecture  Deployment
 Implementation
 Specification Schedule
 Progress To Policies Arch.
Architecture
Architecture  Solution
Date  Design Appendices  Transition
 Deployment
 Implementation Development
Policies  Service Descriptions Approach
Arch.
Architecture Schedule
 Default  Automation Unit  Transition
 Deployment
Service Descriptions Approach
Arch.
Standards  Technical Architecture  Transition
Approach

 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

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.
 Current System
 Current System
 Strategies, priorities  Business Models Models  Technology, Models
 Service Planning  Current System  Existing or 3rd Network  Existing
Policies Models Party Services Architecture Systems

Agree vision,
scope for Identify
Identify
Service Plan Automation
Process
Services Units
Define or
Define
Adopt Identify
Transition
Planning Capability Prepare Prepare Prepare
Identify Approach
Policies Services Service Service Service
Core
Business Specification Implementation Deployment
Identify Identify
Services Architecture Architecture Architecture
Instances of Utility
scope Services Publish
(increments) Service
Identify Plan
Utility
Perform Services
Triage
(prioritization)
Actions

 Service Descriptions  AU Descriptions  Service Service
 Service Specification  Service Deployment Plan
Architecture Implementation Architecture
Architecture © 2008 Everware-CBDI Inc

Example Engagement Work Plan

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

Specific tasks and timeframes may vary for each customer

The Service Architecture consists of three
sub-architectures

Orders Service Service Specification
Architecture
Provides a “logical” architecture of
Products Service services and their dependencies
Accounts Receivable API

Orders
Service Stock Service Implementation
Ordering Stock Architecture
Movements
Component Reordering
Shows how Services are realized
Product by Automation Units (collections
Products Management of software artifacts)
Service

applicationServer Mainframe Service Deployment
EJB Container TP Monitor Architecture
Order Fulfillment <<SOAP over JMS>> Ordering Comp Details how the Services and
Stock Manag’t Purchasing Co Automation Units are deployed
Product Manag’t Sales & Bill’g to the physical network
Accounting Pk.


First, the Services are organized into layers and
domains in the Service Specification Architecture
Order Product Dev Stock Control Solution Layer
System System Application (presentation and dialog)

Order
Fulfillment Process Services
Service Stock Management Service (orchestration layer)

Orders Stock Movements
Sales & Billing

Service Products Core Business

Inventory
Service Stock Purchases Services
Customers (“backbone” layer)
Service

CurrencyConverter Utility Services
(high reuse layer)
AddressFormatter

Underlying Services
AccountsReceivable Purchasing
(from legacy Accounting System) (from highly generic component)

The identification of Services is driven from various
business models, and models of current systems
ACTIVITY MODEL BUSINESS TYPE MODEL
Manage
Lift ROLE CONTRACTING
Execution PIECE
Move COMMERCIAL
Load BILL OF
Conveyance Conveyance LADING

SHIPMENT
UNIT RS STOP EVENT

replaces
Process
Cargo For
Shipment
Load
Conveyance
Process
Shipment at
Transhipment
Incheck
Passengers
& Cargo
DOMAINS BASIC
LOCATION

TRANSPORTATION SHIPMENT
Point UNIT
UNIT
Conveyance
Fixed
Generate
Shipment SUPPY Airports, Seaports,
BASIC GELOC, LATLON . . .
Documents SCHEDULING & UNIT
Voyage Air
Mission
Point
TRACKING DISTRIBUTION SCHEDULING &
TRACKING
SHIPMENT UNIT
SUPPLY
SHIPMENT UNIT REQUISITION
MATERIAL
ITEM

CONTRACTING
CUSTOMERS FACILITIES ORGANIZATION
UNIT SUPPLY

FINANCE REQUISITION

RESOURCES DETAILS

PROCESS SERVICES
Process Cargo
Load Conveyance
CURRENT SYSTEM MODEL
CORE BUSINESS SERVICES
Transportation Unit
Requisition

INTERFACE METADATA REPOSITORY
UNDERLYING SERVICES
TRANSFORMATION SCHEMA SCHEMA

ABC 123 LOGICAL DATA MODEL
XYZ FGH DESIGN
SSSS
GL GOVERNANCE
LOGISTICS MATERIAL

CRM REQUISITION ITEM

ERP PLM
REQUISITION
DETAILS

UTILITY SERVICES
Rules Engine Reference Data Note: All data shown is for illustration purposes only


Next, the Services are mapped to Automation Units
in the Service Implementation Architecture
Product Life Ordering Billing
Cycle System Application Application
Solution Layer
(UI, dialog
management)

Product
Sales
Lifecycle
Process
Services
Services Process Services
« component » « component » (orchestration layer)
Products Life Sales Process
Cycle Component Component

Products
Service
« aggregator » Orders Customers
Core Business Services
Service (the backbone layer)
Products Service
«component»
Component Sales
Component

«external»
Address Utility Services
Formatting Service Undefined (high reuse layer)

Products In Products In
Manufacturing Sys Inventory Sys
«legacy» «wrapper»
Manufacturing
Underlying Services
ProductsAPI2 «legacy»
System Wrapper Inventory
System indicates an embedded data store

Tools and Templates Provided
Service Plan Template Service Description Template
Property Value

1. Introduction
2. Policies Service name (business) Natural language name that business will use for service
 Background
 Tactics & Triage
3. Quality Aliases Other names for the service, which might be used by someone
 Business Goals for searching for this service.
 Sourcing and
SOA Expectations of
4. Structure Purpose of the service Narrative – to describe the service scope and benefit
Commercial
 Performance
 ObjectiveArchitecture
& Scope
5.1 Service Business Domain The business domain that the service belongs to. Leave blank when
Policies Diagram
of PlanExpectations of
 Architecture for
not assigned to any business domain.

 Service Life 6. Development
 Security Business Owner Person who approves this service & any changes
 AudienceDomains
for <name1> Domain
Plan
Cycle Policies Schedules
Expectations
 Domain
Target Consumers Organizations and/or developers roles that service is intended for
 Responsibilities
 Progress
 Architecture  Service Business Process List of end-to-end Business Processes supported by some release of
 Progress Definitions
 Specification
To Date Support this service.
Policies Planning Distinguish between planned/expected support and current/actual
Architecture support achieved by an existing production release of this service.
 Design PoliciesSchedule
 Implementation
 Default Service
Business Objective List of formally defined business objectives or strategies or targets that
Releases Support this service will support.
Architecture
Standards  Provisioning
 Deployment Arch. Stability (over next …
years)
Predicted changes need within next (n) years, and/or
Expected life, if this is a temporary service
Schedule
Appendices  Transition Approach
 Solution
 Service Descriptions
Development
Automation Unit Description Template
 Automation Unit Descriptions Property Value
Schedule
 Technical Architecture Automation Unit Name As depicted in the Implementation View

Purpose Narrative

Services Provided List of Service Names (1 or more)

 Tactics Services Required List of Service Names (0, 1 or more)
State if dependency is implementation-only
 Sourcing Policies
Other Dependencies Non-service bearing automation units or other artifacts (e.g. data
 Architecture and Design Policies stores) that this automation unit depends upon.

 Commercial Policies – govern Sourcing mechanism E.g. Subscription to External Service, Legacy System Wrapping, etc.
buying or selling from 3rd parties Starter Policies Independence Level UI- or business process- or enterprise independent
 Service Life Cycle Policies
Runtime Platform Technology and Comms Protocol used to access (e.g. Web Service
 Default Standards to be used (SOAP on HTTP), Active X (DCOM), CS/3 component (MQ series)

 Default Quality of Service Structure (modules, A narrative description of how the implementation could be realized,
etc.) or a list of modules/components it will be built from. Not required for
expectations an external service.

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


Plus: a full set of models can be produced
using the CBDI-SAE UML profile for SOA
PROCESS DIAGRAM Showing SWIM LANES
:Shipment :Customer :Payment
[acknowledged] [rece ived]
«Process Role»
Office

«Elementary P... «Elementary P...
Raise Inv oices Register Payment
Due
New Day

:Inv oice :Payment
«Process Role»
Sender

«Elementary P...
Rev iew Inv oice

SERVICE
DEPLOYMENT
ARCHITECTURE
Showing
DEPLOYMENTS
BUSINESS TYPE MODEL
Showing DOMAINS

SERVICE IMPLEMENTATION ARCHITECTURE
Showing SERVICES and AUTOMATION
UNITS, assigned to ARCHITECTURE LAYERS

Note: All data shown is for illustration purposes only


Key Deliverables (1 of 2) – High Level
Examples
1. The Service Plan (or increment of) 3. A Service Specification Architecture
- containing all the other deliverables
1. Introduction
2. Policies
 Background
 Tactics & Triage
3. Quality
 Business Goals for
 Sourcing and
SOA Expectations of
4. Structure
Commercial
 Performance
 ObjectiveArchitecture
& Scope
5.1 Service
Policies Diagram of
Expectations
 Architecture for
of Plan
 Service Life 6. Development
 Security
 AudienceDomains
for <name1> Domain
Plan
Cycle Policies Schedules
Expectations
 Domain
 Responsibilities
 Progress
 Architecture  Service
 Progress Definitions
 Specification
To Date
Policies Planning
Architecture
 Design PoliciesSchedule
 Implementation
 Default ServiceReleases
Architecture
Standards  Provisioning
 Deployment Arch.
Schedule
Appendices  Transition Approach
 Solution
 Service Descriptions
Development
 Automation Unit Descriptions 4. Plus a set of Service Descriptions
Schedule
 Technical Architecture Property Value

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

Aliases
Service name (business) Other names for the service, which might be used by someone searching for this service.
Natural
Property Value language name that business will use for service

 Tactics Purpose of the service
Aliases name (business)
Service

Business
Purpose Domain
Aliases of the service
Narrative – to describe the service might and for service
Other names for the service, whichscope useused by someone searching for this service.
Natural language name that business will be benefit

Other names for the service, whichscope andusedLeave blank when not assignedservice.
Narrative – to domain that the service belongsbenefit someone searching for this to any
The business describe the service might be to. by
business domain.

 Sourcing Policies Business Domain
Purpose of the service
Business Owner Narrative – to domain that the service belongsbenefit
The business describe the service scope and to. Leave blank when not assigned to any
Person who approves this service & any changes
business domain.

 Architecture and Design Policies Business Domain
Target Consumers
Business Owner Organizations and/or that the service that service
Person who approves this service & any changes is intended
when not assigned to any
The business domaindevelopers rolesbelongs to. Leave blank for

2. A set of Planning
business domain.

Target ConsumersSupport
Business Process Organizations and/or developers roles that service is some release of this service.
List of end-to-end Business Processes supported by intended for

Commercial Policies – govern
Business Owner Person who approves this service & any changes


Distinguish between planned/expected support and current/actual support achieved by an
existing production release of this service.

buying or selling from 3rd parties Policies (that can be Business Process
Target ConsumersSupport
Business Objective Support
Business Process Support
List of end-to-end Business Processes supported by intended for
Organizations and/or developers roles that service is some release of this service.
List of formally defined business objectives
existing production release of this service. or strategies or targets that this service will
support.
List of end-to-end Business Processes supported by some release of this service.

used in subsequent
Business Objective Support List of formally defined business objectives or strategies or targets that this service will
existing production need within next (n) years, and/or
release of this service.
Stability (over next … years) Predicted
support. changes
 Service Life Cycle Policies Business Objective Support
Stability (over next … years)
List of formally defined business objectives or strategies or targets that this service will
Predicted
support. changes need within next (n) years, and/or

 Default Standards to be used iterations, or service Stability (over next … years)

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

 Default Quality of Service plan projects
expectations

Key Deliverables (2 of 2)
5. A Service Implementation Architecture 7. A Service Deployment Architecture

Campaign
Action
Camp.

Product
Terms
Product
Segment
Market

Competitor

Promotion

Performance

Shipment

Warehouse
or
Subcontract

Origin

Destination

Sender
Domains 
(any business

6. Plus a set of Automation Unit Descriptions
type)
Bus. Process  8. Various matrices
Shipment
Lifecycle
R R R R U C R R C C C
that may have been
Property

Automation Unit Name
Property Value
Value

As depicted in the Implementation View
Truck
Maintenance produced to aid
understanding and
Purpose Narrative Truck R U R R R
Automation Unit Name As depicted in the Implementation View
Property Value
Scheduling
Services Provided List of Service Names (1 or more)
Purpose Narrative
Automation Unit Name As depicted in the Implementation View Run Promotion C R C U
Services Required
Services Provided
Purpose

Services Required
Services Provided Dependencies
List of Service Names (0, 1 or more)
List of Service Names (1 or more)
Narrative
State if dependency is implementation-only

List of Service Names (1 or more) automation units or other artifacts (e.g. data stores) that this automation unit depends upon.
demonstrate
Other Non-service bearing
State if dependency is implementation-only New Product C R C R R
Services Required
Other Dependencies
Sourcing mechanism
Non-service bearing automation units
State if dependency is implementation-only or other artifacts (e.g. data stores)etc. this automation unit depends upon.
E.g. Subscription to External Service, Legacy System Wrapping,
that
Development
relationships between
Product R U C R R R R R
Independence Level
Other Dependencies
Sourcing mechanism

Runtime Platform
Non-service bearing automation units or enterprise independent stores) that this automation unit depends upon.
UI- or business process- or other artifacts (e.g. data
E.g. Subscription to External Service, Legacy System Wrapping, etc.

Technology and Comms Protocol used to access (e.g. Web Service (SOAP on HTTP), Active X (DCOM), CS/3 component (MQ series)
Management
business model
Independence Level UI- or business process- or enterprise independent Execute C C R R C R R

elements and service
Sourcing mechanism E.g. Subscription to External Service, Legacy System Wrapping, etc.
Marketing
Runtime Platform
Independence Level (modules, etc.)
Structure
A process- or enterprise how the implementation could be realized, or a list of modules/components it will be built from. Not required for
UI- or businessnarrative description of independent
Campaign
an external service.

Runtime Platform
Structure (modules, etc.)

Other Information
A narrative description of how the implementation could be realized, or a list of modules/components it will be built from. Not required for
Anything else that the author needs to communicate to readers.
Prepare
Periodic
Financial
architecture elements
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
Statements



Independent Guidance for
Service Architecture and Engineering

Next Steps
Additional Discussion/
Appendix Slides

www.everware-cbdi.com
www.cbdiforum.com

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 level
SOA
 Facilitating SOA standards
 Defined, documented SOA methodology
 Widely used best practices, reference
architecture, repeatable processes
 SOA Solution Business including
Education, Consulting, Knowledge
products

 www.cbdiforum.com
 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)

 http://www.cbdiforum.com/feedback.php3
 +353 (0)28 38073 (Ireland)
 703-246-0000 or 888-383-7927 (USA)


Service Planning Engagement Overview Slideshare

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (17)

Último

Último (20)

Service Planning Engagement Overview Slideshare