Software Outsourcing

Companies outsource their software development for several reasons:

1. It is cheaper because the outsource contractors use cheap labour (usually with development shops based in countries with lower wage rates).
2. It is cheaper because the outsource contractors can achieve economies of scale - for example through some form of software reuse. (Anyone really believe this?)
   
3. It allows companies to manage variations in the volume of software development work, without the need to hire extra staff.
4. It reduces the dependence on an inhouse IT department - especially where there is a history of poor performance.
   

But there are some perceived disadvantages of software outsourcing.

1. Increased "distance" and weak communication between the developers and the users. Issues of business/IT alignment.
   
2. Reduced client control over the software product and process. Issues of trust and security.
   

In this post, I want to discuss how a service-oriented approach affects this equation.

Architecture

The customer organization typically retains responsibility for requirements and architecture. This means that the software specifications are produced by business analysts and software architects in the customer organization. The outsource contractor then produces software artefacts according to these specifications and delivers these artefacts back to the customer organization, where they are tested and deployed.

The first problem here is with the depth of the testing. Most IT departments have got people who know how to do functional testing, usability testing, performance testing - but that's not enough. Presumably the architects have devoted some attention to producing an overall solution with certain architectural characteristics, such as flexibility/maintainability. The requirements will have been stratified into layers and decomposed into discrete units (modules, components, services); the architects will have sought to achieve high cohesion and low coupling, both horizontally and vertically.

However, developers may have an incentive to produce software that is inflexible and more expensive to maintain, because this generates future income for themselves. They can achieve this by introducing hidden coupling between layers, tight coupling where the architects intended loose coupling, inappropriate bindings of varying kinds. Even if these are detected, it is hard to determine whether they were inserted deliberately or merely slipped in as a result of poor development practices. And in most cases, they will not be detected until much later.

So it is crucial for architects in the customer organization to verify that the developers have conformed to the original architectural intentions. This entails an ability to discover the actual architectural structure of the delivered software artefacts - and this may involve a combination of code inspection (static analysis) and runtime monitoring (dynamic analysis). We are starting to see web service modelling and management tools that provide some support for architecture discovery; the next step will be tool support for architecture verification.

Automation

Service-oriented computing reinforces the importance of tools. In the past, development tools for modelling, design and code-generation were regarded as productivity aids. This meant they were sometimes used in high-wage economies (USA, Western Europe) to cut labour costs, but could not be cost-justified in lower-wage economies (Eastern Europe, India).

One modelling tool vendor tells me that this is now changing, at least in India (but not yet in Eastern Europe/Russia), where software companies acquire these tools to improve the relationship with the client and to improve software quality. In other words, the relationship between the outsourcing customer and the outsourcing provider is being automated - reducing the communication distance between developers and users.

Agility/Granularity

The growing importance of components and services opens up the possibility of software development at a much finer level of granularity, with small software artefacts developed independently and composed using web service protocols and orchestration languages (such as BPEL).

Although this could result in a degree of fragmentation, we may expect collaborative software development platforms to appear, which would have to deal with the administration, transaction costs and requirements/quality issues - probably with a strong flavour of agile development

Anticlockwise

In terms of the Boxer Model of Collaborative Composition, software outsourcing typically follows an anticlockwise path - focused on achieving economies of scale. There are significant challenges involved in moving to a clockwise path. I shall return to this subject in another post.