taming the soa beast
play

Taming the SOA Beast SOA introduces complexity as well as new - PowerPoint PPT Presentation

Taming the SOA Beast SOA introduces complexity as well as new organizational impacts. We need to re-think the process. December 2008 Why SOA? Business Effectiveness Agility, responsiveness to market/competitive dynamics Business


  1. Taming the SOA Beast SOA introduces complexity as well as new organizational impacts. We need to re-think the process. December 2008

  2. Why SOA? Business Effectiveness   Agility, responsiveness to market/competitive dynamics  Business agility  Greater process efficiencies  Deploy resources based on  Speed business needs Cost Efficiency   Lower integration  Reduced maintenance costs costs  Reduce integration costs  Reduced skills and effort to  Alignment between support business change  Reduce application redundancy business and IT Reduced Risk   Higher level of IT quality  Incremental deployment  Improved payback times

  3. Stakeholders View of SOA • SOA impact is strategic, long-term and enterprise Board of focused Directors • Project must impact overall operations and strategy of the organization • SOA advantages must be realized in measurable Managers ways • Looking to promote structures for project to be facilitated, monitored, and measured • Need to understand expectations of the vision Developers • Must have the tools and buy-in to achieve vision Operations Staff • Major impact is “change management”

  4. SOA What’s Different… ESB Intermediaries Service Service Consumer Provider Interface Interface Registry  Designed to be useful and usable  Modular by other applications  Client-less server modules  Useful and usable by other  External access to modules enterprises  Loose coupling (black box)  Centrally-managed repository and  Interoperable registry  Walls between partners blur  Intermediary rich environment

  5. SOA Impact to Projects Currently The Challenge • New Relationships • Business Analyst People – Business and technology • Trust – Providers and consumers • Partners • Constant Change • Change based testing Process • Business Service Lifecycle • A new lifecycle – Independent dev. cycles • Continuous quality process – Producers and Consumers • Interoperability • Consistency Technolog • Logic abstracted • Tests need to follow • Complex • Isolation and emulation y

  6. Setting Expectations The Major Points 1. SOA is transformational 2. SOA has deep business process roots 3. Alignment of business and technology not easy 4. Organizational “domain” impact

  7. Approaches From a quality perspective SOA initiatives and/or web services place different quality demands on an organization Application Centric Shared Business Services • “Traditional” application delivery, exposes WS • SOA/WS strategy spans traditional silos API. • Increased complexity due to distributed nature of • Internal versus external initiative • Typical WS/SOA value drivers not at the • Deliverable has x-silo impact forefront of the ROI proposition • Business process focus Legacy New • Dev responsible for service needs to test message and components • Selected components • Project complexity exposed as WS • Complexity of environment is high • Project duration • Might/not use QA • More inclined to be responsible for test • Hypothesis now • Short duration project follows traditional • QA more tightly tied to Dev quality cycle • More sharing of test assets Dev Shar QA Dev QA Dev QA 60% ed 15 60% 40% 40% 60% 25% %

  8. (Or) Approaches Companies that signal with a carved out architecture group or a top-down approach Bottom-Up Top-Down • Application delivery. • Strong signal is the investigation of SOA “governance” • Requirement to expose WS Interface • Separate SOA group is carved out • Internal focus • This group has a high ratio of architects to • Some “Just Checking it out.” Others at Phase 1 developers • This group has planned for “complexity” • Architect is very concerned about consistency and policy enforcement • High potential for the “team” to be divorced from siloed application, strong need to understand if app component is robust • Realization of complexity and the need for a functional framework

  9. SOA Challenges 1. Process Cadence 2. Significant risk 3. Challenge of reuse 4. Properly Addressing Security 5. Organizational impact 6. SOA Sprawl / Unconscious Migration

  10. Process Cadence  Organizations evolve the development process without QA  Agility is lost due to lack of education  Complexity not well understood  Three aspects to consider:  New Service  Versioning  Process changes

  11. Managing Risk Consolidation of application or services for mission critical processes increases the risk of failure. More users are impacted Impact of Impact of Downtime Downtime (Risk) (Risk) Reuse of Services Distributed Applications

  12. Promoting Reuse Creating an asset that is reusable is easy, promoting reuse is  a much different challenge Aside from granularity, reuse is all about trust  There is no such thing as a “used car”  Manufacturer Point Special Certified Warranty Details Inspection Financing Chrysler 125 Yes 8 years / 80,000 mile Powertrain Limited Warranty, measured from original vehicle in-service date. Ford 115 Yes 6 years / 75,000 miles from the In-Service date 110+ Yes 3 months / 3,000 miles from the Purchase date GMC Lexus 161 Yes 3 years from the Purchase date / 100,000 miles from the In-Service date 130+ Yes 12 months from Purchase date / 100,000 miles from the In-Service date Mercedes-Benz 160 Yes 7 years / 100,000 miles Limited Power Train Warranty from date when Toyota first sold as new.

  13. Properly Addressing Security There is a gap in how WS security is addressed  “Security is not my problem it’s coming from  somewhere else” There hasn’t been a big scandal, that we’ve heard  about! Security is usually bolted-on  Audits are usually performed too late  Architect Develop Test Monitor Need to be able to detect GAP Assumptions Audits vulnerabilities as early as possible.

  14. SOA Impacts IT Roles Trend 2 Trend 1 “Quality” and the quality process is Project durations are shorter with higher being promoted higher in the levels of integration. organization Level of Integration Governance Process SOA Internet Client Design Dev Test Deploy Mainframe Server Project Duration Trend 3 Trend 4 Silos are being broken down into smaller The onus of quality is being distributed cross-functional teams. Those teams in the process. QAs role is split. have more distributed team members. Analyst Arch Dev QA QA Perform

  15. SOA Sprawl (Unconscious Migration) With success comes demand for more services  Every new consumer or provider adds exponential potential  for complexity  Identity credentials  Standards  Message format  Transport protocol New versions of a provider or consumer adds complexity  Complexity Risk Eliminated Automated Governance and Quality Control Services

  16. SOA Changes the Game With SOA there is too much at risk we cannot have a “Save it for Later” quality process Futile to stage a “real” SOA environment  Systems and services might not be controlled by a single entity  Environment is complex  Application layer is a “software unit” that performs a service  Service must interact with other systems and services  Assumptions about how components will operate are critical  for quality Our process is only as good as its weakest link  We need a different process

  17. Step By Step Approach Achieving secure, reliable, compliant services requires visibility, trust and control 1. Provide visibility 2. Supply an infrastructure for reuse 3. Promote bottom-up quality 4. Leverage the infrastructure for top-down quality 5. Assist to manage complexity 6. Concentrate on quality process improvement

  18. Visibility Promoting Trust must begin early in the process   When an asset is created the quality process begins Consider internal and external, consumers and providers 

  19. Infrastructure for Reuse

  20. Bottom-Up Quality

  21. Top-Down Quality

  22. Manage Complexity  Stub out the service consumer (client) to test the service provider (server)  Stub out the service provider (server) to test the service consumer (client)  Stub out both tiers to test a proxy or an intermediary

  23. Improve the Process of Quality

  24. Questions  Q&A

Recommend


More recommend