Service Oriented Architecture - Building services that business can trust

By Ben van Niekerk, Compuware Southern Africa

Realising the considerable potential of Service Oriented Architecture depends on persuading people that your components are worth using. The best way to inspire that confidence is to create a testing methodology that prioritises quality and performance from day one, argues Compuware's Ben van Niekerk.

Service Oriented Architecture (SOA) is fast becoming the software development community's latest must-have: Gartner has forecast that as many as 80% of new build projects will be using it by 2008. But much of this work will be wasted if IT management doesn't take steps to ensure that services actually get used.

The attractions of SOA are not in doubt. Early adopters such as Guardian Life Insurance are reporting multi-million dollar savings from SOA. A study by Aberdeen Group suggests that adoption of SOA typically reduces integration costs by 5% or more; others have suggested that savings could be as high as 30%. The sizeable discrepancy between these estimates may reflect the fact that to derive maximum benefit an organisation must embrace SOA across the board, with company-wide adherence to appropriate procedures. In fact, the opportunity that SOA presents for standardisation is a benefit in its own right, and one that may be at least as valuable as the cost savings.

The main reason SOA can offer these gains is that it goes much further than previous initiatives to obtain the benefits of re-use. In contrast with modular, object-oriented or "conventional" component-based development, SOA delivers re-use at a business level and not just at a technical one.

SOA means interoperability across departments, in other words: allowing one business unit to use services provided by another. But achieving this interoperability depends on persuading people in other parts of your organisation to use the services you have written, by making both new and existing applications invoke the services instead of re-developing the code within the application (and thereby re-inventing the wheel).

Success in persuading people in other parts of the organisation to use services depends on letting people know what services are available, but also, crucially, on convincing them that those services are good enough to use. Creators of services must therefore not only provide consistent, comprehensible documentation of functionality and use, but must also document the services' quality, including their performance - which should preferably be defined in terms of a service level agreement. Without an assurance of quality, uptake will be patchy and your savings may be nearer the 5% level than the 30%.

How can we guarantee quality?

What must service developers do to make sure that their components are good enough to be used, in terms of both performance and of overall quality? Firstly, developers must understand users' requirements - something that becomes more challenging with this type of re-use, where the same service could be used by many different parts of the business. For example, a credit check service could be used by departments approving mortgages, those granting new or extended overdrafts, and those opening accounts for new customers. Service designers must appreciate their varying needs and meet them all in a consistent manner. They must produce an unambiguous specification that makes it clear what the component will and won't do - a necessity if duplication is to be avoided. Formal requirements management techniques can help in achieving, and maintaining, precise specifications.

As they start to build the new service, the development team should keep a close eye on quality. Right from the start of coding, they should be using procedures and development utilities that guarantee ease of maintenance and optimum performance. Today there are solutions that automatically assess code for maintainability and efficiency, and make suggestions for improvement, rather like a robotic senior programmer.

Even so, traditional component testing won't be enough for SOA. Given that performance can make or break later adoption, it's essential to tackle any performance issues early on, ideally while the code is still under development. If you identify potential bottlenecks at this stage, they can be quickly and cheaply rectified; it's another story if you have to do it during load testing. Fortunately, the latest code profiling solutions are able to spot potential performance problems at the component testing stage, revealing pitfalls like deeply nested SQL calls that will impede response. For very little additional effort during load testing, therefore, you can guarantee the performance of the finished component.

Building trust

Procedures and solutions like the ones we've outlined will bake quality into SOA components from the outset. The same approach can also provide prospective users with evidence that the component is fit for use.

For example, the solutions can automatically document code coverage during unit testing, ensuring that all possible routes through the code have been covered and that all possible combinations of tests have been executed. The tools can also show that regression testing has been repeated at appropriate junctures. On the performance front, monitoring software can document the component's response time, showing that it meets agreed service levels and also indicating how much of an overhead it will impose on a given application.

By creating a testing methodology based on standardised testing procedures and supported by suitable software tools, you can reassure prospective users that the components on offer are trustworthy. The methodology can ensure that best practice is followed, for example, by stipulating that certain testing activities should be carried out by an independent team with a business as well as a technical perspective. A methodology like this can effectively act as a certificate of quality, in much the same way as TickIT approval.

Ultimately, acceptance of SOA components is a matter of trust; each component is, after all, something of a black box for the people who are being invited to use it. The process that generates the components must inspire trust at all levels of the business, from senior management to technicians.

For the IT manager embarking on the journey towards SOA, the first step should be to create a methodology that prioritises quality and performance from the earliest days of development, that promulgates best practice across the development team, and that clearly documents the results achieved. The methodology should define how and when in the lifecycle any software tools are used; just putting tools there and leaving it up to individuals to decide when to use them will not produce the desired results.

Showing your users that you are adhering to a watertight methodology is the surest way to win their trust. Once you have earned that trust, you stand the best chance of maximising the return on your investment in SOA, and can realistically look for 30% savings rather than settling for 5%.