It’s easy to be cynical in the face of yet another technology acronym that few seem able to explain in terms that make sense to the non-technical majority. In this article, Methods Consulting examines what lies behind the hype and why SOA really does have the potential to transform an organisation’s IT.
The same old promises?
As many in the IT arena readily admit, it’s easy to grow jaded with the hype that seems to surround the ‘latest’ technology. How many times have we heard that some new piece of software or development approach is the cure for all ills, only to be disappointed by endless tales of costly projects that failed to deliver? Such cynicism certainly greeted “service oriented architecture” (SOA) when it arrived on the block and began to make its presence felt.
What is SOA?
SOA is a relatively new approach to IT that encompasses solution analysis, technical design and delivery. The problem for SOA is that the elevator pitch sounds all too familiar: ‘here is an approach to software development that seeks to “align IT with the business” by developing solutions using “loosely coupled” component services.’ These services are said to improve ROI and agility by encouraging re-configuration or re-use of assets rather than green-field re-development. “Plug and play” interoperability across diverse platforms, networks and geographies is also said to be on offer. Whilst in themselves statements like these might impress those who are a little wet behind the ears, anyone who lived through the era of object oriented programming, component based design or even CORBA and DCOM might be forgiven for being a little more sceptical. Many of us have surely heard these high brow visions of IT-driven nirvana somewhere before.
What makes SOA different?
Despite such misgivings, SOA certainly seems to be creating a storm, with major vendors such as IBM and Microsoft vying to muscle in on what appears to be a burgeoning industry. In fact, we believe that SOA truly does offer something new and exciting in terms of business-focused solutions architecture. In order to understand why, we need to spend a little time reminding ourselves of the issues that typically beset organisations as they struggle to roll out effective information technology. Among the most common of these are:
Flawed communications: difficulty in translating business needs into concrete requirements that computer specialists can turn into useful software.
Re-invention: a propensity to re-build every new solution from scratch rather than re-using at least some existing IT assets.
Lack of agility in light of the above: difficulty delivering IT at the speed required in order to keep up with continual changes in the business and regulatory environments.
The past twenty years has seen the computing industry attempt to tackle these issues in a number of ways. Firstly, there has been a drive towards “component based design”, whereby systems are assembled from ready made, re-usable building blocks rather than being constructed into a monolithic whole from raw materials; after all, you wouldn’t expect your car to be custom built for you – right down to hand tapped nuts and bolts! Secondly, in an attempt to bridge the chasm in understanding that all-too-often looms between the board room and the IT back office, various software modelling tools have been developed. These allow business people to specify solutions in a way that can be plugged directly into the software development process without the need for a cadre of analysts acting as intermediaries and the attached risks of “Chinese whispers” distorting the deliverables.
Viewed with this history in mind, SOA’s promise of “assembling re-usable business-focused services” seem distinctly second hand. However, closer examination reveals several important differences:
Emerging standards: The trouble with assembly from building blocks is that Lego and Meccano don’t mix. It’s historically been very difficult to achieve true interoperability, whereby software components from different vendors will talk to each other with minimal fuss. The SOA movement has made a point of defining what constitutes a “service” very thoroughly, making it possible for parts of a solution to establish reliable “contracts” guaranteeing predictable, stable interactions. These definitions are becoming de-facto standards and are managed by vendor-independent bodies such as the Open Applications Group.
More powerful building blocks: As mentioned above, the “monolithic” applications of years gone by did not lend themselves to easy re-use. At the opposite end of the spectrum, the component based systems of the 1990s tended to result in code modules that were too granular for business professionals to understand. A widget to add two numbers and then store the result in a database is unlikely to set the board room alight: things get much more interesting when the software building blocks on offer perform recognisable business services, such as “Process order” or “Obtain credit rating”. The SOA approach focuses on designing functionality at precisely this higher level.
Improved semantics: Where early attempts at defining component interfaces (i.e., the “contracts” that software elements strike when they try to talk to each other) concentrated on necessary but uninspiring detail, such as network protocols and how to package bytes of data, SOA has evolved to include more useful business semantics. Business protagonists can expect to lay down the rules regarding quality of service, timeliness of response and tolerances for transaction costs when specifying the elements of a service oriented architecture.
Improved support tools: The latest generation of SOA-based modelling tools take advantage of the above developments to deliver graphical designers that empower business users to re-design business processes directly, rather than merely generating diagrams for software engineers to interpret and implement.
Reduced technology risks: SOA designs and the resulting communications between software components are not reliant on proprietary standards. Where CORBA and DCOM forced adopters to choose between competing binary standards that only certain platforms could use, SOA’s protocol stack is largely based in human-readable text files (structured according to well-known formats such as XML and SOAP) that can be processed by most modern computers.
All of this means that the Service Oriented Architecture approach merits serious attention.
One of the best ways to enter the SOA arena is to undertake a pilot project. This needs carefully designed and planned in order to achieve appropriate benefits for an acceptable level of risk. Typical phases include:
Stakeholder identification: remembering that SOA is much more than a technical approach to software delivery, pilot projects should begin by creating an appropriate forum in which to define project objectives. This forum should include representatives of an organisation's management, delivery and technical functions.
Strategic planning: whilst the pilot may be small, it's important to position it within a broader framework that sets out the strategic future for the organisation’s IT infrastructure. This is a complex topic but basically involves ensuring that every IT project is aligned with the organisation's long term business objectives - a core aspect of SOA. The stakeholders convened in the previous step must be ready to accept ongoing responsibility for ensuring that this is the case; if they're not willing or lack the resources to do so, ask serious questions about commitment to the goal.
Project identification: This is in many ways the most critical part of SOA adoption: the fate of the pilot is likely to decide the fate of SOA as a whole! Aim to deliver a project that is small in scale but that adds lasting value. It's important to identify a project that is both sufficiently relevant to be visible to stakeholders whilst not being mission critical in a way that would carry more risk than a pilot ought to bear. With this in mind, organisations commonly opt to deliver internally facing applications first; look for systems that are currently sources of irritation rather than an out and out drain on the bottom line. Intranet enablement of existing data / knowledge stores or solutions that consolidate multiple information sources into a single portal are popular. Finally, avoid the pitfall of creating a solution that will not adapt and scale well as part of a larger whole: the pilot should include at least one service element that's likely to be of use in projects that are envisioned by the strategic planning exercise.
Project planning and delivery: As stated elsewhere in this article, SOA does not imply throwing away the entire project delivery rule book and does not, therefore, obviate the need for thorough and ongoing planning. Project costs will vary and need not be high but the benefits should always exceed them. With this in mind, it is of particular importance to a pilot to create a benefits realisation plan that describes the perceived advantages the project will deliver and especially how these are to be measured against costs. It's critical to agree this with all stakeholders at the outset if disappointment and misunderstanding is to be avoided.
How Methods Consulting can help
The IT industry’s commitment to SOA is evident in the large number of vendors that have released tools to develop and manage service oriented solutions. These range from coding environments for developing individual software modules to packages that register available services and broker contracts between them. The breadth of choice is huge and the panoply of SOA adoption routes dizzying.
Methods Consulting has no vendor partnerships and can therefore maintains its ability to give impartial advice in terms of adoption of SOA and our ability to deliver solutions using a variety of differing tools and technologies.
While we understand that each client’s situation is unique, examples of the sorts of assignments we undertake include:
Readiness reviews: Given the considerable potential costs involved both in terms of change management and IT spend it’s important to be sure that the SOA approach is suitable and realistic for a given organisation before committing to it. For these reasons, Methods Consulting provides “readiness review” services that help de-risk the SOA decision by providing a cost effective, independent analysis of the potential costs and benefits of a service oriented approach.
Strategic consultancy: Although SOA is potentially very powerful, it shouldn’t be viewed as a panacea: you cannot wave a wand and make the IT problem disappear. For this reason, SOA is as much a philosophy – an approach to developing solutions – as it is a set of well defined standards that help to deliver agile, interoperable computing solutions. Methods Consulting recognises what SOA teaches: sound, ongoing business analysis is of paramount importance to successful outcomes. We work with our clients to establish the organisational structures required to monitor and govern IT programmes on an ongoing basis – and we won’t pretend that this governance is a one-off or finite exercise.
Delivery projects: As well as providing consultancy assistance on projects, we have a successful track record of delivering and supporting solutions on a range of commercial basis., from fixed price through transaction pricing and service charges through to benefit sharing.
___________________
Martin Little is a senior technical consultant and long-standing Methods Consulting associate with extensive experience of solution design and delivery in public and private sector environments. Martin is a Microsoft Certified Solutions Designer with a particular interest in component based architectures and knowledge management issues.
