Mohamad Afshar Moving Beyond Project Level S O A V1


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mohamad Afshar Moving Beyond Project Level S O A V1

  1. 1. This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena Founding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors
  2. 2. Moving Beyond Project-Level SOA: How to Achieve Departmental and Enterprise SOA
  3. 3. Using SOA Tools v Doing SOA Transformation Accounts $ Receivable Customer (DataHub) Orders (EJB 3.0) Promotion Management ? (Business Rules) ? ? Exception Management Portal – Order Hospital Process Process (Human Workflow) Integration | One Off Services SOA | Reusable Services One off Implementation Low Reuse Potential Architected for Reuse Higher Reuse Potential For a good overview of service granularity, go to
  4. 4. Thomas Erl, Author of SOA:Principles of Service 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.”
  5. 5. <Insert Picture Here> Moving Beyond Project-Level SOA Dr Mohamad Afshar, Vice President, Product Management | SOA on Application Grid Oracle Fusion Middleware
  6. 6. <Insert Picture Here> Introduction
  7. 7. SOA Adoption Strategies Enterprise-Driven IT 100% Full Steam Ahead Management Behind Enterprise SOA Management Skeptical – Management not Bought Need Convincing In 100% IT Focused on Success IT Able to Drive Reuse Stories to Convince Across Departments Project-Driven Infrastructure-Driven
  8. 8. SOA Enablers SOA Benefit Enabler 1) Standards-based Interfaces Interoperability 2) Available through standard protocols 3) Canonical Data Models (within Domain/ Enterprise) 1) Assemble rather than build Ease and Speed of 2) Processes, Rules, Events captured in high-level models instead Development of in code 3) Service portfolio speeds up development Agility 1) Separation of Concerns – messaging, workflow, rules, etc. & Reducing Impact of 2) Loose Coupling, e.g. Changes localized to service Change implementations Lower 3) Abstract Legacy and Proprietary Interfaces Cost 1) Standards-based interfaces 2) Process captured in BPM/ BPEL engines Increased Visibility 3) Events captured in CEP engine 4) Data services with standardized formats for key data assets 1) Portfolio of Services built for reuse Reuse 2) Registry/ Repository to aid developers and architects in finding reusable assets
  9. 9. Adoption Strategies Tied to SOA Benefits Enterprise- Infrastructure- Project- SOA Benefit Driven Driven Driven Interoperability Utility Services Ease and Speed of Development Agility & Reducing Impact of Change Lower Cost Increased Visibility Reuse Utility Services It’s difficult to get reuse if you are doing the project-driven approach unless you actively plan and execute to get it!
  10. 10. More Effort Now Less Pain Later Initial service delivery cost, effort Subsequent Service and time is increased due to Governance burden service identification and service reduced portfolio planning Enterprise-Driven Enterprise-Driven Project-Driven Infrastructure-Driven Infrastructure-Driven Less Effort Now Pain Later Initial service delivery cost, effort Subsequent Service and time is reduced because the Governance requires analysis scope is based on increased cost, effort, immediate project requirements time
  11. 11. <Insert Picture Here> Project-Driven SOA
  12. 12. Characteristics of Project-Driven SOA Key Characteristics Focus/ Benefits Downfalls • Little Involvement from the • Some Cost Savings Flat • Incremental Improvement Business Side Line • Tactical Agility Only - • Scope Restricted to • Some Agility through Ease of Change Individual Projects not Service Portfolios SOA Benefit Score • Integration / Data • Not Investing in Design Movement Focused Interoperability Standards has a Cost • New Projects Build • Disparities Addressed Everything from Scratch Ease and Speed through Integration of Development • Not Focused on Reuse • Missing Reusable Reducing Business Services Impact of • Potential Proliferation of Change Unshareable Services Increased • Introduces New Silos and Visibility Related Integration and Reuse Governance burden
  13. 13. Project | Integration Scenarios: •Siebel Order Capture to Oracle ATP •Oracle Configurator to Siebel Order Capture •Siebel Order Capture to G-Log •Siebel Order Capture to Oracle Financials BPEL FLOW Siebel CRM E-Business Suite
  14. 14. TasmanAve, Inc. Consumer Products Company • Lesson Learned • Project-Driven SOA • SOA projects require the same project • Results considerations such as Performance, Security, HA • SOA Foundation ready for future • Organizational: EA should champion pan- • Significant Cost Savings enterprise SOA practices as reuse is not a • EA prime mover for SOA adoption prime mover at project level • Technology Issues: SOA Skills, New • Key Takeaway Technology Readiness • Treat middleware mainly as middleware • Organizational Issues: EA’s role: implementer versus strategic visionary?
  15. 15. TasmanAve, Inc. Computer Peripherals Company • Lesson Learned • Project-Driven SOA • Technical: Adapters can introduce their • Results: own issues • Sales team moving towards single site • Disparity in standards adoption causes for sales information interoperability problems • SOA Foundation ready for future • Organizational: Real-time works ! projects • Key Takeaway • EA is partnering with other IT teams • Don’t expect 100% plug-play from day • Technology issues: SOA Skills, XML one modeling incompatibilities • Organizational issues: Gain confidence in event-based real-time business processing
  16. 16. What is a Business Service? A business service is a software solution that provides functions related to one or more business processes. Business services may be composed from one or more fine-grained utility, entity or task services and are described using business semantics.
  17. 17. Transitions Enterprise-Driven 2) Project-Driven to 3) Infrastructure-Driven to Enterprise-Driven IT 100% Full Steam Ahead Enterprise-Driven Management Behind Enterprise SOA Management Skeptical – Management not Bought Need Convincing In 100% IT Focused on Success IT Able to Drive Reuse Stories to Convince Across Departments Project-Driven Infrastructure-Driven 1) Project-Driven to Infrastructure-Driven
  18. 18. SOA CAPABILITY MATURITY Model Higher the Level – Higher the Capabilities STRATEGIC GOALS TACTICAL PLANS Able to support business initiatives Refine and improve standards and in a timely and cost-effective manner. processes OPTIMIZED Exploit new business opportunities Processes and procedures - 5 - enabled by SOA Establish key performance indicators quantitatively managed to drive and manage to those metrics business value. MANAGED Leverage BAM to improve business processes. SOA concepts consistently applied - 4 - Standardize approach and products facilitating sharing and reuse Drive widespread adoption SYSTEMATIC Establish governance Focused on simple quick win - 3 - Apply SOA to simple integrations projects to demonstrate value Select business-driven projects OPPORTUNISTIC amenable to SOA (e.g. simple portals) - 2 - Build confidence with business owners Experimenting with and learning Get experience building, deploying, SOA concepts and consuming services AD HOC SOA not being pursued - 1 - Investigate applicability of SOA NO SOA - 0 -
  19. 19. SOA MATURITY DOMAINS Domain – A Collection Of Related Capabilities Architecture Business & Strategy Organizational Disciplines Information Organization Infrastructure Governance Technology- Projects, Dominated Portfolios & OA&M* Services * OA&M – Operations, Administration & Management
  20. 20. Starting Point for Each Approach Corollary: Have to Ensure OPTIMIZED that you have all capabilities - 5 - at levels lower than the one at which you start MANAGED - 4 - Enterprise-Driven SYSTEMATIC - 3 - OPPORTUNISTIC Infrastructure-Driven - 2 - Project-Driven AD HOC - 1 - NO SOA - 0 -
  21. 21. <Insert Picture Here> Project-Driven to Infrastructure-Driven
  22. 22. What You Will and Won’t get out of it? • Some Cost Savings • Shared Platform / Enterprise Nervous System • Reuse of Application Agnostic / Utility Services • Improved Interoperability Within Silos • Reduced Integration Between Silos • Ability to Continue with Existing Methodology(/s)
  23. 23. Characteristics of Infrastructure-Driven SOA Projects Recommendations Downfalls • Integration + MDM • Standardize on SOA • Requires Buy-in Platform • Consolidation / Mainframe • Shared Budgeting for Migration • Focus on Use of Industry Platform and Utility Standards Services SOA Benefit Score • Bring in Design Standards • Ownership over Platform Interoperability for Repeatability and Utility Services Ease and • Build and Manage • Not Investing in Business Speed of Reusable Artifacts Services limits ROI and Development • Services Interoperability Reducing • Agility Limited Since there • Business Rules Impact of is no Portfolio of Business • Data Models Services Change Schemas, Transforms, Increased • Anything Not Standardized etc Visibility has Downfalls of Project- • Governance – Policies to Driven Approach Reuse Encourage Building, Reuse of Assets + Operations
  24. 24. SOA Governance for Infrastructure-Driven Service Ownership Capacity Planning Projects / Service Service Lifecycle Gov Enforce Service Levels Operations Lifecycle Shared Artifacts Enforce Policies
  25. 25. <Insert Picture Here> Syntax-Brillian • Lesson Learned • Currently adopting a Project-Driven • Executive buy in critical for approach to SOA project success • Improved Customer Relationship • Test, Test, .. And Test some Management more! It is never enough! • Increased Fulfillment Capability • Key Takeaway • EA managed by the CIO • Factor in additional time when • Issues: dealing with hosted environments • Disparate Systems • Change Management
  26. 26. <Insert Picture Here> • HELIO • Lesson Learned • Project-Driven to Infrastructure- • Involve & train in-house technical Driven approach resources • Started out as an integration project, • Key Takeaway evolved into reusing components • When working with startup across the enterprise companies, architect and • Introduced agility & interoperability to develop processes closest to the business processes backend system first • EA handled by VP of Applications • Issues: • Time to market
  27. 27. <Insert Picture Here> Secure Path • Lessons Learned: • Currently adopting a Enterprise- • Critical to devote time upfront to Driven approach to SOA finalize data contracts • Extremely quick turnaround time to • Enterprise-wide SOA Roadmap onboard new customers established • Platform agility supports rapidly • Reusing a number of services / growing business needs processes • Very active EA led by their CTO • Key Takeaway: • Issues: • Focus on Business Processes • Scalability & Performance issues and not the Technology with their previous .Net platform
  28. 28. <Insert Picture Here> Project-Driven to Enterprise-Driven
  29. 29. What You Will and Won’t get out of it? • Increased Cost Savings and ROI • Dramatically Reduced Cost of Integration and Reduced IT Burden • New Processes Automated in Less Time and With Less Effort • Agility through Shared Business Services and Service Portfolios • Interoperability across Silos • Methodology focused on Building and Using Reusable Assets
  30. 30. Characteristics of Enterprise-Driven SOA Projects Recommendations Downfalls • Process Automation / BPM • Enterprise-Centric is NOT • Have to Invest Enterprise-Wide! • Monitoring and • Has to be Managed to Optimization • Alignment with Business Deliver Results Strategy & Involvement of • Application Consolidation • Requires Organizational Business People Alignment SOA Benefit Score • Perform Cross-Project • Prone to Dictatorship Interoperability Planning & Funding • Ensure that EA Initiatives • Build and Manage Ease and & Policies are Adopted by Reusable Artifacts Speed of Divisional IT Groups Development • Process Modeling for • Cost Associated with Services Reducing Standardization have to be Impact of • Data Services Balanced and Managed Change • Portfolio Planning • Works Best with Changes Increased • Leverage Architecture & in Methodology Visibility Design Standards Reuse • Enact as Much Governance as Required
  31. 31. Business Service Portfolio Plan Now 18 Months 12 Months Service Service Service Service Service Service Marketing Customer Marketing Service Service Customer Warehouse Marketing Conceptual Service Customer Marketing Services Service Customer Portfolio Customer Finance Service Service Service Service Service Customer Service Customer Service Service Customer Service Customer Concrete Customer Service Customer Customer Customer Customer Service Services Service Customer Portfolio Marketing Customer 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
  32. 32. SOA Governance for Enterprise-Driven Financial People Service Funding Model Portfolio Roles & Responsibilities Service Usage Fees Projects Portfolios EA Group End to End Platform Funding Services Portfolios Service & Process Owners ERP, Legacy App Portfolios Service Ownership Capacity Planning Project Service Lifecycle Gov DRIVEN BY Enforce Service Levels EXECUTIVES Operations Execution Shared Artifacts Enforce Policies Strategic SOA Platform Reference Architectures Data Ownership Architectural Standards Enforce Platform Decisions Shared Foundation Srvcs Data Standards Blueprints & Patterns Technology Data Quality Architecture Information For a White Paper go to
  33. 33. Put your company <Insert Picture Here> Logo here please • Large Canadian Telco • Lessons learned • Infrastructure-to-Enterprise • Technical: Demand higher quality, • SOA means faster time to better governed infrastructure services production, better re-use • Organizational: Wrapping legacy • Moderately active EA oversight services and incorporating them in a • Challenges overcome strategic vision demonstrates the benefits of reuse • Technology: Setting proper granularity for strategic services • Future enterprise-centric service plans: wrapped around legacy services Continue top-down analysis; use vendor- provided Web services as legacy silos • Organizational: Instilling a culture of service reuse • Advice: Top-down, strategic analysis is vital for even the most tactical of projects
  34. 34. Put your company <Insert Picture Here> Logo here please • Fortune 500 Shipping Co. • Lessons learned • Major Enterprise SOA Initiative (phased • Technical: Must design services in roll-out over 3 years, concurrent with advance to support inevitable larger, legacy maintenance) more complex service compositions • $250K pilot project was valuable • Organizational: Making everyone learning experience plus high ROI understand the strategic goals is key to getting their support • Enterprise Architecture team has been central to pilot and main SOA projects • Future enterprise-centric service plans: Establish a strong business entity service • Challenges overcome: layer for broad reuse and business • Technology: Assessing maturity of alignment Service Activity Management • Advice: Success with SOA impossible technologies without successfully enforcing internal • Organizational: Enforcing Internal design standards on a consistent basis Design Standards
  35. 35. <Insert Picture Here> Infrastructure-Driven to Enterprise-Driven
  36. 36. <Insert Picture Here> Level 1: 1999-2003 Level 2: 2003-2005 Level 3: 2005 Onwards • SEMCI application selected • Project-based services selected • Business & IT create 5 year business and refactored to orchestration of srvcs (driven by project budget) IT roadmap; Business blueprints defined for • SOAP, WSDL, UDDI standards • BPEL, WSIF, WS-Security standards all LOB • WSM, UDDI SOA tools selected, • BPEL and XML security/acceleration • Funding model changed from project-based leveraged existing message bus appliance selected to enterprise-based • PCAC (P&C Architects Collective) • Integration Reference Arch v1.0, App • Rules, Portal, BPM engines selected formed (no org changes) Reference Arch. v2.0 created • SOA “Cookbooks” for all SOA tools (maint.) • Application Reference Arch v1.0 • Formal EA group under newly • Business architecture defining Business completed & Projects Checked formed CTO (EAs centralized) Services Portfolio • “Do No Harm” governance policy • Architect job family defined (30 • SOA Governance tools selected, esp. • Project scoring under definition with people’s title changed from architect) Business Services Catalog feedback • SOA “Cookbooks” defined for • SOA Service Committee, Standards • No Explicit Metrics to Measure existing SOA tools (development) Committee Progress on SOA Road • Score Projects to Influence Business • Key business metrics and KPIs identified • No Reuse Decisions – but Scoring Project-level and communicated monthly
  37. 37. <Insert Picture Here> Conclusions
  38. 38. Conclusions Tactical: • Avoid & Manage Service Proliferation • Involve Business Audience for Business Services • Incrementally Adopt a SOA Methodology • Understand the Governance Consequences - Pain Now or Pain Later Strategic: • Target SOA Benefits you Need and Focus on Delivering Them • Pick one of the three SOA Strategies Discussed • Build Your SOA Roadmap & Manage Program as a Program • Don’t Over or Under Govern – Avoid Dictatorship!
  39. 39. Oracle Fusion Middleware
  40. 40. SOA Adoption Strategy Enterprise-Driven IT 100% Full Steam Ahead Management Behind Enterprise SOA Management Skeptical – Management not Bought Need Convincing In 100% IT Focused on Success IT Able to Drive Reuse Stories to Convince Across Departments Project-Driven Infrastructure-Driven