Service Planning Engagement Overview Slideshare1. Independent Guidance for
Service Architecture and Engineering
Service Planning
Engagement Process Overview
www.everware-cbdi.com
www.cbdiforum.com 2. 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 3. 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.
© 2008 Everware-CBDI Inc 4. 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 5. 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)
© 2008 Everware-CBDI Inc 6. 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
© 2008 Everware-CBDI Inc 7. 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
© 2008 Everware-CBDI Inc 8. 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 9. 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
© 2008 Everware-CBDI Inc 10. 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.
10 © 2008 Everware-CBDI Inc 11. 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)
11 © 2008 Everware-CBDI Inc 12. 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
© 2008 Everware-CBDI Inc 13. 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
14 © 2008 Everware-CBDI Inc 14. 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.
© 2008 Everware-CBDI Inc 15. 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
© 2008 Everware-CBDI Inc 16. 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.
Distinguish between planned/expected support and current/actual support achieved by an
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
Distinguish between planned/expected support and current/actual support achieved by an
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)
Expected life, if this is a temporary service
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)
Expected life, if this is a temporary service
Predicted changes need within next (n) years, and/or
Expected life, if this is a temporary service
Default Quality of Service plan projects
expectations
© 2008 Everware-CBDI Inc 17. 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 (0, 1 or more)
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
List of Service Names (0, 1 or more)
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
Technology and Comms Protocol used to access (e.g. Web Service (SOAP on HTTP), Active X (DCOM), CS/3 component (MQ series)
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
Technology and Comms Protocol used to access (e.g. Web Service (SOAP on HTTP), Active X (DCOM), CS/3 component (MQ series)
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.
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
an external service.
Statements
Other Information Anything else that the author needs to communicate to readers.
Other Information Anything else that the author needs to communicate to readers.
© 2008 Everware-CBDI Inc 18. Independent Guidance for
Service Architecture and Engineering
Next Steps
Additional Discussion/
Appendix Slides
www.everware-cbdi.com
www.cbdiforum.com 19. 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
© 2008 Everware-CBDI Inc 20. 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
© 2008 Everware-CBDI Inc 21. 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
© 2008 Everware-CBDI Inc 22. 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
© 2008 Everware-CBDI Inc 23. 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)
© 2008 Everware-CBDI Inc