Information Age: News, analysis & insight for IT & business leaders

Outsourcing is seen as cheaper, especially if offshore workers are used, and more flexible. The ongoing cost of keeping teams of developers on the payroll is becoming harder to justify for companies whose core competence is not IT.

"In-house development can be a distraction, and the maintenance costs can be astronomical," cautions Ashim Pal, an analyst with Meta Group. "It may be cheaper, initially, to develop software yourself, but the amount of money you spend on upgrades and support is much, much greater."

But if the economics are moving steadily towards outsourcing, there is a catch: potential savings from outsourcing will not be achieved if the relationship between the client and the outsourcing partner breaks down.

There are numerous areas of difficulty. Customers, for example, must be sure that their software project will be delivered on time and to budget; there is the inevitable issue of 'feature creep' and changing specifications; and, increasingly, security is an issue.

Outsourcers must maintain levels that are at least as high as those of an in-house team, especially where customer data is concerned. One reason why relationships sour is that the parties simply fail to maintain a good ongoing relationship.

Perhaps the most common reason cited for not outsourcing software projects, especially those that affect core systems, is that managers fear becoming overly dependent on an external supplier. They worry that the expertise will increasingly rest with the outsourcing partner, rather than the internal IT department.

There is no silver bullet solution to these issues, which often stem from the ability of the parties to communicate and to work together for mutual benefit over a sustained period.

But some of the problems related to trust and dependency can be avoided by following best practice when it comes to drawing up an outsourcing contract.

Analysts perpetually warn that businesses frequently fail to put sufficient time and thought into the outsourcing agreement. This does not mean that they are naïve or duped. In fact, frequently they place too much emphasis on a legalistic document with severe penalties for non-delivery, but fail to work in mechanisms for dealing with problems before they escalate to a full-blown contractual dispute. The Meta Group says that contracts need "lighter, faster ways of dealing with disputes" that stop short of full, financial penalties.

Legally-driven contracts can make most sense when applied to outsourced commodity services, where it is simple to calculate delivery metrics.

In complex application development projects, however, the scope for mis-communication and misunderstanding is that much greater. Both parties need systems to review progress, and deal quickly with any problems that arise.

Other issues: ensure that contracts suit what might well be a long-term partnership; expect the supplier to make a sustainable profit over the period of the contract, as supplier failure benefits no-one; and make sure that exit strategies, which cover intellectual property and continuing access to systems and resources, are in place in case the relationship breaks down.

Outsourcing to the web

If the customers follow these best-practice procedures, they should be able to build a trusted relationship with the outsourcing development partner.

The issues are rather different, however, when organisations outsource to a web service, rather than outsource the development or management of a conventional application.

Outsourcing to a web service might mean buying in a single piece of data, such as time or a currency price. But it could also mean outsourcing a service such as payroll processing, or an entire online application such as running an electronic market place.

The process is technically simple. The customer's system sends an XML document to the service supplier's web address where it is processed and sent back. It might be a simple application - filling in the prices of books, for example - or it might involve carrying out a share transaction. This outsourcing process can occur even if the partners have never met - and it entails quite a different business relationship than, for example, when a business outsources a software development project, or the management of an entire, monolithic application.

Once again, trust and dependency are key issues. If a web service is an interchangable commodity, with a wide range of qualified suppliers in the market and short set-up times, there should be few issues with dependency: it should be easy to switch suppliers. This is where web services can prove most powerful.

If a bank needed a currency price at noon each day to price contracts, for example, there would be little need for a complex contract - several currency markets or dealers could supply the pricing information. In the same way, a retailer could easily outsource a search engine for its web site.

If however, the service is more complicated and specialist, the relationship is more comparable to a classic outsourcing one and the partners should develop a full business and legal relationship. In the case of complex IT applications, web services will be simply another delivery channel, albeit one that allows more granular outsourcing than a conventional arrangement could support.

And, just as with outsourcing conventional software development, the more critical the service, the more vital it is that both parties agree the terms of their relationship.

Technically, web services may make some issues of trust easier to overcome. For example, using the technology, the service supplier is unlikely to be able to see into the client's systems - so some issues of trust will be minimal. The client simply needs to ensure that the information supplied is accurate, timely and that links between the external partner are protected from interference.

But equally, buyers of web services need to develop a cautious attitude, backed up best practices in diligence and testing. The ease with which external web services can be inserted into mission-critical programs could encourage complacency. There is no technical standard for programming in trust - it has to be earned.