SOA Adoption: Tracking the Use, Maturity, and Best Practices of SOA

CATALYST
There is now considerable experience in deploying solutions based on a Service Oriented Architecture (SOA). Most, but not all, of those experiences have been positive ones. Regardless of the perceived success many lessons have been learned that have refined our expectations of SOA and increased the prospects of success for later adopters.
This Report re-examines many of the principles and assumptions surrounding SOA to give an up-to-date appraisal of issues around the business, the platform, governance, and design. It includes recent survey results that show how maturity has progressed and also indicates the lack of balance between domains that is still encountered too often. A set of case studies reveals how individual organisations have deployed SOA to meet specific requirements, and describes the lessons they have learned from which others can benefit.

Introduction
The purpose of SOA is to provide a long-lived catalogue of services that deliver functionality of recognised value to the business. The services must be capable of being used (or ‘consumed’) in any valid context irrespective of differences in technology, and they must be capable of evolving as requirements change with the minimum possible impact on consumers or other services.
The architectural principles around SOA have been designed to support these long-term benefits, and the supporting technology has been designed to provide the autonomy and abstraction that is needed by a long period of agile business change. However, the architectural principles and the technology have to be implemented and managed correctly, otherwise the potential benefits could be lost and SOA become just another layer of middleware that has to be supported.

Business Issues
Recent business pressures have been dominated by the impact of the recession, which has influenced business plans and spending patterns across every industry sector in most parts of the world. The recession has highlighted the difference between organisations that already had a well-established plan for exploiting SOA and those that have been adopting a ‘watching and waiting’ approach. Those that have already achieved a substantial move towards broad SOA adoption have been able to exploit the business agility that it enables, introducing more efficient and effective ways of working, and adapting products and services to the market conditions.
Organisations that have not yet made a significant move towards SOA are now facing the need to invest in order to gain the agility they need, but are finding it difficult to make a sound business case for the investment. Projects are, of necessity, built around short-term ROI. While this is within the capability of SOA, it can lead to under-investment in the analysis and architecture, which could compromise long-term benefits.
For all organisations, expectations for a new era of consumer/supplier relationships based around active participation and self-service applications are heightening the need for adaptable applications and simpler processes, as well as the need to prevent accidental or deliberate incursions by external users into sensitive internal systems. The abstraction provided by SOA is an important capability in enabling these new interfaces.

Technology Issues
The capabilities that are required of the IT infrastructure to support SOA deployments are now very well understood, but the packaging of these capabilities into products is open to a number of different interpretations. The ESB is still the most widely deployed option, delivering functionality in an inherently distributed and extensible fashion. However, the term ESB is used to describe products with different levels
of included functionality, and many vendors are now choosing to use the term ‘SOA Suite’ to describe the ESB messaging platform and extra functionality such as rules engines, repositories, lifecycle management, and runtime governance products.
Beyond the ESB, alternative form factors are viable and have a reasonable level of adoption. Hardware appliances offer to unload some or all of the expensive XML processing workload from conventional servers onto specially configured hardware. These appliances range in capability from purely security-focused, through advanced policy management, to a full ‘ESB in a box’, and in addition to offloading work from servers can be used to simplify the establishment of the SOA environment. This trend towards an appliance model of deployment has been somewhat altered by the recent introduction of software appliances, which reduces the complexity of a normal software installation by providing all the levels of the software stack needed by the SOA infrastructure into a single installation package that can be deployed directly onto commodity hardware.

Finally, there are a number of vendor-specific proprietary SOA infrastructure products. These aim to provide all the functionality required of an SOA environment, but instead of being constructed around a standards based messaging platform (which infers a degree of open extension capability), have a more tightly integrated bundling of the functionality. This has benefits in simplifying the infrastructure and making for a simpler implementation, but makes it more difficult to integrate third-party add-on products.

Market Issues
Merger and acquisition activities within the SOA vendor world have had a marked impact on the choice and functionality of products. As the number of established vendors slowly dwindles, the scope of products available from those remaining has ramped up as each one attempts to become a ‘one-stop-shop’. The level of integration of these offerings is a work in progress, and likely to remain so as there seems no end in sight to the acquisition trail.

Challenges to the established market come from vendors that have successfully used mergers, acquisitions, and strategic partnerships to put together an end-to-end capability level that matches those of the established leaders. While this has been going on, several open source products have now reached the state of maturity where they could be considered serious competition to traditionally licensed products, though none has yet achieved the one-stop-shop status. In particular, high-end SOA governance tools appear to have little serious competition from the open source world. Further innovations to the SOA technology line-up are likely to come from the merging of separate initiatives. In particular, Complex Event Processing (CEP), Master Data Management (MDM), and Enterprise 2.0 are all directly relevant and supportive of SOA, so we should expect to see features supporting these initiatives becoming included within SOA suites.

Conclusions

The experiences detailed in this Report show that there is no ‘one size fits all’ approach to SOA adoption.
It can be part of a successful strategy for small organisations or large enterprises, and private or public sector alike, provided that a realistic assessment is made of the desire of the business to embrace change, the capabilities of the organisation, and the level of investment that will be required.
Adopting SOA means a significant change to the way that most IT operations work. In particular it requires the ability to work collaboratively with the business in delivering limited-scope, incremental projects, while progressing towards the target of delivering business services through IT. SOA cannot (or should not) be considered as a stand-alone initiative, but should be considered as complementary to other business-visible initiatives that together have the capability of transforming the business world as much as the IT world.

This Report reveals:
Why business/IT collaboration is important from the start of the SOA deployment.
Why organisations must resist shortcutting the architectural design effort.
How to phase-in SOA governance to keep the cost proportional to the risks.
How the economic climate impacts the expectations of SOA.
How SOA mutually supports and exploits other IT and business innovations.
Why SOA is now approachable by small as well as large enterprises.
What types of deployment platform are viable alternatives to the Enterprise Service Bus.
How open source technology has become a viable alternative to traditionally-licensed SOA products.


Report Highlights
KEY FINDINGS
SOA is not just for large enterprises – smaller organisations can also benefit, aided by new delivery models.
Failure to ensure continuous business involvement and support is the most likely cause of project failure or dissatisfaction with SOA.
SOA is widely deployed in support of Business Process Management (BPM) projects, and provides the agility to support process optimisation and changing business requirements.
Recession in the economy has altered expectations to focus more on short-term deliverables. If taken to extremes this could damage the long-term benefits offered by SOA.
New collaborative business models based around Enterprise 2.0 concepts will demand the abstraction and service-level controls that are made possible by SOA.
Governance needs to be addressed across every phase of the lifecycle. Governance costs can be a large part of the total expenditure, but can be kept proportional to the risks and benefits.
• SOA governance should be regarded as an issue for people, with technology playing a supporting role, rather than as a technology issue.
• Allowing shortcuts to be implemented that compromise the abstraction or loose coupling will destabilise the architecture and put future benefits in doubt.
• The architectural design of the services is key to the long-term benefits that SOA offers. There are new approaches to ensuring that the design remains stable despite ongoing changes to requirements.
• Enterprise Service Bus (ESB) is not the only viable option for deployment. Appliances and proprietary software infrastructure products can provide good solutions in appropriate circumstances.
• There are many potential performance issues, but these can be overcome through a combination of design and technology.
• Open source products are now a viable alternative to ‘traditional’ commercial software. Organisations adopting open source products can reduce the initial cost of deployment provided they have adequate in-house resources.
• Cloud computing and Software-as-a-Service (SaaS) are complementary initiatives that reinforce the need for SOA. They also provide a potential platform for the delivery of the SOA infrastructure as a hosted service.
[Studien Infos ausblenden]

Contents - October 2009

Section 1: Management Summary 7
1.1 Management Summary 9
Section 2: Business Issues 13
2.1 Report Objectives and Structure 15
2.2 The Role of SOA in Business/IT Alignment 16
2.3 Justifying Investments in SOA 21
2.4 SOA in Different Economic Climates 26
Section 3: A Checkpoint on SOA Adoption 31
3.1 The Joint Butler Group/Griffiths Waite SOA Maturity Survey 33
3.2 SOA Maturity Survey Results 36
Section 4: The Practicalities of SOA Governance 53
4.1 Overview of SOA Governance 55
4.2 The Need for a Specific SOA Governance Initiative 56
4.3 The Problems of Delaying SOA Governance Implementation 60
4.4 Governance Across the SOA Lifecycle 62
4.5 Organisational Aspects of SOA Governance 66
4.6 Phased Deployment Permits an Early Start 67
Section 5: The Evolving SOA Platform 71
5.1 Evolving Expectations of the SOA Platform 73
5.2 Alternative Patterns for Placing SOA Logic 77
5.3 The Ascendency of Open Source 82
5.4 The Role of Hosting in SOA Deployments 86
5.5 The Implications of Software-as-a-Service and Cloud Computing 91
Section 6: Evolving Design Principles 95
6.1 The Relationship Between SOA and Complementary Initiatives 97
6.2 Formalising Service Design 101
6.3 Performance Issues, Solutions, and Workarounds 105
6.4 Application Development Perspectives of SOA 109
6.5 Packaged Applications and SOA 115
Section 7: Case Studies 123
7.1 Introduction to the Case Studies 125
7.2 Small Team SOA Deployment at Tewkesbury Borough Council 128
7.3 Small Team Deployment of SOA at Concur 134
7.4 SOA in Support of Spatial Information at New South Wales Department of Lands 139
7.5 Using SOA to Become a Preferred Partner – EBS Building Society 146
7.6 Providing SOA Implementation Assistance – Inter Access 151
7.7 SOA in Support of M&A Activity at a Large European Telecommunications Provider 154
7.8 Retrospective SOA Governance Implementation at Vital Forsikring ASA 158
7.9 Use of SOA at Municipality of Rotterdam 162
Section 8: Glossary 169
[Inhaltsverzeichnis ausblenden]

not available
[Tabellenverzeichnis ausblenden]