Avoiding the SOA Hangover SOA For Dummies

1. Avoiding the SOA HangoverSOA For Dummies Judith Hurwitz and Marcia Kaufman Hurwitz & Associates Thomas J. Cozzolino, LiquidHub, Inc.

2. Today’s Agenda • What do we mean by SOA? • What is the “SOA Hangover”? • Case Study: A Roadmap to Success with SOA • Avoiding the SOA Hangover through Best Practices: • Managing SOA: Governance • Surviving SOA: Operational SOA • Paying for SOA: Funding Strategies • Conclusions, Q&A

3. What is SOA? 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

4. 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). What is SOA?: A More Pragmatic Approach to Enterprise Architecture SOA for Dummies, 2006

5. Key Dos Do take a top down view – need to understand your value to your customers Do set up a cross organizational task force followed by a center of excellence Do think about business services Loosely couple components Do think about security Key Don’ts Don’t start by coding web services Don’t start by trying to boil the ocean Don’t think stove pipes Don’t take a siloed approach to SOA Don’t think about coding to solve a specific problem Don’t leave security until the end of the project How to Avoid the SOA Hangover

6. The SOA 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

7. Why Consider a Service Oriented Architecture? Focus on the Business • 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 ROI Achieve Reuse Future-Proof Your Enterprise Ensure Flexibility

8. Historically all Linkages Between Components Required Custom Integration

9. The Service Oriented Architecture Source: SOA for Dummies/Hurwitz Associates

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

11. Business Processes & Services Business Process “Open Account for Customer” Presentation – user interface Business Process Orchestration Locate account type Add account to customer Get customer details Business Services Coarse Grained Service Orchestration (Process Orchestration) Locate customer record Check customer status Lookup account type table Retrieve account details Create Customer- Account record Technical Services Fine Grained Adapted from ANZ Banking Group Australia

12. Business Process Case Study: Major Oil Supplier • 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

13. What is the SOA Hangover? • Lot of companies are committed to SOA • Many companies have done pilots to test the validity of this approach • While there are many success stories, there are lots of companies trying to find their way

14. Inhibitors to SOA Success • How do you mesh the SOA strategy with both corporate and IT governance practices? • How do you fund SOA beyond the pilot? Who should pay? • Who should be in charge of SOA within the overall company and within IT? • How do you keep IT and business leadership in synch? • How do you train existing IT personnel for the challenges of new technologies? • How do you determine what to reuse and what to throw away? • How can you learn from others in the industry and others within your own company? • Once you have done a pilot, how do you scale? • How much of SOA should be centrally controlled and how much independence should be given to business units? • How can you support SOA applications along side your traditional portfolio?

15. How One Company Developed a Roadmap to Avoid the SOA Hangover • The Company • Large sports/fashion manufacturer and retailer • Mix of high-end designer labels along with mid-range • 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

16. Case Example: 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

17. Case Example: A Roadmap For Success with SOA Understand the business need: Trusting point-of-sale data was a top management priority Achievable Goal This company’s transition to SOA began with implementation of ESB. Goal: decouple various software applications from point-to-point integrations Entry Point Understand the timing required for vendor selection, project rollout, simulation business processes Milestones Projects Select initial projects that could be implemented quickly with visible results for the business 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 People Model core business processes, create a service catalogue, and define SOA testing methods Processes Begin with ESB development tools and adapters. Plan for process modelling and monitoring tools, and master data management Procurement

18. Case Example: Eliminate SOA Hangover with A Strong Governance Process • Creation of a Governance Committee helped to secure collaboration between IT teams and the business. The group reviewed 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 • Company deployed a federated governance models to provide flexibility, speed, and alignment with the enterprise

19. A Case Example: How has SOA Benefitted 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

20. The Benefits of Managing IT with a Focus on IT/Business Alignment As Is Transition To Be Unaligned Departments Via a Federated Matrixed IT Department Aligned Departments Enterprise Architecture policies, standards, directives, etc Unaligned Aligned Shared Unaligned Common Unaligned Service-based policies, standards, directives, etc Reactive Proactive • 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 Common and Shared Services Business Focus and Alignment

21. Managing SOA: Governance Drives Business/IT Alignment • Establish a governance process in the early stages of SOA • Early on in the process, ensure that tooling is place to support the registration, lookup, and versioning of business services • Be prepared to identify and plan for business service ownership • Understand who will sign off on a service • Are there different versions of the same service? • Is the service certified in terms of logic and quality? • Include governance of QA and Production change control and management • Establish a strategy for long term governance

22. Managing SOA: 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

23. Managing SOA: Tool-based Repository and Registration Example

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.

25. Centralized SOA Funding Leads to 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

26. Business Funding or Business/IT Joint Funding of SOA • 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 chargeback mechanisms, the cost of business service development is shared between IT and the business

27. ROI Case Study: $4BN Manufacturing Company • Business and IT Challenges • Inconsistent business-to-business systems (11 distinct solutions) • Inconsistent practices (AR, Customer integration, Problem Management) • Labor-intensive workflows (error-prone AR and Invoice Processing) • Strategy • Compatibility with existing strategic systems • Leverage Role-based security • Ensure Scalability • Integrate with overall SOA Approach • Key Benefit Areas • Reduced Staffing • Operational Efficiencies (Exceptions) • Eliminated Software Costs • Realized ROI • Annual ROI: 81% • Payback Period: 1.1 yrs. • Net Present Value: $144K • Annual yearly cost of ownership: $183K

28. 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

29. Q&AContact Info: Judith Hurwitz Judith.Hurwitz@Hurwitz.comMarcia KaufmanMarcia.Kaufman@Hurwitz.comThomas J. CozzolinoTCozzolino@LiquidHub.com