Ronald Schmelzer Keynote Address


Published on

Keynote Address given by Ronald Schmelzer, Senior Analyst and Founder of ZapThink, at Transformation and Innovation 2007.

Published in: Business
  • Be the first to comment

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

No notes for slide
  • This module follows Module 1: SOA: The Business Case. It is meant to provide an introduction into the key fundamental concepts of Service-Oriented Architecture including Services, Service Orientation, the Abstraction layer, Granularity and other concepts as well as a discussion of limitations and emerging best practices. It lays the groundwork on which later modules expand upon supporting concepts. Instructors’ Guide Notes: Description of course: “ Understanding SOA Basics” serves as an introduction to key SOA concepts that are built upon in following modules of the “Following the ZapThink SOA Roadmap” curriculum. Services, Service Orientation, abstraction, granularity, challenges and best practices are introduced. Minimum Prerequisites: Module 1: Introduction to SOA. Intended Audience: As a fundamental level module, this content can be delivered to audiences of various levels, including business audiences, mixed technical audiences, combination business/technical audiences, and architect audiences of various specialties and levels. Expected Duration for Course : 1.5 to 2 hours. Module Flow: This module is comprised of a logical presentation of concepts that cumulatively accomplish the module goal of being able to explain SOA benefits & challenges and describe SOA in the context of more familiar concepts like traditional distributed computing and EDA. There is a real-world exercise where students will be able to test and cement their understanding of the concepts by stepping into the shoes of an Enterprise Architect presenting SOA to a business stakeholder. REQUIRED EQUIPMENT: Flipcharts and markers for teams to do the exercise. Each module has an overall introduction listing what the learners will accomplish in the module. Each concept includes an introduction, a discussion of the concept and a summary. Finally, there is an overall review of what was accomplished in the module. This module follows the “test and tell” methodology: first generate interest while learning the audience’s pre-existing familiarity with the material by checking understanding of concepts introduced in this module up front. The instructor can use the outcome of the initial evaluation to set the pace for the module. The total time to complete the main concepts in this module should be approximately 2 hours. Each concept will take no more than 20 minutes: approximately 10 minutes of introduction and discussion followed by approximately 10 minutes of Q&A and review. The exercise will take 30-60 minutes depending on the size of the class. Note: All slide timing numbers are rough approximations to be used as guidelines. The actual time spent per slide will depend on the level of interaction with the students. Questions will obviously increase the time spent on a slide. Key Concepts: This is the initial slide in the presentation. Introduce yourself and logistics Questions to address : Will this presentation be available for download?
  • Ronald Schmelzer Keynote Address

    1. 1. Finding the Lowest Risk Path to SOA Adoption Ron Schmelzer Senior Analyst ZapThink, LLC
    2. 2. The Problems of IT are The Problems of Business
    3. 3. Business Constant: Change CHANGE Competition Changing Marketplace Customer Demands Mergers & Acquisitions Optimizing Processes New Technologies Business Partners A Business is Never STATIC
    4. 4. We’ve had IT challenges for years …
    5. 5. … but even after yesterday’s promises…
    6. 6. … we still have the same IT mess, only worse.
    7. 7. The Business Inflexibility Trap <ul><li>Inflexibility is the Mother of All Business Problems </li></ul><ul><ul><li>If you’re flexible enough, you can solve all the other problems </li></ul></ul><ul><li>Information Technology (IT) is an impediment to business change </li></ul><ul><ul><li>It wasn’t supposed to be that way! </li></ul></ul>
    8. 8. <ul><li>Companies require Business Agility… </li></ul><ul><ul><ul><ul><ul><li>Responding quickly to change, and </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Leveraging change for competitive advantage </li></ul></ul></ul></ul></ul>Business Agility J Agility is the key to innovation
    9. 9. If you are in a Hole, Stop Digging! <ul><li>IT Decision Making’s Fatal Flaw: </li></ul><ul><ul><li>Choice between “take some extra time & money and do it right” vs. “give me what I want the cheapest & fastest way” – guess which wins? </li></ul></ul><ul><li>Repeat enough times, leads to the IT “Rat’s Nest” </li></ul>
    10. 10. The Integration “Rat’s Nest” FBT PAY G NTS TRDS Client Customs RRE IPS Integrated A/C Refunds RBA Def Payments Excise CR PKI ECI ADD AWA ELS Client Staff Remote Staff TAX AGENTS GCI Call Centers WOC CCD TASS Staff Phone Compliance Staff BOA Ref material Bus. Intel NTS A/c BEP CDCC CWMS BANK DDDR 1 Data……. Penalty Business IVR 1
    11. 11. Service Orientation: A Business Approach <ul><li>It’s not about connecting things, it’s about enabling business processes & continual change </li></ul><ul><li>The core business motivation is business agility </li></ul><ul><li>Rather than “rip and replace” old systems – make them work better together </li></ul><ul><li>It’s not about technology, integration, or middleware </li></ul>
    12. 12. SOA shifts the way we think Architecture makes it work Middleware makes it work Leverage Heterogeneous Technology Favor Homogeneous Technology Compose Services Integrate Silos Loosely Coupled, Agile and Adaptive Tightly Coupled Designed to change Designed to last Interactive and iterative development Long development cycle Metadata Oriented Code Oriented Service Oriented Approach Traditional Distributed Approach
    13. 13. Measuring ROI for SOA Source: Wipro <ul><li>Reduced licensing & configuration costs </li></ul><ul><li>Cost for Maintenance & Changes </li></ul><ul><li>Operations Cost </li></ul><ul><li>Cost of future integrations </li></ul><ul><li>Phased replacement of legacy middleware </li></ul>Integration Cost Asset Reuse Business Agility Business Risk <ul><li>Cost for development of new business process flows and composite applications </li></ul><ul><li>Overall staffing </li></ul><ul><li>Greater ability to outsource </li></ul><ul><li>Portfolio cleanup </li></ul><ul><li>Improved time to market & responsive customer service </li></ul><ul><li>Ability for business users to directly control business process definition & management </li></ul><ul><li>Ability to easily integrate with new business partners and suppliers </li></ul><ul><li>Provide value to the partners and suppliers which could result in new business opportunities </li></ul><ul><li>Ability to capture the new revenue streams </li></ul><ul><li>Improved Business & IT alignment that helps in intelligent planning </li></ul><ul><li>Cost of enforcing & ensuring regulatory compliance </li></ul><ul><li>Reduction of liability </li></ul>
    14. 14. Many Perspectives on SOA <ul><li>All views relevant & important </li></ul><ul><li>Service-Oriented Architects must have all perspectives </li></ul>Data Services Technology Business Processes
    15. 15. Web Services are the Trees…. Service Orientation is the Forest
    16. 16. The Economics of Integration Pkg. Implementations
    17. 17. There’s No Such Thing as a SOA Wizard! <ul><li>Click…click…click…done! You now have a SOA! </li></ul><ul><li>Will never happen because… </li></ul><ul><ul><li>SOA best practices are too general </li></ul></ul><ul><ul><li>Each organization has a different environment, both technical and cultural </li></ul></ul>The architect’s answer is usually “ it depends”
    18. 18. SOA Challenges Source: Wipro
    19. 19. Challenge: Inertia in the Organization <ul><li>Architecture doesn’t have features and business executives pay for features! </li></ul><ul><li>Moving to SOA means breaking down silos and sharing resources </li></ul><ul><li>The technology change is easy – it’s the human change that’s the hard part! </li></ul>
    20. 20. Challenge: Balancing Control & Empowerment <ul><li>Answer: Governance </li></ul><ul><li>Establishing, communicating, and enforcing policies, providing visibility into the levels of compliance, and dealing with issues </li></ul><ul><li>Not just governance of SOA…governance with SOA </li></ul><ul><li>But…avoid “big brother” effect </li></ul>Who likes to be governed?
    21. 21. Challenge: Reuse = Sharing We all learned to share in kindergarten… But by the time we get to the working world, we forget how!
    22. 22. How Do You Eat an Elephant? <ul><li>One bite at a time! </li></ul><ul><li>Don’t expect to have all the answers on day one </li></ul><ul><li>Take a step-by-step approach, but… </li></ul><ul><ul><li>Top-down only: have the plan, may not be able to execute </li></ul></ul><ul><ul><li>Bottom-up only: build Services, may not be reusable </li></ul></ul><ul><li>SOA planning must be both </li></ul><ul><ul><li>Develop the vision (but not the details) ahead of time </li></ul></ul><ul><ul><li>Service development should be iterative </li></ul></ul><ul><li>Show business value at each step </li></ul>
    23. 23. The ZapThink SOA Roadmap
    24. 24. ZapThink’s SOA Implementation Roadmap Heterogeneous Systems with Proprietary Interfaces Manage Services Implement the SOA Metamodel Service-Oriented Process Semantic Integration Dynamic Service Discovery Secure Service Interfaces Wrap Legacy Systems in Services Interfaces Service-Oriented Enterprise Enterprise SOA Buildout Mission-Critical SOA SOA Pilots “ Grass Roots” Web Services Implementations Create a Governance Framework Contract-First Development Cross-Departmental SOA
    25. 25. SOA Pilots <ul><li>A few high ROI Services </li></ul><ul><li>Build acceptance for SOA </li></ul><ul><li>Get team up to speed </li></ul><ul><li>Work out the kinks </li></ul><ul><li>Pilot the governance model </li></ul><ul><li>Part of an iterative approach to SOA </li></ul><ul><li>Piloting only the Services instead of the architecture </li></ul><ul><li>Remember, the pilot is one step on the roadmap </li></ul>DANGER! Avoid the SOA Pilot Pitfall
    26. 26. Building SOA the Right Way <ul><li>SOA is all about continuous and sometimes unpredictable change </li></ul><ul><li>Development issues </li></ul><ul><ul><li>How to handle versioning? </li></ul></ul><ul><ul><li>How to handle metadata management? </li></ul></ul><ul><ul><li>How to develop changing policies? </li></ul></ul><ul><li>Runtime issues </li></ul><ul><ul><li>Service availability </li></ul></ul><ul><ul><li>Policy enforcement </li></ul></ul><ul><ul><li>Guarantee service-level agreement </li></ul></ul><ul><ul><li>Maintain low TCO </li></ul></ul>
    27. 27. Role of the Architect <ul><li>Where is the architect? </li></ul><ul><ul><li>Growth of the Enterprise Architecture Team </li></ul></ul><ul><li>Should have dotted-line responsibility to the CIO </li></ul><ul><ul><li>Avoid the Ivory Tower! </li></ul></ul><ul><li>Become the Master of Best Practices </li></ul><ul><ul><li>Know the methodologies and approaches </li></ul></ul><ul><ul><li>Best practices, not software, is where the innovation and opportunities remain! </li></ul></ul>
    28. 28. Ownership of Services <ul><li>Shared Services cross organizational boundaries </li></ul><ul><li>Siloed IT management styles are becoming obsolete </li></ul><ul><li>The new role for enterprise architects </li></ul>
    29. 29. How do you Budget? <ul><li>Who pays for Service development? </li></ul><ul><li>Who pays for Service changes? </li></ul><ul><li>Should architects have their own budget? </li></ul>Revenge of the chargebacks!
    30. 30. Planning for Change <ul><li>Why middle management is resisting </li></ul><ul><li>How enterprise architecture helps </li></ul><ul><li>Incremental SOA is the way to go! </li></ul>
    31. 31. Change & Version Mgmt: Multiple Levels <ul><li>Loosely-coupled systems: </li></ul><ul><ul><li>Lots of simultaneous change </li></ul></ul><ul><li>Service Implementation Change </li></ul><ul><ul><li>Changing how you build and run the Service </li></ul></ul><ul><li>Service Contract Change </li></ul><ul><ul><li>Changing how to define and communicate Service capabilities </li></ul></ul><ul><li>Service Policy Change </li></ul><ul><ul><li>Changing the rules by which you create, access, and compose Services </li></ul></ul><ul><li>Data Schema Change </li></ul><ul><ul><li>Changing the language of data </li></ul></ul><ul><li>Service Infrastructure Change </li></ul><ul><ul><li>Embracing ongoing heterogeneity </li></ul></ul><ul><li>Business Process Change </li></ul><ul><ul><li>The Business keeps changing, so your architecture needs to keep working! </li></ul></ul>State of the Art!
    32. 32. How to Think Service-Oriented <ul><li>Think of IT as an asset and the business as processes composed of Services </li></ul><ul><li>Think of SOA as an approach for dealing with frequent, and often unpredictable change… in both business and IT. </li></ul><ul><li>Think of integration as a byproduct of Service composition </li></ul>
    33. 33. Thank You!