Understanding Outsourcing Models

Outsourcing Models for Software developmentOutsourcing
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.


Published by


Cofounder & CTO @ Chartcube.com