The Road to SOA


Published on

  • Be the first to comment

  • Be the first to like this

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

No notes for slide
  • Add 2 bullets
  • SOA is a solution to a number of problem scenarios in IT. The most common of these scenarios is when there is a variety of Existing IT systems (animation) which are not integrated, and yet they have to be used as if they were a single one through a Presentation layer (animation). In this common case, Services (animation) are created to integrate these heterogeneous systems and offer a coherent view of them to any other part of the organization. These services then become the way to access any IT resource from any other part. However, while SOAs are often used for integration, its differentiative feature (e.g. against EAIs) is reuse – i.e. the availability of any capability implemented in any IT system to any other part of it, no matter where is it implemented, with which technology, tool or platform. The main differentiating point of a SOA is that as much business functionality as possible is available as a service , thus making it reusable instead of locking it. This reuse feature is what gives sense to the concept of Composite Applications , (animation) which provide useful functionalities to the user by reusing existing functionalities available in the services of the SOA. Any service in a SOA can be accessed no matter where or how is it implemented, as long as it is useful for its consumer; only its description matters for that. However there is a number of typical ways to create services, like Legacy service enablement (animation) Which makes it possible for existing IT systems to be accessed as services (and the other way), thus making them reusable by any other needing them. But most often the functionalities available in existing IT system are not useful for other elements in an isolated way, because they are heterogeneous and unintegrated. For this, Service Orchestration (animation) Allows to easily combine the functionality of any existing service e.g. to integrate or coherentize them. Also, Information Integration (animation) Performs similar functionalities, only that using means specifically aimed to integration of disparate sources. But it must be reminded that any piece of logic which is natively able to act as service of the SOA (animation) is valid in a SOA, as long as it complies with the base technology to interoperate with the SOA (e.g. WS-*). So, for example, a SOA is useful even for brand new systems, i.e. when there are no existing systems to integrate. A very useful way to implement business functionality is BPM, which allows to define how people and IT systems should coordinate to perform business processes. Thus, the business process execution (animation) benefits much from SOA because it has no longer to worry about integrating existing systems, but the services make available to the processes any functionality existing in the organization. Also, BPM provides part of the business functionality it implements as reusable services. Please not that in this architecture, “execution of BPM” refers only to the engines, and the user interface lies in the Presentation, since a end user application often accesses both BPM and services. These blocks depict the functional part of the SOA, i.e. what delivers the useful functionality. However it cannot work without some Runtime infrastructure (animation) delivering facilities like Communications (animation) Operational storage (animation) Security and other policy enforcement (animation) And other Runtime governance features (animation) This completes what is often considered as the typical Service-Oriented Architecture. But indeed it composes only its Delivery part (animation), i.e. the one which operates all the time to deliver the business functionalities. But of course this performing needs of Operational Management tools (animation) Which allow to ensure that it continues delivering such functionalities with the expected service levels. Among others, it contains tools to Control the delivery, monitor its activity, configure Alerts upon it, enact Runtime covernance functions on it, Obtain Reports upon it, and configure it . Still this is commonly seen in Service-Oriented Architectures. But of course, no functionality will be delivered by the runtime without activities and tools for Modeling, Designing and developing services and other SOA runtime elements (animation), like creation of Orchestrations, Business processes, composite applications or SOA-Enabling service. And still one missing piece – these three environments all refer to the same SOA, and to the same elements inside it that deliver functionalities. But, where reside this common knowledge, without which it is not possible to coordinate the three environments? In the Registry & Repository (animation), A metainformation store about any relevant aspect of the SOA, its elements, its relationships, etc. Among others, it allows to manage the Life cycle , makes it possible its Governance, assess the impact of any change, and in general to store any metadata and assets relevant for the SOA. This is the overall view of the Reference SOA, but there also exists detailed views and mappings into crossvision.
  • The Road to SOA

    1. 1. The Road to SOA
    2. 2. What’s the target ? Services Services Services Services Services Services Policy Policy Policy Policy Policy Policy Business Process Business Process Application Application <ul><li>Technical Services </li></ul><ul><li>Integration Points </li></ul><ul><li>webMethods Flow Services </li></ul><ul><li>Business Services </li></ul><ul><li>Business Services orchestrated from Technical Services </li></ul><ul><li>webMethods IS Web Services </li></ul>Service Consumers - Business processes and/or applications Systems of Record - Mainframe, DBMS, etc <ul><li>Mediation </li></ul><ul><li>Provides Security and Transformation </li></ul><ul><li>X-Broker, Datapower, etc </li></ul>Services Services Services Services
    3. 3. The SOA Reference Architecture SOA Delivery Application composition Native services Communications Operational storage Security and policy enforcement Runtime governance Operational Management Modeling, Design, Development Services Presentation Existing IT systems Registry & Repository Service Orchestration Information Integration Legacy service enablement Business process execution
    4. 4. Pragmatic Next Steps for SOA SOA Maturity Initial Actions Operational Governance <ul><li>- SOA Success Factors </li></ul><ul><li>Services Funding Model </li></ul><ul><li>ROI Analysis </li></ul><ul><li>SOA Accelerator </li></ul><ul><li>Infravio Quick Start </li></ul>Optimized Composition <ul><li>Technical Architecture </li></ul><ul><li>Services Bus </li></ul><ul><li>Mediation </li></ul><ul><li>Monitoring </li></ul><ul><li>Services Design </li></ul><ul><li>Granularity </li></ul><ul><li>Contracts </li></ul><ul><li>Service Lifecycle </li></ul><ul><li>Design Time </li></ul><ul><li>Change Time </li></ul><ul><li>Run Time </li></ul><ul><li>Organizational Changes </li></ul><ul><li>- SOA CC </li></ul>Design for Change <ul><li>Continual Process Improvement </li></ul><ul><li>Composition </li></ul><ul><li>Versioning </li></ul><ul><li>Testing </li></ul><ul><li>Operations </li></ul>30 Days 60 Days 90 Days 120 Days SOA Adoption
    5. 5. Gap Analysis <ul><li>An industry “Best Practice” is to augment your existing governance structure with a support group or competency center for successfully deploying any new technology. </li></ul><ul><ul><li>Integration Competency Centers (ICC) have evolved for addressing integration technologies </li></ul></ul><ul><ul><li>Shared Service Organizations in addition to an ICC have evolved for addressing the adoption of SOA. </li></ul></ul><ul><ul><li>Many companies extend their existing ICC to address SOA. </li></ul></ul>
    6. 6. Introducing The SOA CC Senior VP (Business Steering Committee) << LOB Leader >> (Line of Business) CIO (IT Steering Committee) IT Integrators Project Director (Project A) PMO Enterprise Architecture SOA CC
    7. 7. Evolution of the SOA CC Benefits Knowledge Leverage Consistency Resource Optimization Control Best Practices Technology Standards Shared Services Central Services Centralized Hybrid Distributed Distributed Organization Shared Standardized Standardized Recommended Technology Defined Defined Defined Defined Process SOA CC Evolution
    8. 8. SOA CC Interaction New Project Enterprise Architecture Vision and Integration Architecture* Selection of Technology* Platform Architecture Database Administration Data Modeling Expertise Modeling Tools Enterprise Data Knowledge* Internal Marketing Communicating the SOA Vision* Demonstrating the SOA Value (Success Stories)* Suggesting Projects* Operations and System Administration Middleware Installation and Configuration Server and Network Configuration System Management* QA Process* Test Scripts Testing Tools SOA CC Administration Maintain SOA Documentation* Best Practices* Metadata Management* Business Analysts Business Modeling* Business Domain Knowledge* Development Project Management Application Knowledge Development Skills Security Corporate Security Knowledge* Product and Application Vendors Application Data Model* Integration Middleware* Pilot Project Support Adapters* Source: Gartner - May, 2007
    9. 9. Design for Change Transition <ul><li>Change during a project is expensive; so define everything up front so nothing needs to change </li></ul><ul><ul><li>Large deliverables </li></ul></ul><ul><ul><li>Longer Cycles </li></ul></ul><ul><ul><li>Large Analysis </li></ul></ul>Agile <ul><li>Change during a project is expensive and unavoidable; so do everything possible to minimize the cost of change </li></ul><ul><ul><li>Smaller deliverables </li></ul></ul><ul><ul><li>Shorter Cycles </li></ul></ul><ul><ul><li>Smaller Analysis </li></ul></ul>Waterfall <ul><ul><li>Review </li></ul></ul>Improve <ul><li>Continual process improvement </li></ul><ul><li>Strategies </li></ul><ul><ul><li>Composition </li></ul></ul><ul><ul><li>Versioning </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Operations </li></ul></ul>
    10. 10. Development and Support Disciplines Inception Elaboration Construction Transition Production Retirement New Service Services Identification Contract First Service Specification Major Version (non-backwards Compatible) Or Minor Version (backwards Compatible) Evolve Existing Service Finalize Schema Enforce Standards Communicate and promote Service Deploy Service Deprecate Service Phases
    11. 11. Enterprise Disciplines <ul><li>Before projects start; perform planning around services </li></ul><ul><ul><li>Service Versioning Strategies </li></ul></ul><ul><ul><ul><li>Configuration Management Process </li></ul></ul></ul><ul><ul><ul><li>Major/Minor versioning schemes </li></ul></ul></ul><ul><ul><ul><li>Deprecation Policies </li></ul></ul></ul><ul><ul><li>Service Testing Strategies </li></ul></ul><ul><ul><ul><li>Complete Testing </li></ul></ul></ul><ul><ul><ul><li>Collaborative Testing </li></ul></ul></ul><ul><ul><ul><li>Continuous Testing </li></ul></ul></ul><ul><ul><li>Service Capacity/Sizing </li></ul></ul><ul><ul><ul><li># of Versions </li></ul></ul></ul><ul><ul><ul><li># of Consumers </li></ul></ul></ul><ul><ul><ul><li>Transaction Volumes </li></ul></ul></ul><ul><li>Write the policies </li></ul><ul><ul><li>Determine if they can be enforced with technology </li></ul></ul>
    12. 12. Organizational Functions Disciplines for application development , packaged application customization and implementation. Connecting applications together including traditional EAI and B2B disciplines , with re-usable interfaces and inter-application standards. Overall IT governance capability for the overall lifecycle project Management , systems development , testing , release, change management , system support . Business focus on improving their results / goals by determining tactile change to business operations (leveraging IT capability) . Overall alignment of business goals, multi-year plans, and opportunities. Enterprise Architecture Cross-functional team responsible for ensuring optimal alignment of IT capability with business goals - minimizing implementation, runtime, evolution costs , complexity, downtime, and technology risk. Application Delivery Enterprise Integration IT Organizational Governance Business Development Business Strategy
    13. 13. Waterfall Methodologies and SOA <ul><li>The Premise: Change during a project is expensive, so define everything up front so nothing needs to change </li></ul><ul><li>SOA Impact Considerations: </li></ul><ul><li>Architects at the front of the Waterfall Process need to have tight integration with service registries . </li></ul><ul><li>Specifications need to be updated as service versions evolve in outside efforts </li></ul><ul><li>Use and modification of services across projects must be handled via outside governance </li></ul><ul><li>Developed services are enterprise assets – testing and release of service sub-components may need to move towards “iterative” models </li></ul><ul><li>Testing during the development cycle needs to adopt automation and continuous regression concepts </li></ul><ul><li>Functional Domain Models hugely important </li></ul><ul><li>Process-centric business development moves out of purview of “application development” to BPM – which can be a difficult transition </li></ul>
    14. 14. Agile / Iterative Methodologies and SOA <ul><li>The Premise: Change during a project is expensive – And Unavoidable – so do everything possible to minimize the cost of change </li></ul><ul><li>SOA Impact Considerations: </li></ul><ul><li>“ Just in Time” building can limit future re-use opportunities for services without careful consideration </li></ul><ul><li>“ This project only” philosophy can make it challenging for effective outside governance enforcement </li></ul><ul><li>There is typically no re-use metric within these methodologies </li></ul><ul><li>Integrated testing model fits amazingly well with SOA </li></ul><ul><li>Closer involvement of business sponsors can facilitate line between business logic hard-coded within services and process logic / business rules held in more flexible, abstracted technology </li></ul>
    15. 15. Role Changes within Application Delivery <ul><li>Application Architects: </li></ul><ul><ul><li>The role specialization between application and enterprise architects grows </li></ul></ul><ul><ul><li>Enhanced knowledge of the company’s “inventory” of service assets required </li></ul></ul><ul><ul><li>Run-time information and service level exchanges required for web services in building applications </li></ul></ul><ul><li>“ Service” Developers: </li></ul><ul><ul><li>Building towards a detailed policy for service definitions </li></ul></ul><ul><ul><li>Services begin to give up “process logic” to outside orchestration </li></ul></ul><ul><ul><li>Good understanding of object and functional models </li></ul></ul><ul><li>Testers: </li></ul><ul><ul><li>End-to-end, automated regression testing important </li></ul></ul><ul><ul><li>Version testing important </li></ul></ul><ul><ul><li>Must begin to gain greater system design understanding </li></ul></ul>Application Delivery Enterprise Integration IT Organizational Governance Business Development Business Strategy Enterprise Architecture
    16. 16. “ SOA-ing” the Integration Competency Center “ Service-enable” existing End-Points Evolve Point Integration to Enterprise Service Bus Composite Service Creation Metadata / Policy Management Web Services Management Integrated / Automated Composite Testing Application Delivery Enterprise Integration IT Organizational Governance Business Development Business Strategy Enterprise Architecture
    17. 17. Organizational Governance LOB Project Prioritization along Pre-Agreed Axis Higher level IT Processes are implemented at the services layer: Asset, Change and Configuration Management Project Governance of SOA Usage / Adoption Governance of Process Usage / Adoption Governance of Development and Application Architecture The “Registry” Owner lives here Think about how other technology assets are managed and you are on the way… Governance, more than any other area, will drive the success or failure of a scalable SOA strategy… Application Delivery Enterprise Integration IT Organizational Governance Business Development Business Strategy Enterprise Architecture
    18. 18. Rise of the “SOA Enabled” Business Analyst Greatest Impact in terms of Efficiency The true key between IT Integration 2.0 and Business-Agile SOA The “SOA Analyst”: Expanded Roles = New Training and Concepts!! BPM / BAM Embedded in the SOA Business-level Semantics True Process Improvement Discipline – Huge Value and potentially huge cultural threat Application Delivery Enterprise Integration IT Organizational Governance Business Development Business Strategy Enterprise Architecture
    19. 19. Enterprise Architecture Front and Center SOA Mandates the end of the “Ivory Tower” Increased control = increased accountability and measurements Multi-Year view combined with incremental ROI measurement Technology-first infatuation is a detriment In some organizations these teams are evolving to delivery centers for Enterprise Assets Application Delivery Enterprise Integration IT Organizational Governance Business Development Business Strategy Enterprise Architecture
    20. 20. Communication with the Business End of the “silos” Requires maturity in the face of true IT execution capability Process-centric focus drives more complex IT-LOB relationships Application Delivery Enterprise Integration IT Organizational Governance Business Development Business Strategy Enterprise Architecture
    21. 21. Funding / Budget for Shared Services – What’s the Answer? <ul><li>Allocation Models often deployed in the industry: </li></ul><ul><li>He who comes to the river builds the first bridge </li></ul><ul><li>Enterprise Funding – Business Level belief </li></ul><ul><li>IT Funding – Infrastructure team responsible for mitigating complexity and cost </li></ul><ul><li>Cost Shielding – Net zero, hiding ABC Costing </li></ul><ul><li>Chargeback Unit Mechanisms often deployed: </li></ul><ul><li>Shared “service” units – virtual units created based on underlying transaction rate consumption of assets </li></ul><ul><li>Tiered “service” units – virtual units based on underlying consumption, level of service, and/or consumer </li></ul><ul><li>Enterprise Pool – Higher level distribution of cost of enterprise assets not based on direct usage (based on revenue, LOB employee count, etc) </li></ul>
    22. 22. Get Started with an SOA Implementation <ul><li>Keys to a successful </li></ul><ul><li>Quick Start: </li></ul><ul><li>Start small </li></ul><ul><li>Non-production vs. production </li></ul><ul><li>Evolve SOA </li></ul><ul><li>Integrate with strategic direction </li></ul><ul><li>Disciplined approach </li></ul>SOA Quick Start Define Your Criteria Implement Your SOA System Conduct Training & Knowledge Transfer Design Your Implementation
    23. 23. Quick-start: use industry standard <ul><li>Use specification from an industry standard (e.g. eTOM for telecommunications) </li></ul><ul><li>Top-down business process definition approach is possible </li></ul><ul><li>Focus on DesignTime and ChangeTime </li></ul><ul><li>As services are identified and deployed, evolve into RunTime mediation and governance </li></ul>
    24. 24. Managing Outcomes <ul><li>Step One: Establish top level goals and outcomes </li></ul><ul><ul><li>Measurable goals </li></ul></ul><ul><ul><li>Metrics Reporting and Auditing </li></ul></ul><ul><li>Step Two: Establish policies and contracts </li></ul><ul><ul><li>Accountability, adjudication, responsibilities </li></ul></ul><ul><ul><li>Interoperability Standards </li></ul></ul><ul><ul><li>Service Lifecycle Processes </li></ul></ul><ul><ul><li>Security Policies </li></ul></ul><ul><li>Step Three: Build the Foundation </li></ul><ul><ul><li>Assign ownerships, budgets and responsibilities </li></ul></ul><ul><ul><li>Develop Organizational Tools (CoE, chargebacks, shared services org) </li></ul></ul><ul><ul><li>Establish federated systems of record for policies, contracts and services </li></ul></ul><ul><ul><li>Automate governance processes </li></ul></ul>
    25. 25. Resources –
    26. 26. <ul><li>Where are you? </li></ul><ul><li>Business context </li></ul><ul><li>Arch and Tech </li></ul><ul><li>Governance & Process </li></ul><ul><li>People </li></ul><ul><li>What is your destination / itinerary? </li></ul><ul><li>Vision </li></ul><ul><li>Evolution </li></ul><ul><li>Alignment </li></ul>