Driving IT from the Business- Delivering SOA

Steve Jones

Moving from Big xxx to Small xxx

• Business• Large inflexible business

units• Monolithic functions• Big investments

• IT and MIS• Large long running

Projects• Big applications i.e. ERP• Overall infrastructure

• Business• Small agile market based

units• Flexible attributed process• Small investments, quick

payoffs

• IT and MIS• Small self-contained

projects• Web Services• Shared infrastructure

Bad News BIG Good News SMALL

Our Take on the SOA Hype

HOW• SOA is not WS

• SOA is not about BPEL

• SOA is not about ESB

• SOA is not about Technology

• Not driven by the 'How'

Object Oriented Design works because an Object represents a real-world 'thing'.

So why SOA?

Service Oriented Architecture works

because a Service represents

a real world 'what we do'.

OASIS SOA Reference Model – Defining the Terms

• Service Oriented Architecture (SOA)• Service Oriented Architecture is a paradigm for organising

and utilising distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations

• Service• The means by which the needs of a consumer are brought

together with the capabilities of a provider

How to Create Your SOA

• What: Defining the scope of Services, this is about determining what the Services actually are.

• Who: Who are the external actors that drive the services or with which the services interact.

• Why: Identifying why one service talks to another and why external actors interact with the services.

• How: The detail about the processes that co-ordinate the services and also the detail of how a service itself will be implemented.

So what could it look like?

Which enables you to concentrate on …

WHAT you doand WHY …

Then drill down - Manufacturing

Level 1

Same applies to projects

Level 0

Level 1• About managing change

• KISS

• The start of the process, not the end

• Gives a structure for re-using assets

Structure Matters

• Millions of 'Services'• Disjoint from how the company works• Lack of clear ownership• Duplication• Missed opportunities• Unclear strategy• Driven by techies using Web Services

• Clearly defined structure• Defined areas of shared ownership• Driven by how the company works• 'Do it once, well'• Aligned to the business goals• Driven by how the business wants to react• Think about Process second• NOT THE SAME AS ORG CHARTS

What does this give? - Classification

• Sourcing Strategy

• Delivery Model

• Business Transformation

• Delivery Transformation

Rules for Establishing an Enterprise SOA

• DON’T start from the IT side of the business alone• Work with the business to understand the key

business services and their drivers• Create the Enterprise SOA first, then aim to deliver it

tactically• Get the big picture

• Ensure that tactical projects leave the company better off• Deliver the Business Services• Refine the Enterprise SOA• Penalise the projects that make it worse

• Establish clear architectural governance of IT solutions

The Approach – Delivering SOA

Business IT

BusinessSOA

ArchitecturalGovernance

Programme

Sign Off

Update

Context

ProgrammeSOA

ServiceProjectServiceProjectServiceProjectServiceProjectServiceProjectServiceProjectServiceProjectServiceProject

Enterprise SOA is Always Evolving and Growing• Enterprise SOA provide the ultimate context

• Programme SOAs add more information to the Enterprise SOA

• IT and Programme SOAs will identify key technical services that are required

• The Enterprise SOA is a living thing, it will evolve and change as the business requires• If systems are delivered against the Enterprise SOA it is simpler

to see how they must also change• Process is a co-ordination of services, it is NOT a separate

thing• Enterprise SOA applies both to

• Management of existing applications• Delivery of new applications

Service Realisation – SOR isn’t SOA

• Development practices need to change• 'one team – one service' mentality• Contract Driven and Test Driven development• 'Higher' level services may just be meta-data on lower level ones• Architecture becomes much more important• Sourcing strategies

• Building Services is not SOA• Technical SOA is just old IT with new tools

IT Needs to Provide the Infrastructure

• Service Oriented Infrastructure – SOI• Includes all of the software and hardware infrastructure

• Boxes, app servers, integration software, service management

• Needs a clear strategy• Vendors are only just understanding the separation of

integration and services• Debugging, compliance and audit will become more

complex if you don’t plan• Pick the standards, more than the vendors, to back.

Capacity

Service Hosting

Service Management

Drive Down from the Top

• Projects and enterprises should define their Service Architecture FIRST

• Requirements and processes need to be in the context of that architecture

• Architecture needs to be defined so all stakeholders understand

• Needs to be an collaborative exercise

• Once you have the service, THEN think about process• Avoid the '100 step' nightmare• Add hierarchy to the processes• Enable greater flexibility by enabling the small

POA is Not SOAStart Call

Customer Buying?

End

No

GetCustomer

Name

GetCustomerAddress

CheckAddress

ValidAddress?

Yes

No

CreditCheck

GoodCredit ?

No

Yes

SelectProduct

SelectQuantity

ConfirmOrder

OrderConfirmed?

NoYes

ThankCustomer

Yes

SubmitOrder

ProcessNew Order

CheckStock

StockAvailable?

Order NewStock Get Quote Contact

Supplier Create PO

ReceiveGoods

CheckGoods

Add toStock

ReceiveInvoice

CreateShipment

DispatchShipment

DeliverShipment Accepted? Return

Shipment

CreateInvoice

SendInvoice

RequestPayment

ReceivePayment

Willingto Pay?End

AskNicely

DemandMoney

UseLawyers

UseBig Dave

Willingto Pay?

Willingto Pay?

Willingto Pay?

ReceivePayment

No

Yes

No

No

Yes

• Processes tend to be 'end to end'

• Process maps tend to miss horizontal services

•Procurement•CRM

• Process is just Visual Cobol after all

• At the very top level when doing process decomposition its pretty similar

• When you get to actual execution is where Services become much more important

Summary

• Services are business driven• Not a technology decision• Defining a hierarchy of Service• About getting a clear vision for all stakeholders• Avoiding complexity

• Service Oriented Architecture (SOA) requires proper governance

• SOA enables proper Service Oriented Realisation (SOR)• SOR needs a proper Service Oriented Infrastructure (SOI)• SOI needs a proper strategy

References

• 'Toward an acceptable definition of Service' – IEEE Software May/June 2005

• OASIS SOA Reference Model Public Draft - http://www.oasis-open.org/committees/download.php/16630/wd-soa-rm-pr1.doc

• OASIS Contributed SOA Methodology• http://www.oasis-open.org/committees/download.php/15071/A%2

0methodology%20for%20Service%20Architectures%201%202%204%20-%20OASIS%20Contribution.pdf