<Insert Picture Here> Enterprise (-wide) SOA?! Thoughts beyond technology and XML

Size: px
Start display at page:

Download "<Insert Picture Here> Enterprise (-wide) SOA?! Thoughts beyond technology and XML"

Transcription

1 <Insert Picture Here> Enterprise (-wide) SOA?! Thoughts beyond technology and XML Clemens Utschig-Utschig, Oracle SOA Product Management

2 What is SOA? -Oriented Architecture is an approach to: Rationalize enterprise integration Enable new breeds of process driven applications Re-use existing services to build new value mainframe credit check + CRM + web portal + extra logic = new online instant credit check SOA heavily relies on standards to ease system connectivity and preserve investment: Standard data format Standard interface definitions Standard wire protocols Standard security protocols

3 What is SOA, again..? Let s agree on vocabulary first.. The means by which the needs of a consumer are brought together with the capabilities of a provider Capability A real-world effect that a service is able to provide to a service consumer (SC) SOA Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides uniform means to offer, discover, interact with, and use capabilities to produce desired effects consistent with measurable pre-conditions and expectations Execution Context The means of communication between SC and SP. E.g. SOAP, REST, RPC.. from the OASIS SOA Reference Model

4 Take-away? We talk about SOA and usually mean the execution context (= tech)! <Insert Picture Here>

5 SOA Adoption Strategies Enterprise-Driven IT 100% Full Steam Ahead Management Behind Enterprise SOA Project-Driven Management Skeptical Need Convincing IT Focused on Success Stories to Convince Management not Bought In 100% IT Able to Drive Reuse Across Departments Infrastructure-Driven

6 Adoption strategies tied to SOA benefits SOA Benefit Enterprise- Driven Infrastructure- Driven Project- Driven Interoperability Utility s Agility & Lower Cost Ease and Speed of Development Reducing Impact of Change Increased Visibility Reuse Utility s It s difficult to get reuse if you are doing the project-driven approach unless you actively plan and execute to get it!

7 More Effort Now Initial service delivery cost, effort and time is increased due to service identification and service portfolio planning Less Pain Later Subsequent Governance burden reduced Enterprise-Driven Project-Driven Less Effort Now Initial service delivery cost, effort and time is reduced because the analysis scope is based on immediate project requirements Pain Later Infrastructure-Driven Subsequent Governance requires increased cost, effort, time

8 Project-Driven SOA <Insert Picture Here>

9 Characteristics of Project-Driven SOA Key Characteristics Focus/ Benefits Downfalls Little Involvement from the Business Side Scope Restricted to Individual Projects Integration / Data Movement Focused New Projects Build Everything from Scratch Not Focused on Reuse Some Cost Savings Flat Line Some Agility SOA Benefit Interoperability Ease and Speed of Development Reducing Impact of Change Increased Visibility Reuse Score Incremental Improvement Tactical Agility Only - through Ease of Change not Portfolios Not Investing in Design Standards has a Cost Disparities Addressed through Integration Missing Reusable Business s Potential Proliferation of Unshareable s Introduces New Silos and Related Integration and Governance burden

10 Project Integration Scenarios: Replicate orders across systems Datapump Sort of EAI 2.0 BPEL FLOW Siebel CRM E-Business Suite

11 TasmanAve, Inc. Computer Peripherals Company Project-Driven SOA Results: Sales team moving towards single site for sales information SOA Foundation ready for future projects EA is partnering with other IT teams Technology issues: SOA Skills, XML modeling incompatibilities Organizational issues: Gain confidence in event-based real-time business processing Lesson Learned Technical: Adapters can introduce their own issues Disparity in standards adoption causes interoperability problems Organizational: Real-time works! Key Takeaway Don t expect 100% plug-play from day one.

12 Take-away? Project-wide SOA, integration, standards-based. s? <Insert Picture Here>

13 Thomas Erl, Author of SOA: Principles of Design It's tough to incrementally adopt SOA when you're delivering services tactically because each tactically delivered service essentially becomes legacy once SOA is properly adopted.

14 Infrastructure-Driven SOA <Insert Picture Here>

15 Characteristics of Infrastructure-Driven SOA Projects Integration + MDM Consolidation / Mainframe Migration SOA Benefit Interoperability Ease and Speed of Development Reducing Impact of Change Increased Visibility Reuse Score Recommendations Standardize on SOA Platform Focus on Use of Industry Standards Bring in Design Standards for Repeatability Build and Manage Reusable Artifacts s Business Rules Data Models Schemas, Transforms, etc Governance Policies to Encourage Building, Reuse of Assets + Operations Downfalls Requires Buy-in Shared Budgeting for Platform and Utility s Ownership over Platform and Utility s Not Investing in Business s limits ROI and Interoperability Agility Limited Since there is no Portfolio of Business s Anything Not Standardized has Downfalls of Project- Driven Approach

16 SOA Governance for Infrastructure-Driven Projects / Lifecycle Ownership Lifecycle Gov Shared Artifacts Capacity Planning Enforce Levels Enforce Policies Operations

17 Take-away? Infrastructure wide SOA = pure technology, supporting.. <Insert Picture Here>

18 Enterprise-Driven SOA <Insert Picture Here>

19 Characteristics of Enterprise-Driven SOA Projects Process Automation / BPM Monitoring and Optimization Application Consolidation SOA Benefit Interoperability Ease and Speed of Development Reducing Impact of Change Increased Visibility Reuse Score Recommendations Enterprise-Centric is NOT Enterprise-Wide! Alignment with Business Strategy & Involvement of Business People Perform Cross-Project Planning & Funding Build and Manage Reusable Artifacts Process Modeling for s Data s Portfolio Planning Leverage Architecture & Design Standards Enact as Much Governance as Required Downfalls Have to Invest Has to be Managed to Deliver Results Requires Organizational Alignment Prone to Dictatorship Ensure that EA Initiatives & Policies are Adopted by Divisional IT Groups Cost Associated with Standardization have to be Balanced and Managed Works Best with Changes in Methodology

20 Business Portfolio Plan Now 12 Months 18 Months Conceptual s Portfolio Customer Customer Customer Customer Customer Marketing Marketing Marketing Marketing Finance Warehouse Concrete s Portfolio Customer Customer Customer Customer Customer Customer Customer Customer Customer Customer Customer Marketing The more effort you put in upfront on identifying, refining service candidates, and building a service portfolio plan, the less chance you will have of increased governance burden, overlapping services, versioning

21 SOA Governance for Enterprise-Driven Financial People Roles & Responsibilities EA Group Funding Model Usage Fees End to End Platform Funding Portfolio Projects Portfolios s Portfolios & Process Owners ERP, Legacy App Portfolios Project Execution Ownership Lifecycle Gov Shared Artifacts DRIVEN BY EXECUTIVES Capacity Planning Enforce Levels Enforce Policies Operations Strategic SOA Platform Reference Architectures Enforce Platform Decisions Data Ownership Architectural Standards Shared Foundation Srvcs Data Standards Blueprints & Patterns Technology Data Quality Information Architecture

22 <Insert Picture Here> HELIO Project-Driven to Infrastructure- Driven approach Started out as an integration project, evolved into reusing components across the enterprise Introduced agility & interoperability to business processes EA handled by VP of Applications Issues: Time to market Lesson Learned Involve & train in-house technical resources Key Takeaway When working with startup companies, architect and develop processes closest to the backend system first

23 Take-away? Enterprise-wide SOA = process-centric, governance throughout the enterprise <Insert Picture Here>

24

25 SOA Maturity Domains (Dimensions) Cross-section through a typical slice of the Level-5 SOA maturity stack

26 Starting Point for Each Approach Corollary: Have to Ensure that you have all capabilities at levels lower than the one at which you start Enterprise-Driven Infrastructure-Driven Project-Driven

27 That s it? Level 5 - your company service oriented? <Insert Picture Here>

28 Another view on -Orientation (1) A landscape of your company and how it does business Core competencies E.g. Deliver/manufacture high-quality goods on time Supporting functions E.g. Integrated conversion from plan to manufact g Processes that span / orchestrate the above E.g. From customer call to the delivered product Project level vs. Enterprise WIDE thinking..

29 Another view on -Orientation (2) Defining your services What? Who? Why? How? What is this thing doing in the context of my business, what is the scope? Who are the guys, services using that thing - actors Why does one need another, dependencies What is the process that orchestrates all those what s, implementation details. from Enterprise SOA adoption strategies, 2006, C4Media, Steve Jones

30 Discovery from a different angle.. Discovering your services top down Rather than looking at the structure (which department, where in the chain) focus on the function. Functions are stabler than structure! Rather than looking at the process, look at the what s first. Most companies are structured around their functions, rather than process centric (processes connect these functions!) Process > discovery > drilldown

31 s, the other chunks Virtual s A collection of internal services Trading services Stock ticker > Trading Portal facade Support services A capability that is needed from implementation, but unknown to the business (or they don t care about..) Technical support services E.g. RFID tag reader

32 Conclusion: what is SOA, again..? It s about services! it s about YOUR company s core competencies It s NOT about the fancy technology Although at some level, you probably go after implementing at least some services :D Don t get stuck in the we do BPEL and web-services hence we do SOA trap Attention: Enterprise-wide SOA might lead to change of your organizational culture, not just of the structure (Silos > Weak matrix)!

33 Further readings.. Enterprise SOA adoption strategies C4Media, Steve Jones, 2006 Governance for the enterprise Everything else, that is not about the execution context :D