Driving IT from the Business Delivering SOA

1
Driving IT from the Business- Delivering SOA

• Steve Jones

2
Moving from Big xxx to Small xxx
Bad News BIG
Good News SMALL

• 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

3
Our Take on the SOA Hype

• SOA is not WS
• SOA is not about BPEL
• SOA is not about ESB
• SOA is not about Technology
• Not driven by the 'How'

HOW
Object Oriented Design works because an Object
represents a real-world 'thing'.
4
So why SOA?
Service Oriented Architecture works because a
Service represents a real world 'what we do'.
5
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

6
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.

7
So what could it look like?
8
Which enables you to concentrate on
WHAT you do and WHY
9
Then drill down - Manufacturing
Level 1
10
Same applies to projects

• About managing change
• KISS
• The start of the process, not the end
• Gives a structure for re-using assets

11
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

12
What does this give? - Classification

• Sourcing Strategy
• Delivery Model
• Business Transformation
• Delivery Transformation

13
Rules for Establishing an Enterprise SOA

• DONT 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

14
The Approach Delivering SOA
Business
IT
Architectural Governance
Business SOA
Programme
Programme SOA
15
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

16
Service Realisation SOR isnt 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

17
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 dont plan
• Pick the standards, more than the vendors, to
  back.

Service Management
Service Hosting
Capacity
18
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

19
POA is Not SOA

• 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

20
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

21
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/A20methodology20for20Service20Architectu
  res20120220420-20OASIS20Contribution.pdf