SOA monitoring and performance management challenges

659 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
659
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • MIT Sloan Center for Information Systems Research (CISR) studies The 4 stages of enterprise architecture Silos – IT efforts focused on specific departmental needs Standardized IT – standard platform technologies where possible (desktop, HW, OS, DB) Standardized business processes - business is viewed holistically, and IT and business leaders see themselves as partners. Business modularity - business processes and their supporting technologies become modules that can be reused for efficiency and recombined for agility—the quintessential promise of SOA. Moving from the second stage to the third can produce subtle benefits. At TD Banknorth, the business units needed more sophisticated products to compete. That required IT to keep improving its abilities and levels of sophistication. At the same time, cost pressures require the CIO to deliver these more sophisticated tools with the same level of resources. This pressure leads to an optimization approach, bringing the enterprise into the third architecture stage. It is at this third stage that architecture begins to mean more than IT infrastructure. Data architecture, IT governance, Six Sigma process optimization and business-IT alignment become critical aspects of the enterprise architecture, with the focus of IT shifting from simply managing the technology plumbing efficiently to contributing to the business's operational excellence. Efficiency remains important, but its goal has changed from saving money for the sake of reducing costs to freeing up resources that can be used to grow the business, says Petrey. "Companies can be agile only if they can turn specific functions on and off," Wachs asserts, and that requires understanding what the functions are, where they are used and what they affect. That in turn requires having an architecture designed for both flexibility and consistency, he says.
  • Loosely Coupled Increases organizational agility; allows companies to easily assemble, and modify business processes in response to market requirements Provides a competitive advantage by offering greater flexibility in the way computer systems can be used to support the business Lowers implementation costs by increasing reusability; services can easily be shared across multiple applications Increases IT adaptability; changes — resulting from mergers, acquisitions, package application implementations, etc . — are easily integrated Modular Approach Enables incremental development, deployment, and maintenance; avoids the need to do costly and risky " big bang " software implementations Decreases development effort by reducing complexity ( through a " divide and conquer " approach ) Over time, accelerates deployment of new application functionality; process becomes mostly assembly of existing services versus mostly new development Non - intrusive Allows existing investment in IT assets to be leveraged Lowers risk and development effort; avoids the need to rewrite and test existing applications Standards - based Platform independence allows companies to use the software and hardware of their choice Allows companies to engage in a multi - source strategy, reducing threat of vendor lock - in Delivers economies of scale; same technology can be applied to address a broad range of business problems Reduces complexity and fragmentation resulting from use of proprietary technologies Lowers training requirements; increases available labor pool
  • Visibility and control at the cross tier business transaction layer are what we need to effectively mange IT service delivery, aligned with business needs. The need for this visibility and control is increasing due to the trends highlighted on the right of this screen. They combine to further increase the COMPLEXITY and DYNAMIC nature of our IT environment.
  • By design (or as developers like to see SOA) every interaction is a straight forward set of request-response by service requestors and producers, however in production environments where multiple applications share a single services architecture of composed internal and external services and registries things can get a bit more “spaghetti” like and not as simple…
  • Messages are usually stateless and the state / status is in the message (XML) Routing is done based on internal sates or statuses Multiple service registries co-exist New services plug-in to an exiting environment
  • Transactions of different characteristics and business importance go into the IT cloud and come back out once completed. The “cloud” obscures the path the transaction takes and it is indifferent to the transaction’s context. Overall response times may meet SLAs or fail to meet SLAs, or deviate sharply from averages without any correlation to the business impact of the transaction. In this diagram a high priority online transaction (for example a high $ worth purchase or trade or part order) fails to meet SLA, while a low priority long running transaction (such as a BI report, or an exchange of transactions with an external system, or simply a back-office transaction) does better than SLA. Our next slide exposes the reasons why the infrastructure can’t do any better.
  • Transactions of different characteristics and business importance go into the IT cloud and come back out once completed. The “cloud” obscures the path the transaction takes and it is indifferent to the transaction’s context. Overall response times may meet SLAs or fail to meet SLAs, or deviate sharply from averages without any correlation to the business impact of the transaction. In this diagram a high priority online transaction (for example a high $ worth purchase or trade or part order) fails to meet SLA, while a low priority long running transaction (such as a BI report, or an exchange of transactions with an external system, or simply a back-office transaction) does better than SLA. Our next slide exposes the reasons why the infrastructure can’t do any better.
  • Transactions of different characteristics and business importance go into the IT cloud and come back out once completed. The “cloud” obscures the path the transaction takes and it is indifferent to the transaction’s context. Overall response times may meet SLAs or fail to meet SLAs, or deviate sharply from averages without any correlation to the business impact of the transaction. In this diagram a high priority online transaction (for example a high $ worth purchase or trade or part order) fails to meet SLA, while a low priority long running transaction (such as a BI report, or an exchange of transactions with an external system, or simply a back-office transaction) does better than SLA. Our next slide exposes the reasons why the infrastructure can’t do any better.
  • Transactions of different characteristics and business importance go into the IT cloud and come back out once completed. The “cloud” obscures the path the transaction takes and it is indifferent to the transaction’s context. Overall response times may meet SLAs or fail to meet SLAs, or deviate sharply from averages without any correlation to the business impact of the transaction. In this diagram a high priority online transaction (for example a high $ worth purchase or trade or part order) fails to meet SLA, while a low priority long running transaction (such as a BI report, or an exchange of transactions with an external system, or simply a back-office transaction) does better than SLA. Our next slide exposes the reasons why the infrastructure can’t do any better.
  • Transactions of different characteristics and business importance go into the IT cloud and come back out once completed. The “cloud” obscures the path the transaction takes and it is indifferent to the transaction’s context. Overall response times may meet SLAs or fail to meet SLAs, or deviate sharply from averages without any correlation to the business impact of the transaction. In this diagram a high priority online transaction (for example a high $ worth purchase or trade or part order) fails to meet SLA, while a low priority long running transaction (such as a BI report, or an exchange of transactions with an external system, or simply a back-office transaction) does better than SLA. Our next slide exposes the reasons why the infrastructure can’t do any better.
  • Transactions of different characteristics and business importance go into the IT cloud and come back out once completed. The “cloud” obscures the path the transaction takes and it is indifferent to the transaction’s context. Overall response times may meet SLAs or fail to meet SLAs, or deviate sharply from averages without any correlation to the business impact of the transaction. In this diagram a high priority online transaction (for example a high $ worth purchase or trade or part order) fails to meet SLA, while a low priority long running transaction (such as a BI report, or an exchange of transactions with an external system, or simply a back-office transaction) does better than SLA. Our next slide exposes the reasons why the infrastructure can’t do any better.
  • SOA monitoring and performance management challenges

    1. 1. SOA monitoring and performance management challenges Ron Gidron Director, Product Marketing [email_address]
    2. 2. SOA is about culture, not technology <ul><li>Technology provides the raw materials – it’s up to you to use them effectively </li></ul><ul><li>Slapping a WS interface on a bad process will not help </li></ul><ul><li>Current practices discourage SOA </li></ul><ul><ul><li>Project-oriented approach </li></ul></ul><ul><ul><li>Vendor lock-in / “standardization” </li></ul></ul><ul><ul><li>Time to market </li></ul></ul><ul><li>SOA is like physical fitness </li></ul><ul><ul><li>It requires a lifestyle change </li></ul></ul><ul><ul><li>Governance is essential </li></ul></ul>SILOS STD IT STD BP’s BIZ MODULARITY
    3. 3. Agenda <ul><li>Setting the stage </li></ul><ul><li>SOA monitoring challenges </li></ul><ul><li>Business Transaction Management™ </li></ul><ul><li>Q&A </li></ul>
    4. 4. SOA Basics <ul><li>Service Oriented Architecture </li></ul><ul><li>Not only web services (e.g. REST, POX …) </li></ul><ul><li>Vendors sell a “complete SOA platform” </li></ul><ul><ul><li>No such platform exists </li></ul></ul><ul><ul><li>SOA is heterogeneous by design </li></ul></ul><ul><li>Most people would agree on: </li></ul><ul><ul><li>Flexible service components at the core </li></ul></ul><ul><ul><li>Messages between components to get things done </li></ul></ul><ul><ul><li>Compose services to build applications </li></ul></ul><ul><ul><li>Service contracts between providers and consumers </li></ul></ul>
    5. 5. High level architecture Shared, reusable services Account management Order processing Profile management Managed communications infrastructure Applications using shared services Retail customer service Partner customer service Web Self-service Call center
    6. 6. Benefits of SOA Loosely coupled Modular Non- intrusive Standards- based <ul><li>Agility </li></ul><ul><li>Flexibility </li></ul><ul><li>-Reusability </li></ul><ul><li>Adaptability </li></ul>Incremental development, deployment and maintenance Reduced complexity Accelerated functionality deployment Leverage IT assets Lower risk & development efforts Freedom of choice in HW & SW Multi-source strategy – avoid lock-in Address broad range of business needs with the same technology
    7. 7. Agenda <ul><li>Setting the stage </li></ul><ul><li>SOA monitoring challenges </li></ul><ul><li>Business Transaction Management™ </li></ul><ul><li>Q&A </li></ul>
    8. 8. The gap in the IT management stack No visibility / no control SOA, ESB, integration Increasing, varied demand Consolidation, virtualization IT infrastructure End-user business transactions Cross-tier business transactions Applications Introduction Problem Solution Technology Summary
    9. 9. The ideal – efficient interaction Presentation layer App Service Backend system
    10. 10. Reality – death by a thousand cuts <ul><li>Why is this happening? </li></ul><ul><ul><li>Design flows? </li></ul></ul><ul><ul><li>New use cases? </li></ul></ul><ul><ul><li>New transaction types? </li></ul></ul>Presentation layer App Service Backend system
    11. 11. SOA monitoring challenges Presentation layer App. Service App. Service App. Service Backend System Backend System Backend System Backend System Backend System Backend System WS WS WS WS WS WS WS WS WS WS WS WS WS
    12. 12. SOA monitoring challenges <ul><li>How will you know where your transactions go? </li></ul><ul><ul><li>They don’t always route the same way… </li></ul></ul><ul><li>What is the impact of a given service or backend going offline? </li></ul><ul><li>Who is impacted by outages and what are the business consequences? </li></ul><ul><li>How do you plan for capacity changes in a dynamic environment? </li></ul><ul><li>How do you resolve performance problems? </li></ul>
    13. 13. SOA monitoring/performance mgt challenges <ul><li>Performance metrics are hidden by design </li></ul><ul><li>Challenges </li></ul><ul><ul><li>SLA compliance NOT guaranteed </li></ul></ul><ul><ul><li>Limited visibility beyond SOA borders </li></ul></ul><ul><ul><li>Limited performance management </li></ul></ul><ul><li>Banking example: </li></ul><ul><ul><li>Two customer transactions </li></ul></ul><ul><ul><ul><li>Portfolio analysis </li></ul></ul></ul><ul><ul><ul><li>Execute trade </li></ul></ul></ul><ul><ul><li>Both get account details – implemented as a service or transaction component </li></ul></ul><ul><ul><li>No transactional context means both get the same resource allocation at execution time </li></ul></ul>
    14. 14. Agenda <ul><li>Setting the stage </li></ul><ul><li>SOA monitoring challenges </li></ul><ul><li>Business Transaction Management™ </li></ul><ul><li>Q&A </li></ul>
    15. 15. Business Transaction Management™ <ul><li>Links your business metrics with your IT metrics </li></ul><ul><ul><li>Starting from every transaction instance </li></ul></ul><ul><li>Respond to problems quickly and efficiently </li></ul><ul><ul><li>Understand execution paths in real time </li></ul></ul><ul><ul><li>View transaction behavior across SOA and beyond </li></ul></ul><ul><li>Identify trends before business users are affected </li></ul><ul><li>Reduce your TCO </li></ul><ul><ul><li>Assure business priorities are met </li></ul></ul><ul><ul><li>Meet service level requirements </li></ul></ul><ul><ul><li>Reduce over-provisioning </li></ul></ul><ul><ul><li>Avoid the blame game </li></ul></ul><ul><li>Make IT relevant – speak the business language </li></ul>
    16. 16. Tracking transactions Customer account inquiry Get policy details Analytics WU – Work Unit App server2 DB server Web server App server1 App server3 App server4 SOA Management Legacy server Back-office daily analytics query Infrastructure service indicators
    17. 17. Tracking transactions Customer account inquiry Get policy details Analytics App server2 DB server Web server App server1 App server3 Legacy server App server4 SOA Management WU – Work Unit Back-office daily analytics query Infrastructure service indicators
    18. 18. Tracking transactions Customer account inquiry Get policy details Analytics App server2 DB server Web server App server1 App server3 App server4 SOA Management Legacy server SOA management with CoreFirst Back-office daily analytics query Infrastructure service indicators Auto-discover and track transactions Install collectors
    19. 19. Tracking transactions Customer account inquiry Get policy details Analytics App server2 DB server Web server App server1 App server3 App server4 SOA management with CoreFirst Legacy server Back-office daily analytics query Infrastructure Service Indicators Auto-discover and track transactions Install collectors
    20. 20. Tracking transactions Customer account inquiry Get policy details Analytics App server2 DB server Web server App server1 App server3 App server4 SOA management with CoreFirst Legacy server Back-office daily analytics query Infrastructure Service Indicators Auto-discover and track transactions Install collectors
    21. 21. Tracking transactions Customer account inquiry Get policy details Analytics App server2 DB server Web server App server1 App server3 App server4 SOA Management with CoreFirst Legacy server Back-office daily analytics query Infrastructure Service Indicators Install Collectors Auto-Discover & Track transactions
    22. 22. CoreFirst™ - solution architecture Web server .Net App server J2EE EJB App server DB server Proactive, cross-tier, Business Transaction Management (patent-pending) Management server and web GUI DTE – Dynamic Tier Extension Observed Tier DTE DTE DTE DTE User request Transaction profiles collected
    23. 23. Benefits See your real transactions
    24. 24. Benefits … and their detailed cross-tier breakdown
    25. 25. Benefits … down to specific transaction instances and their cross-tier breakdown
    26. 26. Benefits - View transaction flow - Rapidly pinpoint issues - Identify anomalies - Associate issues with impact
    27. 27. Business transaction tracking is necessary for effective SOA environments <ul><li>Address need for flexibility and change </li></ul><ul><li>Respond to real-time fluctuations in usage regardless of crunch on resources </li></ul><ul><li>Help identify new trends in usage and focus IT staff </li></ul><ul><li>View business transactions across tiers </li></ul><ul><li>Provide the most comprehensive performance management </li></ul><ul><ul><li>End-to-end visibility across all tiers </li></ul></ul><ul><ul><li>- and beyond SOA borders </li></ul></ul>
    28. 28. OpTier™ provides software solutions that dynamically link business services to underlying IT infrastructure, assuring service delivery and optimizing IT resources. Its unique Business Transaction Management™ technology – which delivers end-to-end visibility and control of all business transactions – makes effective Business Service Management a reality.

    ×