Getting SOA to work for you

By Edwin Schumacher, Director Product Management Compuware

Service Oriented Architecture (SOA) is the subject of growing interest, for excellent reasons. The central idea behind SOA is that, with today's fast reliable networks, it makes sense to put frequently-required applications on servers where they can be used by everyone within an organisation. At the same time, monolithic applications can be split up into independent services - each of which performs a single well-defined business function.

Once enough services have been deployed, much of the work traditionally involved in creating new applications becomes unnecessary; the services are already there, just waiting to be invoked. And whenever a new service is added, all existing applications immediately gain the benefit of its functionality. The essence of SOA is to identify services at the business level, thus ensuring that every service makes a clear-cut contribution to the value chain.

From a business point of view, the benefits are obvious. At present, many desirable initiatives are held up by the notorious "applications backlog". Not only does SOA promise to save time and money by slashing development times for new applications; it can drastically reduce "time to market", allowing companies to seize business opportunities the moment they arise.

One of the best features of SOA is its flexibility. Many different kinds of middleware can be used in an SOA; for instance RPC, CORBA, RMI or JMS. Although Web services have often been associated with SOA, it is quite possible to build an industrial-strength SOA in which Web services play no part at all. Nevertheless, there is much to be said for using Web services, with SOAP as the main wire protocol, XML as the message format and WSDL as the service description language.

SOA can bring significant business benefits if implemented correctly. As with any new technology, however, there are plenty of snares and pitfalls. When creating an SOA, for example, organisations often adopt one of the two following approaches:

1. Take advantage of an IDE that creates Web services automatically. Such an "SOA" is difficult to change quickly. Above all, it fails one of the most critical tests of an SOA, as services are not defined at the business level, but inherited from the structure of existing applications.
2. Start by writing XML schema and WSDL. This is the right way to go about things, but much of the coding must still be done by hand - which is slow, costly and error-prone.

It looks as if we need a radically different approach to constructing SOAs.

So how can organisations start SOAs that deliver? SOAs that are built piecemeal are all too likely to end up as complicated messes. The best policy is to start with a Business Model, and refine it through schemas, Architecture Models and code. Model - Driven - Pattern - Based development is the best way of doing this.

Chronic mismatches between IT and business have caused untold amounts of trouble across the gamut of industry and commerce. Government projects have become a byword for failure, due to their size and the tendency of requirements to shift during development. According to analysts, as many as 70% of today's IT projects fail to meet their objectives.

One of the main causes of the "software crisis" is that too many people - with dramatically different skill sets and assumptions - are "in the loop". Project sponsors and end-users talk to systems analysts, who gather requirements and pass them to designers. Eventually, programmers get involved, and have to write code that does exactly what the sponsors and end-users want - even if that has changed since it was first documented (as it usually does). All too often, the result is software that does not meet the current needs of the business. And getting applications changed to reflect new business conditions takes so long that the software is always out of date.

Both SOA and MDPB development strike at the heart of these difficulties, thus helping to align business and IT more closely. In SOA, each service is carefully designed to implement a well-defined business function; so business managers can readily understand how the system works. When a department changes its way of working, it is easy to modify the corresponding services without affecting any other software. And if new activities are undertaken, it takes little time to create new services to support them.

MDPB, for its part, goes a long way toward eliminating the communication barrier between those who specify the software and those who build it. Instead of sponsors and end-users talking to analysts, who talk to designers, who talk to programmers, they can actively help the analysts to create the Business Model. When the Business Model is completely to their satisfaction, a pattern-based tool like OptimalJ can speedily translate it to an Architecture Model, generate a running application, and test it to ensure the correct behaviour. Changes, too, are made directly to the Business Model, so that the software can be quickly and easily kept in step with current business operations.

Using MDPB, many existing applications can be converted to SOA. Others (such as legacies) can participate once some wrapper code is written. This initiates a virtuous cycle, as all new applications can become part of the SOA. The more SOA applications there are, and the more services to be invoked, the more powerful the whole - and the quicker it becomes to add new applications, or change the behaviour of existing ones as business needs dictate.

What is needed is a sound development strategy base on three complementary requirements:

1. Faster Development - Applications and systems must be built as quickly as possible without quality being affected, to save time and money, but above all to respond to fast-changing business opportunities.
2. Agility - It must be possible to change or extend applications quickly, easily and with a minimum of risk.
3. Business-Driven Approach - Now more than ever, applications need to reflect business requirements promptly and accurately.

MDPB development fulfils all three requirements.

It confers extreme productivity within a standards-based approach, and allows developers to be highly business-focussed.

Faster Development

The typical enterprise always needs more new software (and needs it sooner) than its IT department can deliver. Worse still, application complexity has burgeoned dramatically. Today's developers have to cope with distributed systems, multiple programming languages, bigger teams, and geographical separation (sometimes across time zones). Under these circumstances, it is optimistic indeed to hope for faster development - but there is compelling evidence that MDPB development can deliver just that.

Agility

Just as MDPB development is faster, it also makes software maintenance, extension and modification far easier and safer. Technical innovations and improvements can easily be absorbed. A single developer can change a whole application to reflect a new house style without any manual coding at all.

All too often, companies have seen their strategies frustrated by the inflexibility of software. In a few cases, mergers have even been called off because the respective IT systems were so completely incompatible that it was not practical to integrate them.

MDPB development minimises the risk of such damaging consequences, because it makes corporate applications far more flexible. If a new business opportunity crops up, the necessary business processes can usually be created just by editing the Business Model and regenerating the relevant applications. Or if a new system has to be rolled out, the Business Model can easily be translated to a new Architecture Model.

Thus an existing J2EE system can quickly be upgraded to support Web services, providing the basis for an SOA. This would also be done by translating the unchanged Business Model to a fresh Architecture Model, this time with additional logic for WSDL, SOAP and other Web service specific languages and protocols. For instance, existing EJBs could simply be given extra Web service interfaces. With this approach, an SOA can be created in a few hours at virtually no additional cost.

Business-Driven Approach

Close alignment of IT with the business is often cited as a prime benefit of SOA. But this does not happen automatically: Most organisations today have "stovepipe" or "silo" architectures, in which every individual department or function has gone its own way. Adding Web services to these will merely turn them into messy, distributed stovepipe architectures. It will still be quite unclear who owns which services, what levels of service are committed to by whom, and what happens when things go wrong.

Close integration of IT with the business implies a tight feedback loop, in which any departures from intended behaviour are quickly identified and fixed. MDPB development fits this description perfectly, as requirements are gathered from user input, turned into business models, and translated - by a highly automated series of steps - into code. If the result is not what sponsors or users want, it is quick and easy to change the model accordingly, and generate a new and better application. On the other hand, this process is very prone to error when undertaken manually.