Increasing the probability of success with SOA

WHITE PAPER Increasing the Probability of Success with SOA - A Review of the Cordys@Work Implementation Methodology Sponsored by: Cordys Rob Hailstone Erik Bruin September 2006 IDC OPINION This White Paper discusses Services Oriented Architecture (SOA) software vendor Cordys' implementation methodology. Cordys decided to develop such a methodology, named Cordys@Work, with the objective better to serve its customers and support its ecosystem of SI partners. www.idc.com y Early experiences regarding SOA implementations have shown that SOA implementations are complex. Good software is only appreciated by customers if it has been implemented well. Therefore, IDC encourages Cordys' initiative to develop a good implementation methodology that takes the specifics of its own Tel.+44.20.8987.7100 software into account. y Cordys has adopted a modular, hands-on approach and offers guidelines, blueprints and best practices specific to Cordys software from which customers and partners can use whichever modules they need. IDC thinks the choice of a modular approach was a sound decision, as especially SI partners usually have their own existing SOA methodologies and are just looking for partners-specific IDC EMEA, 389 Chiswick High Road, London, W4 4AE, U.K. content to complement their own generic methodologies. Consequently, the Cordys@Work approach should stimulate the development of a good partner ecosystem. y At the time of writing the Cordys@Work methodology is not yet two years beyond its initial inception. For any methodology this must be considered early days. However, the way in which Cordys@Work has been engineered to build on the SOA methodologies used by major SIs and also leverages commonly-used methodologies such as Prince2 and Scrum. This gives Cordys the opportunity to focus on incorporating the specifics of its own software in its methodology and make it useful for customers and partners as quickly as possible. IN THIS WHITE PAPER This IDC White Paper describes the role that methodology plays in an SOA deployment in ensuring that the potential benefits of SOA are delivered in practice. It relates this general requirement to the Cordys@Work methodology, created by Cordys to assist its customers to derive maximum benefit from the Cordys products when used in a SOA deployment. SITUATION OVERVIEW Importance of Methodologies to SOA Implementations The purpose of SOA is to enable IT to respond more quickly to changing business requirements. This simple statement hides four decades of frustration that change requests inevitably attract a high price tag and a lengthy implementation period – for reasons that are often not obvious to the business. IT has become a black box to the business world, with no obvious way of mapping the time and cost of change requests onto the business value that is being sought. SOA aims to bridge the gap between IT and business mindsets by steering away from the technology-centric world of IT and instead describing its capabilities as a set of technology-independent services that can be assembled and reused in a timely and cost-effective manner. Of course, the technology underlying these services still exists, but SOA uses virtualization to abstract away the technical details to allow services based on different technologies to interoperate. Based on this virtualization, SOA provides a mechanism for: y Creating automated business processes that execute multiple steps – with or without human intervention depending on the process requirements y Creating new, very rich applications that combine the functionality of multiple services into a single user interface (composite applications) y Providing a simpler integration mechanism for ensuring consistency of information where there is an overlap in the functionality of multiple business applications y Outsourcing selected business operations and the associated IT infrastructure while still retaining the functionality within the scope of larger processes y Adding further automated processes and composite applications as required by the business, without modifying the underlying applications in any way y Changing the flow of existing processes and the functionality of composite applications without requiring changes to the underlying applications y Replacing applications that are no longer cost-effective, while minimizing the impact on the other components. 2 # ©2006 IDC So much for the benefits. They are all achievable in practice – but it isn't reasonable to expect that all of this added value is going to be delivered without some level of cost. In fact, one of the mistakes made by the IT community at the beginning of the SOA lifecycle was to understate the work and cost that would be involved in a successful implementation. Yes, SOA can be very cost-effective, but not necessarily cheap! Despite the fact that software vendors are putting a lot of effort in increasing the quality of their software tools, it is still possible to deploy all of this technology without seeing the full value of the benefits SOA offers. To gain maximum value from SOA, implementations need to be approached in an organized manner that is mindful of the benefits needed; hence the need to consider the methodological approach to SOA projects. The manner in which these projects are designed, managed, changed and implemented is at least as important as the selection of the supporting technology. Why Are SOA Methodologies Different? IT methodologies have evolved over the last three decades as systems grew more complex and demanded clarity in the approach to requirements definition and the transformation of requirements into robust, complete systems. Large changes in the capabilities of the underlying technologies have demanded constant rethinking of the best methodological approach. The resulting methodologies have developed from the information-centric definition of corporate databases, through the top-down "waterfall" methodologies for the complete definition of major systems. In these definitions, each phase had to be entirely complete before starting on the next. Changes to requirements came at enormous cost, through rapid development methodologies such as using prototyping, also taking distributed processing, client/server, Web access, and so on into account. SOA is, potentially, the most demanding situation from the perspective of methodologies, since the aim is to put in place a set of services, and the technology foundation, which will permit the assembly of a wide variety of systems in a very short timeframe, and the accommodation of the large number of changes demanded by the business world. Obviously, the IT departments wish to deliver early value to the business from the first SOA projects so that further investment can be justified, yet at the same time any design errors or shortcuts that are made at an early stage can impact the ability to deliver the economies of reuse further down the line. SOA is so far-reaching that the methodology needs to address a broad spectrum of issues, some of which are organizational rather than directly IT focused. As a minimum, the methodology needs to address: y Discovering the business activities that need to be supported and their associated priorities y Establishing the services that need to be made available to support the business activities y Mapping the services to available IT functionality, analyzing the capability of existing applications to deliver the required services, and identifying where new services must be created y Providing the virtualization of the existing applications into a set of technology- independent services ©2006 IDC # 3 y Designing the composition of services into rich applications and automated business processes y Preparing the organization to exploit the new capabilities.