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. © 2008 Everware-CBDI Inc

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) © 2008 Everware-CBDI Inc

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

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

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 © 2008 Everware-CBDI Inc

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

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

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

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

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

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

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

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

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 © 2008 Everware-CBDI Inc

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

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

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

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

http://everware-cbdi.com	223
http://www.everware-cbdi.com	26
http://cbdi.wikispaces.com	25
http://www.slideshare.net	12
http://www.cbdiforum.com	11
https://cbdi.wikispaces.com	1
http://lwsoa.blogspot.com	1
http://www.soakb.com	1
http://translate.googleusercontent.com	1

Service Planning Engagement Overview Slideshare

by Lawrence Wilkes on Jun 18, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

9 Embeds 301

Statistics

Service Planning Engagement Overview Slideshare — Presentation Transcript