Whatever... [Deepak Alur's Blog]: Deepak Alur's Blog @ Sun

Outsourcing is an increasingly popular trend in the IT industry. However, from an architectural prespective, there are many nuances about outsourcing that I have been focussing on lately to understand.

Let me discuss different models of outsourcing I have seen from a software development perspective. I suspect these models are applicable for any systems development. But, software is my game and I am sticking to it. Let us categorize the project activities broadly into 5 areas: Requirements/Analysis, Design, Development, Deployment and Management/Maintenance. The Owner is an entity (team, department, division, company) that owns the project and the Outsourcer is an entity (mostly in another company) that executes various tasks assigned by the Owner. The Owner is always in charge of the requirements so outsourcing that activity may not make much sense in most cases. Anyway, I have seen several different models of outsourcing when it comes to IT organizations working with an Outsourcer. I have categorized them as follows:

Model 1: All In (AI)
This is the traditional model of development where everything is done inhouse, i.e. no outsourcing.

Model 2: Development Out (DO)
Outsource only the development activity. The Owner is still responsible for design and is trying to leverage lower development costs by outsourcing the development activity. Once the Outsourcer completes development, the code is brought inhouse for deployment, management and maintenance.

Model 3: Design Out, Develop Out (DODO)
[No, not that Dodo, although there might be some similarities] This model extends Model 2, but in this case the design also becomes a responsibility of the Outsourcer. This is more suitable if the Owner has limited IT development capabilities (e.g. skills & resources).

Model 4: Design In, Rest Out (DIRO)
In this model, the Owner designs the system and delegates the development, deployment and management of the system to the Outsourcer. I don't see a value in this model for most scenarios. If you are going to hand off the management of the system to the Outsourcer, let them design as they see fit.

Model 5: All Out (AO)
This is the inverse of Model 1 where the Owner delegates all activities (except for Requirements) to the Outsourcer. This is similar to the ASP model. This is the model that most Outsourcers might prefer. If executed properly, this can be a win-win scenario for both parties.

Some of the customers I have talked to have been experimenting with Model 2 and Model 3. And this model exhibits the pain points of architecture and design. When you are designing a system and having someone else implement it, it becomes a tedious and sometimes impossible task to govern the architecture and design of the system on a continuous basis. A lot of architects in this model spend their cycles on the phone talking to the developers in a different world trying to communicate the design intentions and the confirm and validate the developer implementations to ensure those intentions are addressed and implemented.

What do you think? Do these models make sense? Have you seen other models? What are the (architectural/design/development related) pain points for architects when dealing with outsourcing?

May 26 2005: Also see this followup.