avoiding the soa hangover rational approaches to soa adoption for large enterprises thomas j....
TRANSCRIPT
Avoiding the SOA HangoverRational Approaches to SOA Adoption for Large
Enterprises
Thomas J. Cozzolino - LiquidHub, Inc.
Judith Hurwitz, Marcia Kaufman - Hurwitz and Associates
2
Today’s Agenda
I. What do we mean by SOA and Why do we Care?
II. What is the “SOA Hangover”?
III. Case Examples
IV. Best Practices to the Rescue:
- Managing SOA: Governance - Surviving SOA: Operational SOA- Paying for SOA: Funding Strategies
V. Conclusions, Q&A
What is SOA?
3
SOA: A Definition
A software architecture for building applications that implement business processes or services using a set of
loosely-coupled black-box components orchestrated to deliver a
well-defined level of service.
What is SOA?
4
Really, it’s a Pragmatic Approach to Enterprise Architecture
Loosely-coupled black-box components: Historical point-to-point and other integration strategies are expensive, error-prone, and difficult to manage and scale. Loose coupling drives many benefits, including reuse, predictability, and uniformity.
Well-defined level of service: True SOA-based approaches drive both business and IT to clearly consider, define, and measure Service Levels, greatly increasing the effectiveness of development and providing clear, transparent success criteria.
Business Processes: Critical to success of the Business-IT partnership is the ability to focus on a common set of linkage points. Processes in SOA, long the domain of the Business, finally become the focus area of IT through the construct of Business Process Management (BPM).
SOA for Dummies, 2006
What is SOA?
5
Why Consider a Service Oriented Architecture?
Define business rationale, not technical features
Find a pragmatic balance between technical rigor and time-to-market
Value ongoing flexibility and agility over a one-time efficiency gain
With planning, immediate return for each service built via the “Network Effect”
Increasing return as the architecture – and that of your customers, suppliers, and partners – evolves to SOA
SOA is about reuse of existing assets: Legacy, Client Server, and Web
Can “wrap” existing applications, re-using existing functionality of legacy systems to increase their reach and longevity
Build new services on multiple supported platforms
Invest in a diversified portfolio of applications, not a packaged application or a technology platform
Applications are less fragile, more adaptive to rapidly changing business requirements
Facilitate standards based integration with trusted business partners (B2B)
Ease integration needs raised by M&A activity
Complexity is encapsulated
Code is mobile
Enhancements and changes can be added incrementally with a minimum ripple effect across the application infrastructure
Increase Increase ROIROI
Focus on Focus on the the
BusinessBusiness
Achieve Achieve ReuseReuse
Ensure Ensure FlexibilityFlexibility
Future-Future-Proof Your Proof Your EnterpriseEnterprise
What is SOA?
6
Historically all Linkages Between Components Required Custom Integration
What is SOA?
7
The Service Oriented Architecture
Source: SOA for Dummies/Hurwitz Associates
What is SOA?
8
Business Processes & Services
Business Process Orchestration
BusinessServices
TechnicalServices
Get customer
details
“Open Account for Customer”
Locateaccount
type
Add account tocustomer
Locatecustomer
record
Checkcustomer
status
Presentation – user interface
Create Customer-Accountrecord
Lookupaccount
typetable
Retrieveaccountdetails
Business Process
Coarse Grained
FineGrained
Service Orchestration(Process
Orchestration)
Adapted from ANZ Banking Group Australia
What is SOA?
9
The Goal: Linking Business and IT together
Reduce costs and complexity
Ensure stability and flexibility
Adopt a rational portfolio of applications, not a single packaged application or a technology platform
Leveraging valuable software assets and best practices by turning them into reusable business services
Create software services that conform to business rules and processes
Create an environment where IT approach mirrors the business
What is SOA?
10
It’s About Thinking Differently
Think differently about:- Software- Process- Linking rather than integrating - Managing based on process
It’s putting the pieces in context with:- Security- Data - Quality- Manageability
What is SOA?
11
What is the SOA Hangover?
Lot of companies are committed to SOA
Initial commitment and energy is high
Many companies have done pilots to test the tools and approaches
Barriers to entry are low
But the opportunities to make mistakes are high
many Pilots have gone nowhere
costs (at least initially) have gone up
tools for measuring ROI are poor / non-existent
Leads to:
“SOA? Maybe next year”
“Been there, done that – thanks but no thanks”..
The SOA Hangover
12
Inhibitors to SOA Success
Meshing the SOA strategy with both corporate and IT Governance practices
Funding SOA beyond the pilot - who should pay?
Confusion regarding who should be in charge of SOA within the overall company and within IT
Keeping IT and business leadership in synch
Training existing IT personnel for the challenges of new technologies
Determination of what to reuse and what to throw away
Vetting the right internal and industry partners to learn from (and with)
Uncertainty on how to scale the Pilot
Gauging how much of SOA should be centrally controlled and how much independence should be given to business units
Operational Support of SOA-based assets along side your traditional portfolio
The SOA Hangover
13
Major Oil Supplier: Business Process
Business and IT Challenges
- Multiple systems used for electronic invoicing- High human error- Poor visibility into overall invoicing performance- Needed to mange 15,000 invoices in 48 states to meet “Net 30” business terms
Strategy
- Deploy BPM as key enabler- Integrate BPM as part of larger SOA solution
Key Benefit Areas and Realized ROI
- Reduced FTEs from 40 5- Increased Customer service through timely payment and higher visibility
CaseExamples
14
Retailer: Roadmap
The Company- Large sports/fashion manufacturer and retailer - Mix of high-end and mid-range designer labels- A series of major acquisitions has contributed to substantial revenue growth
- The company’s products are distributed globally via wholesale and retail outlets
The Challenge- How to monitor and measure performance at an enterprise-wide after explosive growth?
- How to streamline overlapping and redundant applications and computing infrastructure resulting from multiple acquisitions
The Approach- Start with a Roadmap – connectivity becomes the entry point- Begin with creation of a common point-of-sale process for all stores- Streamline the process of maintaining high quality data from retail stores and integrate this data efficiently and accurately at the enterprise level
CaseExamples
15
Retailer - What are the Business Drivers and Goals?
Implement a Service Oriented Architecture to enable the monitoring and measuring of performance of all retail stores at an enterprise wide level
Create a cost effective plan to leverage data and applications without duplication
Rationalize point of sale applications to back office data and information access
Streamline the information management process
Trust the product inventory and sales data from retail stores
Integrate data efficiently and accurately at the enterprise level
Determine if revenue goals are being met
CaseExamples
16
Retailer’s SOA Dimensional Roadmap
Achievable
Goal
Entry Point
Milestones
People
Processes
Procurement
Understand the business need: Trusting point-of-sale data was a top management priority
This company’s transition to SOA began with implementation of ESB. Goal: decouple various software applications from point-to-point integrations
Understand the timing required for vendor selection, project rollout, simulation business processes
Training and mentoring of developers to allow for re-thinking of traditional concepts about software development –help business and IT to share a common language
Model core business processes, create a service catalogue, and define SOA testing methods
Begin with ESB development tools and adapters. Plan for process modelling and monitoring tools, and master data management
ProjectsSelect initial projects that could be implemented quickly with visible results for the business
CaseExamples
17
Retailer - How has SOA Benefited the Business?
Consistent and common point-of-sale system allowed the business to begin to fully leverage the various assets brought together under one organization after some major acquisitions
Employees have become more productive and business units have become more profitable now that they are able to share common data about sales, inventory, and customers
The business is now able to trust the data
IT can identify and correct errors in sales data before it is viewed by management
Clearly defined business services have helped to change the pace of business-shortening the time to add a new partner and providing quicker responsiveness to market changes
Business leaders and technology leaders share common goals and speak a common language
CaseExamples
18
Major Energy Company
Business and IT Challenges- Major upgrades of ERP, Logistics, Self-Service Web Sites- Understanding of SOA benefits, but low experience- Many options regarding Enterprise Service Bus- What to do first?
Strategy- Cross-Project Leads coordinate through centralized Enterprise Architecture Group
- Consider Commercial, Open Source, and Hybrid Solutions- Plan for Scale and Metrics on Day One- Emphasis on Governance, Communications Planning and Technical Leadership
Key Benefit Areas- “Eyes Wide Open” as ESB comes online- Infrastructure just ahead of Services- Rigorous cost model and ROI reduced Software Costs
CaseExamples
19
Strong Governance Process
Creation of a Governance Committee helped to secure collaboration between IT teams and the business. The group reviews candidates for business services to determine the most appropriate level of granularity and to evaluate the following:
- Potential for reuse- Implications for other established infrastructure and other applications- Ensure that business services are matched with business objectives- Ensure that business services meet regulatory requirements
SOA project teams regularly present key accomplishments to the Governance body
- Presentations are backed up with accurate metrics - The teams know how business services are being used- The teams know who is monitoring changes to business services- The teams know how IT is organized to support codified business services- Consider a federated governance model to provide flexibility, speed, and
alignment with the enterprise
BestPractices:
Managing SOA
20
Governance “Forcing Function” - IT/Business Alignment
Aligned Shared
Common
As Is To Be
Unaligned Enterprise Architecture policies, standards, directives, etc.
Common and Shared Services
Business Focus andAlignment
Unaligned
UnalignedService-based policies,
standards, directives, etc.
Via a Federated Matrixed IT DepartmentUnaligned Departments
Transition
Aligned Departments
• IT Plan Non Existent or Not Aligned with Business Plan
• IT Reactive to Business Initiatives
•No SOA Strategy•No SOA Roadmap •Silos of SOA
• IT Plans Aligned with Business Plans and Initiatives
• SOA Strategy that is Communicated Widely
• Well-Defined Business Benefits Sought from SOA Strategy
• SOA Roadmap Aligned to Deliver on Business and SOA Strategy
Rea
ctiv
e Pro
activ
e
BestPractices:
Managing SOA
21
Governance How To’s: Increasing Alignment
Process- Establish a Governance process in the early stages of SOA- Be prepared to identify and plan for business service ownership- Understand who will sign off on a service- Begin to establish a strategy for long-term Governance
Operations- Early on in the process, ensure that tooling is place to support
the registration, lookup, and versioning of business services - How are different versions of the same service managed?- Is the service certified in terms of logic and quality?- Include Governance of QA and Production change control and
management
BestPractices:
Managing SOA
22
Benefit of Service Registry/Repository
Best Practice: Deploy supporting technology for Service Registry / Repository regardless of the number of Services deployed:
Enforces Lifecycle discipline: development teams immediately plan for basic Registry-based operations within their Lifecycle, with no need to retrofit “after SOA has matured”
Provides a Management View: early stages of SOA deployment will be highly visible to both Business and IT management. A Registry that can be tapped for usage data is a critical tool in showing early return on investment as well as Service reuse.
Enables a baseline for characteristic workloads: early metrics regarding usage (and the associated linkages to traditional capacity planning and measurement tools) are critical to avoid unplanned resource shortages.
BestPractices:
Managing SOA
23
Tool-based Repository and Registration Example
Developer
Service Consumer
System Admin
Business Owner
Enterprise Architect
Project PM
Publish Service
Update Service
Deprecate Service
Delete Service
Discover Service Retrieve Service
Publish Polcies Approves Services
Performs Validation
Perform Cataloging
Perform Versioning
Store Artifacts
Notifications
Service Repository
BestPractices:
Managing SOA
24
Planning for Operational SOA: Service Management Evolves
Organizations must have visibility into the components of a SOA environment in order to plan to manage them from an SLA perspective
There is no substitute for a clear, consistent and aligned set of SLAs that Business and IT can understand and strive to meet
IT must anticipate that a service can degrade and be prepared to manage a set of well-defined services across applications, servers, storage, and networks
Only a well-architected service management platform can scale
Need to have a way to measure and monitor through well-designed tools
Requires a focus on dramatic changes in process management and cultural changes
BestPractices:
Surviving SOA
25
Centralized Funding: Carefully-Paced Adoption of SOA
Leverage strong SOA Governance Committees and strong centralized development teams for CIO/CEO identification and funding of key business services
Centralized SOA Governance Committee collects business requirements, sets priority and sequence of Service Development, and provides funding through a corporate budget
First Services to be developed should be most widely used or have the most impact across business units.
Governance body could choose to fund a small number of incubator Services to gain expertise in Service granularity or to gauge the impact of SOA
Centralized approach helps to show SOA progress and accountability to the Executive team
Governance body helps to educate business on the benefits of the SOA strategy
BestPractices:
Funding SOA
26
Business Funding: Entrepreneur, Joint Partnering
Business units with strong IT skills develop business services and “Sell” back to enterprise
- As long as business has the IT skills, this approach promotes rapid evolution of SOA
- High risk of service duplication and of inappropriate level of granularity for services
- Hard to provide centralized SOA Governance
Business units and IT jointly fund business service development
- This approach may take more time, but will lead higher levels of trust, coordination, and ownership of results between business and IT
- Shared responsibility and more effective utilization of resources- Based on internal charge back mechanisms, the cost of business
service development is shared between IT and the business
BestPractices:
Managing SOA
27
SOA is About Good Business and Technical Practice
SOA is about understanding your business and creating the right granularity of business services
SOA is about creating a reusable set of services that mirror the business
SOA is about being able to link the right pieces together at the right time to create competitive differentiation
SOA is a journey that allows a flexible approach to incrementally adding both business and infrastructure components as the foundation for the future
SOA is about a life cycle of business services supported by a scalable, secure, and manageable infrastructure
SOA demands a focus on security within a highly virtualized environment
Manageability of both business services and infrastructure must be planned for as a foundation for SOA expansion
Conclusions
28
How to Avoid the SOA Hangover
Key Dos- Take a top down view – need to understand your value to your customers
- Set up a cross-organizational Task Force followed by a Center of Excellence (COE)
- Think about business services- Loosely couple components- Think about security- Stress the importance of Governance
Key Don’ts- Start by coding Web Services- Start by trying to boil the ocean- Take a siloed approach to SOA- Think (initially) about coding to solve a specific problem
- Leave security until the end of the project
- Believe that Governance can happen “when we have time”
Conclusions
