Top Banner

Click here to load reader

Mohamad Afshar Moving Beyond Project Level S O A V1

May 11, 2015

ReportDownload

Technology

  • 1.This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena www.soasymposium.com [email protected]ium.comFounding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors

2. Moving Beyond Project-Level SOA: How to Achieve Departmental and Enterprise SOA 3. Using SOA Tools v Doing SOA Transformation Accounts $Receivable Customer(DataHub)Orders(EJB 3.0)Promotion Management ?(Business Rules) ??Exception ManagementPortal Order Hospital ProcessProcess(Human Workflow) Integration | One Off ServicesSOA | Reusable ServicesOne off Implementation Low Reuse PotentialArchitected for ReuseHigher Reuse Potential For a good overview of service granularity, go to http://www.soaglossary.com/service_granularity.asp 4. Thomas Erl, Author of SOA:Principles of Service DesignIt'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. Moving Beyond Project-Level SOA Dr Mohamad Afshar, Vice President, Product Management | SOA on Application Grid Oracle Fusion Middleware 6. Introduction 7. SOA Adoption StrategiesEnterprise-DrivenIT 100% Full Steam Ahead Management BehindEnterprise SOA Management Skeptical Management not Bought Need Convincing In 100%IT Focused on Success IT Able to Drive ReuseStories to ConvinceAcross DepartmentsProject-Driven Infrastructure-Driven 8. SOA Enablers SOA BenefitEnabler1) Standards-based Interfaces Interoperability 2) Available through standard protocols3) Canonical Data Models (within Domain/ Enterprise)1) Assemble rather than build Ease and Speed of2) Processes, Rules, Events captured in high-level models instead Development of in code3) Service portfolio speeds up development Agility1) Separation of Concerns messaging, workflow, rules, etc. & Reducing Impact of 2) Loose Coupling, e.g. Changes localized to service Changeimplementations Lower3) Abstract Legacy and Proprietary InterfacesCost1) Standards-based interfaces2) Process captured in BPM/ BPEL engines Increased Visibility3) Events captured in CEP engine4) Data services with standardized formats for key data assets1) Portfolio of Services built for reuse Reuse2) Registry/ Repository to aid developers and architects in finding reusable assets 9. Adoption Strategies Tied to SOA Benefits Enterprise- Infrastructure-Project- SOA BenefitDrivenDriven DrivenInteroperabilityUtility Services Ease and Speed of Development Agility & Reducing Impact of Change LowerCost Increased Visibility ReuseUtility Services Its difficult to get reuse if you are doing the project-drivenapproach unless you actively plan and execute to get it! 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 planningEnterprise-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 onincreased cost, effort, immediate project requirementstime 11. Project-Driven SOA 12. Characteristics of Project-Driven SOAKey Characteristics Focus/ Benefits Downfalls Little Involvement from the Some Cost SavingsFlat Incremental ImprovementBusiness Side Line Tactical Agility Only - Scope Restricted to Some Agility through Ease of ChangeIndividual Projects not Service Portfolios SOA Benefit Score Integration / Data Not Investing in DesignMovement Focused Interoperability Standards has a Cost New Projects Build Disparities AddressedEverything from ScratchEase 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 ReuseGovernance burden 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 FinancialsBPEL FLOWSiebel CRME-Business Suite 14. TasmanAve, Inc. Consumer Products Company Lesson Learned Project-Driven SOA SOA projects require the same project Resultsconsiderations such as Performance,Security, HA SOA Foundation ready for future Organizational: EA should champion pan- Significant Cost Savingsenterprise SOA practices as reuse is not a EA prime mover for SOA adoptionprime mover at project level Technology Issues: SOA Skills, New Key Takeaway Technology Readiness Treat middleware mainly as middleware Organizational Issues: EAs role: implementer versus strategic visionary? 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 causesfor sales information interoperability problems SOA Foundation ready for future Organizational: Real-time works !projects Key Takeaway EA is partnering with other IT teams Dont 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. 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. TransitionsEnterprise-Driven 2) Project-Driven to 3) Infrastructure-Driven to Enterprise-Driven IT 100% Full Steam Ahead Enterprise-Driven Management Behind Enterprise SOAManagement Skeptical Management not Bought Need ConvincingIn 100% IT Focused on Success IT Able to Drive Reuse Stories to ConvinceAcross DepartmentsProject-DrivenInfrastructure-Driven 1) Project-Driven to Infrastructure-Driven 18. SOA CAPABILITY MATURITY ModelHigher the Level Higher the Capabilities STRATEGIC GOALSTACTICAL PLANS Able to support business initiatives Refine and improve standards and in a timely and cost-effective manner. processesOPTIMIZED Exploit new business opportunities Processes and procedures - 5 -enabled by SOAEstablish key performance indicatorsquantitatively managed to drive and manage to those metricsbusiness value. MANAGED Leverage BAM to improve businessprocesses. 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 integrationsprojects to demonstrate value Select business-driven projectsOPPORTUNISTIC 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. SOA MATURITY DOMAINS Domain A Collection Of Related Capabilities Architecture Business & StrategyOrganizationalDisciplines InformationOrganization Infrastructure Governance Technology- Projects, DominatedPortfolios &OA&M*Services* OA&M Operations, Administration & Management 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-DrivenSYSTEMATIC- 3 - OPPORTUNISTIC Infrastructure-Driven- 2 - Project-Driven AD HOC- 1 -NO SOA- 0 - 21. Project-Driven to Infrastructure-Driven 22. What You Will and Wont 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. Characteristics of Infrastructure-Driven SOAProjectsRecommendations Downfalls Integration + MDM Standardize on SOA Requires Buy-inPlatform Consolidation / Mainframe Shared Budgeting forMigration Focus on Use of Industry Platform and UtilityStandards ServicesSOA BenefitScore Bring in Design Standards Ownership over PlatformInteroperabilityfor Repeatability and Utility Services Ease and Build and Manage Not Investing in BusinessSpeed ofReusable ArtifactsServices limits ROI andDevelopment ServicesInteroperability Reducing Agility Limited Since there Business RulesImpact of is no Portfolio of Business Data Models ServicesChangeSchemas, Transforms,Increased Anything Not StandardizedetcVisibilityhas Downfalls of Project- Governance Policies to Driven ApproachReuse Encourage Building, Reuseof Assets + Operations 24. SOA Governance for Infrastructure-Driven Service OwnershipCapacity Planning Projects / ServiceService Lifecycle Gov Enforce Service Levels Operations LifecycleShared Artifacts Enforce Policies 25. Syntax-Brillian Lesson Learned Currently adopting a Project-Driven Executive buy in critical forapproach to SOAproject success Improved Customer Relationship Test, Test, .. And Test someManagement 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. 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 todevelop processes closest to the business processesbackend system first EA handled by VP of Applications Issues: Time to market 27. Secure Path Lessons Learned: Currently adopting a Ente