Post on 11-May-2015
Founding Sponsors
This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com
Gold Sponsors
Platinum Sponsors
Silver Sponsors
Moving Beyond Project-Level SOA: How to Achieve Departmental and Enterprise SOA
Using SOA Tools v Doing SOA
?
Process
Architected for Reuse Higher Reuse Potential One off Implementation Low Reuse Potential
SOA | Reusable Services Integration | One Off Services
Promotion Management(Business Rules)?
Accounts Receivable
Customer (DataHub)
Exception ManagementPortal – Order Hospital(Human Workflow)
Orders(EJB 3.0)
?
Process
$
Transformation
For a good overview of service granularity, go to http://www.soaglossary.com/service_granularity.asp
“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.”
Thomas Erl, Author of SOA:Principles of Service Design
<Insert Picture Here>
Moving Beyond Project-Level SOADr Mohamad Afshar, Vice President, Product Management | SOA on Application GridOracle Fusion Middleware
<Insert Picture Here>
Introduction
SOA Adoption Strategies
Enterprise-Driven
Infrastructure-DrivenProject-Driven
Management BehindEnterprise SOA
Management Skeptical –Need Convincing
IT 100% Full Steam Ahead
IT Focused on SuccessStories to Convince
Management not BoughtIn 100%
IT Able to Drive ReuseAcross Departments
SOA Enablers
1) Portfolio of Services built for reuse 2) Registry/ Repository to aid developers and architects in finding
reusable assets Reuse
1) Standards-based interfaces2) Process captured in BPM/ BPEL engines3) Events captured in CEP engine4) Data services with standardized formats for key data assets
Increased Visibility
1) Separation of Concerns – messaging, workflow, rules, etc. 2) Loose Coupling, e.g. Changes localized to service
implementations3) Abstract Legacy and Proprietary Interfaces
Reducing Impact of Change
1) Assemble rather than build 2) Processes, Rules, Events captured in high-level models instead
of in code3) Service portfolio speeds up development
Ease and Speed of Development
1) Standards-based Interfaces2) Available through standard protocols 3) Canonical Data Models (within Domain/ Enterprise)
Interoperability
Enabler SOA Benefit
Agility&
Lower Cost
Adoption Strategies Tied to SOA Benefits
Enterprise-Driven
Utility Services
Utility Services
Infrastructure-Driven
Reuse
Increased Visibility
Reducing Impact of Change
Ease and Speed of Development
Interoperability
Project-Driven SOA Benefit
It’s difficult to get reuse if you are doing the project-driven approach unless you actively plan and execute to get it!
Agility&
Lower Cost
Project-Driven
Enterprise-Driven
Infrastructure-Driven
Subsequent Service Governance requires increased cost, effort, time
Pain LaterInitial service delivery cost, effort and time is reduced because the analysis scope is based on immediate project requirements
Less Effort Now
Subsequent Service Governance burden reduced
Less Pain LaterInitial service delivery cost, effort and time is increased due to service identification and service portfolio planning
More Effort Now
Enterprise-Driven
Infrastructure-DrivenProject-Driven
<Insert Picture Here>
Project-Driven SOA
• 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
Key Characteristics
• Some Cost Savings Flat Line
• Some Agility
• Incremental Improvement• Tactical Agility Only -
through Ease of Change not Service Portfolios
• Not Investing in Design Standards has a Cost
• Disparities Addressed through Integration
• Missing Reusable Business Services
• Potential Proliferation ofUnshareable Services
• Introduces New Silos and Related Integration and Governance burden
Focus/ Benefits Downfalls
Characteristics of Project-Driven SOA
Reuse
Increased Visibility
Reducing Impact of Change
Ease and Speed of Development
Interoperability
ScoreSOA Benefit
Project | Integration
SiebelCRM
E-Business Suite
BPEL FLOW
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
Consumer Products Company• Project-Driven SOA• Results
• SOA Foundation ready for future• Significant Cost Savings
• EA prime mover for SOA adoption• Technology Issues: SOA Skills, New
Technology Readiness• Organizational Issues: EA’s role:
implementer versus strategic visionary?
• Lesson Learned• SOA projects require the same project
considerations such as Performance, Security, HA
• Organizational: EA should champion pan-enterprise SOA practices as reuse is not a prime mover at project level
• Key Takeaway• Treat middleware mainly as middleware
TasmanAve, Inc.
TasmanAve, Inc.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
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.
What is a Business Service?
Transitions
Enterprise-Driven
Infrastructure-DrivenProject-Driven
Management BehindEnterprise SOA
Management Skeptical –Need Convincing
IT 100% Full Steam Ahead
IT Focused on SuccessStories to Convince
Management not BoughtIn 100%
IT Able to Drive ReuseAcross Departments
2) Project-Driven to Enterprise-Driven
1) Project-Driven to Infrastructure-Driven
3) Infrastructure-Driven to Enterprise-Driven
SOA CAPABILITY MATURITY ModelHigher the Level – Higher the Capabilities
NO SOA- 0 -
STRATEGIC GOALS TACTICAL PLANS
SOA not being pursued Investigate applicability of SOA
AD HOC- 1 -
Experimenting with and learning SOA concepts
Get experience building, deploying, and consuming services
Focused on simple quick winprojects to demonstrate value
Apply SOA to simple integrationsSelect business-driven projects amenable to SOA (e.g. simple portals)Build confidence with business owners
OPPORTUNISTIC- 2 -
SOA concepts consistently applied facilitating sharing and reuse
Standardize approach and productsDrive widespread adoptionEstablish governanceSYSTEMATIC
- 3 -
Processes and procedures quantitatively managed to drive
business value.
Establish key performance indicators and manage to those metricsLeverage BAM to improve business processes.
MANAGED- 4 -
Able to support business initiatives in a timely and cost-effective manner.
Refine and improve standards and processesExploit new business opportunitiesenabled by SOA
OPTIMIZED- 5 -
SOA MATURITY DOMAINSDomain – A Collection Of Related Capabilities
Business &Strategy
Organization
Governance
Projects,Portfolios &Services
OrganizationalDisciplines
* OA&M – Operations, Administration & Management
Architecture
Infrastructure
Information
OA&M*
Technology-Dominated
Project-Driven
Enterprise-Driven
Infrastructure-Driven
Starting Point for Each Approach
Corollary: Have to Ensure that you have all capabilitiesat levels lower than the one at which you start
NO SOA- 0 -
AD HOC- 1 -
OPPORTUNISTIC- 2 -
SYSTEMATIC- 3 -
MANAGED- 4 -
OPTIMIZED- 5 -
<Insert Picture Here>
Project-Driven to Infrastructure-Driven
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)
• Integration + MDM• Consolidation / Mainframe
Migration
Projects
• Standardize on SOA Platform
• Focus on Use of Industry Standards
• Bring in Design Standards for Repeatability
• Build and Manage Reusable Artifacts
• Services • Business Rules • Data Models
Schemas, Transforms, etc
• Governance – Policies to Encourage Building, Reuse of Assets + Operations
• Requires Buy-in• Shared Budgeting for
Platform and Utility Services
• Ownership over Platform and Utility Services
• Not Investing in Business Services limits ROI and Interoperability
• Agility Limited Since there is no Portfolio of Business Services
• Anything Not Standardized has Downfalls of Project-Driven Approach
Recommendations Downfalls
Characteristics of Infrastructure-Driven SOA
Reuse
Increased Visibility
Reducing Impact of Change
Ease and Speed of Development
Interoperability
ScoreSOA Benefit
SOA Governance for Infrastructure-Driven
OperationsProjects / Service Lifecycle
Service Ownership
Service Lifecycle Gov
Shared Artifacts
Capacity Planning
Enforce Service Levels
Enforce Policies
<Insert Picture Here>
Syntax-Brillian• Currently adopting a Project-Driven
approach to SOA• Improved Customer Relationship
Management• Increased Fulfillment Capability• EA managed by the CIO• Issues:
• Disparate Systems• Change Management
• Lesson Learned• Executive buy in critical for
project success• Test, Test, .. And Test some
more! It is never enough!• Key Takeaway
• Factor in additional time when dealing with hosted environments
<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
<Insert Picture Here>
Secure Path• Currently adopting a Enterprise-
Driven approach to SOA• Extremely quick turnaround time to
onboard new customers• Platform agility supports rapidly
growing business needs• Very active EA led by their CTO• Issues:
• Scalability & Performance issues with their previous .Net platform
• Lessons Learned:• Critical to devote time upfront to
finalize data contracts• Enterprise-wide SOA Roadmap
established• Reusing a number of services /
processes• Key Takeaway:
• Focus on Business Processes and not the Technology
<Insert Picture Here>
Project-Driven to Enterprise-Driven
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
• Process Automation / BPM• Monitoring and
Optimization• Application Consolidation
Projects
• 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 Services
• Data Services• Portfolio Planning
• Leverage Architecture & Design Standards
• Enact as Much Governanceas Required
• 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
Recommendations Downfalls
Characteristics of Enterprise-Driven SOA
Reuse
Increased Visibility
Reducing Impact of Change
Ease and Speed of Development
Interoperability
ScoreSOA Benefit
Business Service Portfolio Plan
Conceptual ServicesPortfolio
Customer
Service
Customer
Service
Concrete ServicesPortfolio
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Now
Marketing
Service
Marketing
Service
Marketing
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
12 Months
Finance
Marketing
Service
Warehouse
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Marketing
Service
18 Months
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
SOA Governance for Enterprise-Driven
Financial
PortfolioPeople
OperationsProjectExecution
Technology Architecture
Service Usage Fees
Service Funding Model
Projects Portfolios
ERP, Legacy App Portfolios
End to End Platform Funding Services Portfolios
Roles & Responsibilities
Service Ownership
EA Group
Service & Process Owners
Service Lifecycle Gov
Shared Artifacts
Capacity Planning
Enforce Service Levels
Enforce Policies
Strategic SOA Platform
Shared Foundation Srvcs
Enforce Platform Decisions
Reference Architectures
Architectural Standards
Blueprints & Patterns
DRIVEN BY EXECUTIVES
Information
Data Standards
Data Quality
Data Ownership
For a White Paper go to http://www.oracle.com/technologies/soa/docs/oracle-soa-governance-best-practices.pdf
<Insert Picture Here>Put your companyLogo here please
• Large Canadian Telco• Infrastructure-to-Enterprise • SOA means faster time to
production, better re-use• Moderately active EA oversight• Challenges overcome
• Technology: Setting proper granularity for strategic services wrapped around legacy services
• Organizational: Instilling a culture of service reuse
• Lessons learned• Technical: Demand higher quality,
better governed infrastructure services• Organizational: Wrapping legacy
services and incorporating them in a strategic vision demonstrates the benefits of reuse
• Future enterprise-centric service plans: Continue top-down analysis; use vendor-provided Web services as legacy silos
• Advice: Top-down, strategic analysis is vital for even the most tactical of projects
<Insert Picture Here>Put your companyLogo here please
• Fortune 500 Shipping Co.• Major Enterprise SOA Initiative (phased
roll-out over 3 years, concurrent with legacy maintenance)
• $250K pilot project was valuable learning experience plus high ROI
• Enterprise Architecture team has been central to pilot and main SOA projects
• Challenges overcome:• Technology: Assessing maturity of
Service Activity Management technologies
• Organizational: Enforcing Internal Design Standards
• Lessons learned• Technical: Must design services in
advance to support inevitable larger, more complex service compositions
• Organizational: Making everyone understand the strategic goals is key to getting their support
• Future enterprise-centric service plans: Establish a strong business entity service layer for broad reuse and business alignment
• Advice: Success with SOA impossible without successfully enforcing internal design standards on a consistent basis
<Insert Picture Here>Put your companyLogo here please
<Insert Picture Here>
Infrastructure-Driven to Enterprise-Driven
<Insert Picture Here>
Level 1: 1999-2003• SEMCI application selected
refactored to orchestration of srvcs• SOAP, WSDL, UDDI standards• WSM, UDDI SOA tools selected,
leveraged existing message bus• PCAC (P&C Architects Collective)
formed (no org changes)• Application Reference Arch v1.0
completed & Projects Checked • “Do No Harm” governance policy• Project scoring under definition with
feedback• No Explicit Metrics to Measure
Progress on SOA Road • No Reuse
Level 2: 2003-2005• Project-based services selected
(driven by project budget)• BPEL, WSIF, WS-Security standards• BPEL and XML security/acceleration
appliance selected• Integration Reference Arch v1.0, App
Reference Arch. v2.0 created• Formal EA group under newly
formed CTO (EAs centralized)• Architect job family defined (30
people’s title changed from architect)• SOA “Cookbooks” defined for
existing SOA tools (development)• Score Projects to Influence Business
Decisions – but Scoring Project-level
Level 3: 2005 Onwards• Business & IT create 5 year business and
IT roadmap; Business blueprints defined for all LOB
• Funding model changed from project-based to enterprise-based
• Rules, Portal, BPM engines selected• SOA “Cookbooks” for all SOA tools (maint.)• Business architecture defining Business
Services Portfolio• SOA Governance tools selected, esp.
Business Services Catalog• SOA Service Committee, Standards
Committee• Key business metrics and KPIs identified
and communicated monthly
<Insert Picture Here>
Conclusions
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!
Oracle Fusion Middleware
SOA Adoption Strategy
Enterprise-Driven
Infrastructure-DrivenProject-Driven
Management BehindEnterprise SOA
Management Skeptical –Need Convincing
IT 100% Full Steam Ahead
IT Focused on SuccessStories to Convince
Management not BoughtIn 100%
IT Able to Drive ReuseAcross Departments