Driving IT from the Business - Delivering SOA
description
Transcript of Driving IT from the Business - Delivering SOA
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