1 / 21

Driving IT from the Business - Delivering SOA

Driving IT from the Business - Delivering SOA. Steve Jones. 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

hei
Télécharger la présentation

Driving IT from the Business - Delivering SOA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Driving IT from the Business- Delivering SOA Steve Jones

  2. 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 Moving from Big xxx to Small xxx Bad News BIG Good News SMALL

  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. Level 1 Level 0 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 • 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 • Millions of 'Services' • Disjoint from how the company works • Lack of clear ownership • Duplication • Missed opportunities • Unclear strategy • Driven by techies using Web Services

  12. What does this give? - Classification • Sourcing Strategy • Delivery Model • Business Transformation • Delivery Transformation

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

  14. Service Project Service Project Sign Off Service Project Service Project Service Project Service Project Service Project Service Project Context Update 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 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

  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 don’t 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/A%20methodology%20for%20Service%20Architectures%201%202%204%20-%20OASIS%20Contribution.pdf

More Related