Independent Insight for Service Oriented Practice Techniques Toward a Service Oriented Architecture...

Independent Insight for Service Oriented Practice

www.cbdiforum.com

Techniques Toward a Service Oriented Architecture

John Dodd

© 2005 CBDI Forum Limited

Agenda

Techniques for SOA Service Portfolio Planning Rich Service Specification Solution-Driven Service Delivery

Organizing for SOA Teams Process

I’ll assume you know what SOA means Written from perspective of enterprise committed to using SOA to improve its

applications and interactions with partners Not from perspective of organization that plans to sell services


Service Portfolio Planning

Identifies the set of software services your enterprise needs Defines the policies

Govern how service acquisition and usage proceeds Defines “default” non-functional attributes of services

Quality-of-service Standards to be followed Overridden or extended for given domains, services or

operations

This up-front effort does not deliver any software Typical objective for the Plan:

more flexible software that will support more adaptable business processes and easier integration between applications

Ensures that service acquisition and usage is orderly, in enterprise’s best interests, aligned to business objectives


Features of Service Portfolio Plan (1)

Does not identify all operations, focus is on services & service scope

operations defined as service provisioning authorized

Operations defined as needed by Solution teams the Plan enables operations to be assigned to services

“Core business services” driven from enduring business concepts (resources, things, entities), not business processes (functions, activity, capability)

The Plan itself is big -- so built incrementally a business domain at a time according the business priorities


Features of Service Portfolio Plan (2)

Services View

(consuming developers)

Deployment View

(operations)

Implementation View

(service developers)

Organizes services into layers

Three views of Services in Plan Service View Implementation View Deployment View


Services Organized into Layers

Process Services(optional layer)

Order FulfillmentService

Core Business Services(“backbone” layer)

Underlying Services(if required)

Stock Movements ServiceProductsService

Orders Service

Stock Management Service

Purchasing(from highly generic component)

Order System

Stock ControlApplication

Product DevSystem

Application Layer(UI, may be more)

Utility ServicesCurrencyConversionServiceAddressReformatter

AccountsReceivableAPI(from legacy Accounting System)

Stock Reordering


Three Views of Planned Services

Deployment View

Service ViewOrders Service

Accounts Receivable APIProducts Service

Implementation View

a: applicationServer a: Mainframe

<<SOAP over JMS>>

EJB Container

Order Fulfillment

Stock Management

Product Management

TP Monitor

Ordering Component

Purchasing Component

Sales And Billing

Accounting Package

Stock

Reordering<<quasiComponent>>

Ordering

Component

Stock

Movements

<<component>>Product

ManagementProducts Service

<<legacySystem>>

Accounting

Package

Accounts

Receivable API

Accounts Payable API

Orders

Service


Domains

Business Domain : “Major logical partition of an enterprise consisting of a set of well-related business concepts and the business processes which maintain concept instances”

Example:

Business Service Bus: A collection of related services for a given business domain (such as Human Resources, Logistics, CRM, etc) that follows a certain set of conventions and standards relevant to that domain.

Aim to develop a BSB for each business domain

PURCHASING

MANUFACTURING

INVENTORY

DISTRIBUTION

MARKETING

SALES & BILLING

HUMAN RESOURCESFINANCE

FACILITIES


Business Service Bus Plan and deploy a separate Software Service Portfolio for each domain Includes a “business service bus” of “core business services” for each

domain

Breaks architecture design effort into manageable units – “divide & conquer” Services of domain can share

a semantic model instance data lower-level utility services data storage (perhaps) WS-standards quality-of-service other policies

Inter-domain service dependencies disallowed or minimized, to simply software maintenance

«businessServiceBus» InventoryServices

LocationsManagement

StockTakingService

StockAcceptanceService

StockIssue & Requisition Service

StockMonitoringService

InventoryDesignService


Rich Service Specifications

Service signatures do not explain enough WSDL is not good at explaining service behaviour

Service Specification Sections Interface Definition (signatures of operations) Behaviour Definition (without pre-empting how implemented) Service Information model (possible service states) Mandatory Message Patterns Properties and Features Quality of Service (variations from Portfolio Plan defaults) Standards Conformance (variations from SOA defaults)

Non-functional

spec.

Functional

spec.


Service Information Model

Stock Admin Service

allocateStock( )orderStock( )newProduct( )etc

Product

identifier: Number6name: String25totalStock: Number11

*

1

Warehouse

code: Number6name: String25address: Line[4]

1

*

Stock Item

actual: Number9available: Number9allocated: Number9location: String8

1

*holds

1

*

stored as

knowsknows

1. For Product:totalStock=SUM of actual Stock Items

2. For Stock Item:actual = available + allocated

3. For Stock Item- - location cannot be used for two stock Items (different products)(location + associated Warehouse) IS UNIQUE

4. For Stock Item - - same Product can be stored in more than one location of a Warehouse(location + associated Product) NOT UNIQUE

5. For Warehousecode IS UNIQUE


Pre- and Post-Condition

CONTEXT: StockAdminService :: allocateStock (inProductId, inWarehouseCode, inQuantity, outResult)

DESCRIPTION: Transfers a quantity of stock, held at a specific location in a particular Warehouse, from being “available” to “allocated”. (Does not record which order the stock is allocated to.)

PRE: all inputs supplied andStockItem exists for input product and warehouse

POST: if available stock greater than inQuantity then:decrement available stock by inQuantity and increment allocated stock by inQuantity andoutResult is “OK, stock allocated”

else outResult is “insufficient stock”

PRE: all inputs supplied andStockItem does not exist for input product and warehouse

POST: outResult is “product not held at this warehouse”


Solution-Driven Delivery of Services

Only acquire the operations you need for underway or imminent projects You can’t acquire the whole portfolio at once, you have to do it a chunk at

a time Why not do it according to current demand? Further ops. added later If other operations come in the service you acquire, that’s OK It is governed by the Plan – service structure, standards, QoS, policies

Other strategies: Services in Advance

Acquire services before Solution Delivery projects initiated Common situation: services already available from supplier of your

installed enterprise application packages Projects speeded up, not waiting for services High up-front cost, may result in unused services

Services By Opportunity Only acquire services (as per plan, in advance) that are fast or low

cost to obtain E.g. external supplier, part of package, can wrap legacy Lower up-front cost, may need more compromises


Software Solution Projects

Should be driven by Business Process Improvement projects these are non-IT projects focused on designing new business

processes, reengineering business processes, or improving processes (incrementally)

improvements often require IT support e.g. integrating two applications using WS e.g. integrating with partners via web services

BPI projects should be driven by business priorities based on business strategies, targets, goals, etc.

Operations delivered are then based on business priorities not what’s easiest not what IT believes is most important nor what’s most technical fascinating

Business Goals

BPI Projects

Software Solution projects

ServiceDeliverypriorities


Golden Rules

Keep Service Development and Application Development separate Work done in “twin tracks” Solution developers should not be building/testing acquired

services Service implementers are not a part of Solution teams

Separation helps to ensure: Service operations are built/acquired for sharing – to be used in

multiple solutions Solution developers code to the service specification; they do not

utilize knowledge of how implemented Strong subdivision of labour and responsibility

Services are only accessed through their interfaces calling software codes to the spec, not implementation knowledge implementation can change without impact on consumer consumer and service tester follow same specification


IT Teams & the project “services” they perform

Application Dev.Service Provisioning

Service Architecture

Service Implementation

Bus. Process Design Service OperationsDesign/Refine S PortfolioApproval Activities Design/Refine E S BusDesign/Refine S SecurityAnalyze Performance

Specify ServiceOrganize Service Prov’gCertify ServiceImprove Service Spec.

Plan for BPIRedesign Bus. ProcessRollout Imp. Bus. Process

Deploy ServicesOperate ServicesMonitor ServicesTune Services

Construct Automation UnitTest Automation UnitFix Automation Units

Bus. Strategy & Arch. IT Strategy & Arch. Systems OperationsInstall OperateMonitorTune

HardwareNetworksMiddlewareApplications

Create IT StrategyDefine IT ArchitectureImplement IT ArchitectureVerify ESB Compatibility

Design Software SolutionConstruct Softw. SolutionFix Solution

Capture Business StrategyDefine Bus. ArchitectureImplement Business Arch.

Strategic TeamsService Consumption TeamsService Provider Teams

Main interactions between teams


Layered View of Teams: Main Direction of Work Flow

Business Strategy

and Architecture

Business Process

Design

(planning)

Business Process

Design

(improvement)

Application

Development

(soln. design)

Application

Development

(soln.construction)

Systems

Operations

IT Strategy

and Architecture

Service Archi-

tecture (portfolio

and platform)

Service

Provisioning

Service

Implementation

Service

Operations

BUSINESS STRATEGIC

PLAN & ARCHITECT

DESIGN & SPECIFICATION

DESIGN, CODE & TEST

PRODUCTION RUNNING


Business Process Improvement drives SOA success

RedesignBusiness Process

BUSINESS PROCESS DESIGN APPLICATION DEV. SERVICE PROVISIONING SERVICE IMPLEMENTAT’N

DesignSoftwareSolution

SpecifyService

CertifyService

[Approved Solution Spec]

[Required ServiceDescrip-

tion]Construct

AutomationUnit

[Automation Unit

Spec]

[ApprovedServiceSpec]

TestAutomation

Unit

[externalprovisioning]


[AcceptanceTested

Service]

ConstructSoftwareSolution

[CertifiedService]

Rollout ImprovedBusiness Process

[AcceptanceTested

Solution]

[ApprovedProcess Design]

[Justifi-cation forProcessredesign]


[ImplementedBusiness ProcessImprovement]


RedesignBusiness Process

BUSINESS PROCESS DESIGN APPLICATION DEV. SERVICE PROVISIONING SERVICE IMPLEMENTAT’N

DesignSoftwareSolution

SpecifyService,OrganizeProvis’g

CertifyService

[Approved Solution Spec]

[Required ServiceDescrip-

tion]Construct

AutomationUnit

[Automation Unit

Spec]


TestAutomation

Unit

[externalprovisioning]


[AcceptanceTested

Service]

ConstructSoftwareSolution

[CertifiedService]

Rollout ImprovedBusiness Process

[AcceptanceTested

Solution]



Imp

lem

en

ted

Bu

sin

ess

Pro

cess

Imp

rovem

en

t]

[selectedprocess]

Plan for BPI

[Portfolio Fragment for Solution]

[Verified Fragment]

BUSINESS STRATEGYAND ARCHITECTURE

IT STRATEGY & ARCH.

DefineIT StrategyDefine

Business Strategy

CreateBusiness

Architecture

Create IT Architecture

Verify ESB Compatibility

SERVICE PLANNING AND ARCHITECTURE

Design/RefineSoftware ServicePortfolio Plan

Design/RefineEnterprise Service Bus Design

ApproveService & AUSpecification

ApprovePortfolio

Fragment

[SPP]

[goals, etc.]

[goals,targets etc.]

[priorityprocesses]

[BPIPlan]

Assess Fitwith Strategy

[goals,targets]

[ESBdesign]

[Technical Infrastructure Design, Policies]

[IT goals, etc.]

[Technical Infrastructure Design, Policies]

[SPP][SPPchanges]

[business models]

[business models]

[SPPchanges][SPP]

[candidate services]

Go

vern

ed b

y S

trat

egy,

Arc

hit

ectu

re &

Po

rtfo

lio

Pla

n[bus. andIT goals]

[ESBdesign]

[spec.changes]

[proposed serviceand AU spec.]


Summary

Focus was on 3 specific techniques for SOA Where may be different from “establishment” wisdom for SOA

Service Portfolio Plan Defines services, policies, default QoS & standards to follow Proposes set of services, not operations Establishes a framework for service acquisition & management

Business Service Bus per domain this is not the Enterprise Service Bus -- that’s needed too

Rich Service Specifications – for implementers, testers, consumers Service provisioning driven by Solutions being developed SOA & IT teams

Twin track: solutions & services separate A service-based IT organization?

a project is performed by orchestrating other services


www.cbdiforum.com

Independent Insight for Service Oriented Practice Techniques Toward a Service Oriented Architecture...

Documents

Transcript of Independent Insight for Service Oriented Practice Techniques Toward a Service Oriented Architecture...