<< . .

( 36)

. . >>



int usin













In-house Outsourced offshore

Figure 1.5 Offshoring by phase of the software life cycle.
Source: Software Development Magazine, 2004.14
Survey results of US development managers/engineers in projects that were already partially or
fully offshored. Numbers do not add to 100 because the activity could be both in-house and
offshore and because some projects did not use some phases.

The best method for analyzing which activities are suitable for offshoring is to use the
software development life cycle. This was the approach taken in a survey conducted by an
American trade magazine that is depicted in Figure 1.5. The survey results show that
activities offshored most often were coding, testing, and maintenance; while those that
were least offshored were business integration, architecture, and requirements gathering.
This is a picture of two clusters: activities that are frequently offshored and those
that are not. This clustering is essentially the split offshore migration that was described
earlier in the chapter (Figure 1.2), in the forecasted separation between design and devel-
opment. Recall that the chart forecasted that development (such as coding) would move
offshore faster than design (where the word design was used broadly to include any
high-level activity including architecture). The survey results are consistent with the styl-
ized depiction of the life cycle in Figure 1.6, applied to offshore and onshore.
Let us take a closer look at these two clusters to see what differentiates them from
one another. First, activities offshored are those which: are standardized (commoditized),
can be precisely de¬ned (precisely speci¬ed), and may even be considered tedious, repet-
itive, and undesirable. Hence, coding and maintenance, which can be well de¬ned, are
often offshored.
Activities that tend to stay onshore are those which require customer interaction,
customer proximity, deep domain knowledge, and deep cultural knowledge. Thus,
15 The offshore landscape


Require- Archi-
ments tecture


Figure 1.6 Common division of onshore/offshore phases.

requirements gathering activities, early in the development cycle, are conducted onshore
because of the need to be close to customers; that is, to meet with them and talk to them
in their own language. At the end of the development cycle comes systems integration
(also labeled “deployment”), where the software pieces are sewn together; this is dif¬cult
to do from afar.
Two phases appear as both onshore and offshore in Figure 1.6: design and testing.
High-level design is often done onshore while lower-level design is offshored. Testing, a
largely tedious task, is offshored in part. Unit testing can easily be done offshore. Some
testing activities, such as systems testing, have remained onshore, because they are
better performed together with other integration/deployment tasks. Separately, for con-
trol reasons, managers keep later testing phases onshore in order to monitor quality.
Some important IT activities are not depicted in Figure 1.6: data center management
and a variety of managed services, such as network services and support. Generally,
these have not been offshored since they require some proximity. Furthermore, there
are business continuity risks in moving such services offshore.
The ¬nal differentiation between the two clusters is competitiveness. Companies
tend to keep “high-end” activities at home (onshore) to maintain their competitiveness.
These tasks are more likely to be creative, innovative, and research oriented, or they
require very broad knowledge and experience. For example, architecture (systems archi-
tecture or product architecture) ¬ts all of these criteria and is kept onshore as shown in
Figure 1.6.
Companies give these competitive activities many labels namely, core activities,
proprietary activities, the most sensitive activities, the leading product design, and the
company™s competitive edge. Most IT applications at end-user ¬rms (e.g. a bank) involve
few activities which are proprietary and therefore such companies are not hesitant to
offshore. The picture is different, at least in theory, for a software product company: its
software code is its “crown jewel.” Any company should carefully weigh allowing
16 The fundamentals

an outsider access to its crown jewels. Yet even among software product ¬rms that per-
form R&D there is signi¬cant offshoring. An estimated 5“15% of American software
product R&D is offshored, forecast to rise by 2007/2008 to 25“30%.15 And some of
the companies which are offshoring software product R&D are the largest US technol-
ogy ¬rms. Yet, this is a risk that they have presumably considered carefully. We return
to discuss this topic in Chapter 5, Offshore Strategy.

Quality, processes, and methodologies

Until the 1960s, Japan was known as a destination for cheap, low-quality
manufactured goods. “Made in Japan” was a derogatory term. Beginning in
the 1950s, the Japanese began to implement quality production processes from
abroad and re-invented their production culture. Within a relatively short
period, Japan became known as a source for high-quality manufacturing.

This is an example of history repeating itself. Until about 1990 India™s reputation was for
shoddy products. The Indian offshore providers recognized early that by attaining high-
quality development processes (CMM, ISO 9001, and Six Sigma) they could achieve
two important goals: they could overcome some of the dif¬culties of working over dis-
tance, and, perhaps more important for the nascent Indian industry, they could signal to
potential customers that they were world-class companies worthy of their business.
The Indian organizations™ success in this regard is remarkable. The very ¬rst organiza-
tion in the world to attain the highest-level software process maturity rating, the CMM
Level 5, was India™s Motorola unit in 1993. Since then many other Indian ¬rms have
adapted this standard. By 2001, 32 organizations with CMM Level 5 were in India. By
2003, there were over 65 Indian organizations that attained CMM Level 5 (including
both Indian ¬rms and foreign multinational subsidiaries), representing more than half
of all organizations in the world at that highest level. The outcomes of all these efforts
have been impressive: a 2003 survey among US offshore users found that 71% of the
users stated “that offshore suppliers delivered somewhat better- or much-better-quality
work” compared to their US-based counterparts.16
By the early 2000s, offshore units in nations that compete with India, namely China
and Russia, began to emulate the Indian sector™s successes in this area. Russia™s Luxoft
attained CMM Level 5 in 2003, while two Chinese organizations attained Level 5
by 2003.
CMM and its newer cousin CMM-I, both came out of the US Software Engineering
Institute to impose structured, standardized development processes that are repeatable,
planned, and optimized. The advantages of these process improvements are error rate
reductions and cost savings. Moreover when working across distance, these processes
17 The offshore landscape

reduce the communication dif¬culties by structuring the development process “ by
introducing standard approaches that reduce the need for explicit coordination.
Nevertheless, several issues need to be noted about the promise of structured
approaches in general, and CMM in particular. CMM cannot address many of the off-
shore challenges that were described earlier in this chapter. Furthermore, the ¬xation on
CMM Level 5 is misguided: CMM Level 3 is considered suf¬cient for most software
development activities (CMM Level 5 was designed to satisfy large American defense
contractors and NASA). Finally, the hoopla around CMM generated by the Indian suc-
cess has created an environment of exaggeration and fraud. A 2004 CIO magazine17
expos© documented this landscape: some offshore providers misrepresent their CMM
rating and others have not “renewed” their ratings in years since there is no requirement
for such renewals.

National differences in software abilities
When in a comfortable private setting, executive decision-makers ask the following
questions: Are the programmers in Country A better than the programmers in Country
B? Do the engineers of Country C have a better work ethics than those of Country D?
Are the ¬rms in Country E more sophisticated than those in Country F?
These are important questions. No one has answered them properly. And it is unlikely
that anyone will, in part because of the extreme political sensitivity of giving a country
a failing grade. Furthermore, comparative studies are likely to be fraught with sample
biases. Project outcomes are often mixed and depend on many factors including short-
comings of the client. We found an American software manager that set out to answer
the “which country is better for us” question on his own, using an interesting approach.
His small software ¬rm set out to contract an identical pilot project to three providers,
one each in India, China, and Russia. Once the pilot projects were complete the ¬rm
chose the winner. The case appears in Chapter 4.
An important study was conducted by Cusumano and colleagues18 using data col-
lected in 2001“2002. The study compared best practices of ¬rms in Europe, Japan,
USA, and India (most were technology ¬rms). The eleven best practices included: archi-
tecture speci¬cations, code generation, code reviews, sub-cycles, pair programming,
and daily builds. The researchers concluded that India™s stated strengths in processes
and best practices are correct, namely, that Indian ¬rms were combining disciplined
approaches such as architectural speci¬cation, code and design reviews, with more ¬‚ex-
ible approaches. The study also noted continued software strengths in Japan. Separately,
the study authors made an interesting observation in their conclusions, writing that “¦
no Indian or Japanese company has yet to make any real global mark in widely-
recognized software innovation, which has long been the provenance of US and a
few European software ¬rms.”
18 The fundamentals

The demand for offshore work

In the next two sections we examine the two sides of the offshoring equation: the
demand (answering the question: who are the customers?) and then later the supply
(answering the question: who are the providers?). The global context of demand and
supply is presented in Table 1.2.
On the demand side we begin with a few broad observations before looking at spe-
ci¬c geographic regions:
— Geography. The most aggressive offshore consumers are in the US. Within

Europe, the UK has been the most active in offshoring.
— Industry. Among the end-user industries, the most active in offshoring are ¬nancial

services (banks, investment ¬rms, and insurance) and technology ¬rms (software,
hardware, and telecommunications).21
— Company size. Companies that offshore are generally the larger ¬rms, with the

largest global corporations, such as GE, American Express, and British Telecom
having taken the lead. The vast majority of small- and medium-sized ¬rms (SMEs)
do not offshore, with the exception of technology ¬rms.
— Motivation. Cost savings has always been the dominant driver for offshoring in

both Europe and America, except for the short period in the late 1990s, when labor
Table 1.2 Selected ¬gures and estimates on market sizes

Data for 2003 Forecast for 2008

Global market of IT services 536 billion USD growing N/A
(Source: Gartner) at 6.2%

Global market of IT-enabled 405 billion USD, growing 680 billion USD
services at 8%
(Source: IDC)

Indian IT services providers Growth of 29% for the year, N/A
(Source: Gartner) though Indian providers represent
only 1.4% of global market

Foreign R&D subsidiaries India: 77 global software product N/A
¬rms.19 China: 223 technology

Indian R&D sourcing 1.3 billion USD 9.1 billion USD
(Source: Frost & Sullivan)

Global [offshore] sourcing 10 billion USD. Total savings 21 billion USD. Total
of software and services from offshoring by US savings from offshoring by
(Source: ITAA) corporations was 6.7 billion USD US corporations will be
31 billion USD
19 The offshore landscape

markets were very tight due to the technology boom, the Y2K remediation efforts,
and the euro currency conversion.

The largest market for offshoring is the US. This should not be surprising given that the
US has long maintained leadership in the software industry through its clusters of
innovation, such as Silicon Valley, its catalyst role on the internet, and its powerful
global corporations. The largest of these corporations, IBM, may qualify as the “Father”
of globalized software development. In the 1960s and 1970s, IBM, then the most
powerful computer ¬rm in the world, and always among the top 10 largest US corpo-
rations, had R&D centers in three countries with development centers in some addi-
tional European nations (see Figure 1.7). No company came close to this global network
for many decades.
In 2003, global sourcing of computer software and services was estimated at 10 billion
USD, which represents but a small portion of total US corporate spending on IT. Of
the 10 billion USD in global sourcing, the US purchases have generally represented
two-thirds. This ratio will probably remain steady for some years, though the amount
in dollars will continue to rise at double-digit rates.

Thomas J. Watson Research Center
(Westchester County, NY and Zurich Research Laboratory (Rueschlikon, Switzerland)
Cambridge, MA, USA) Established in 1956
Established in 1961

Almaden Research Center
Haifa Research Laboratory (Haifa, Israel)
(San Jose, CA, USA)
Established in 1972
Established in 1955

Figure 1.7 IBM™s early global network of R&D sites, circa 1970.
Source: IBM.
20 The fundamentals

Table 1.3 Selected US software ¬rms™ offshore activities

Cadence Cadence is the largest semiconductor design software ¬rm. The ¬rm opened an India
R&D center in 1987 where its staff reached 300 developers by 2004. It also had
development centers in Taiwan, China, and Russia22
Google In 2004, search engine company Google was viewed as one of the most innovative
American tech ¬rms and its public offering of stock was closely watched. Google
stated that it could afford to hire the best developers in the US, but chose to open
an R&D center in India to attract creative talent
I2 I2 develops logistics software for business customers. In 2004 the ¬rm had
1400 engineers outside the US, mostly in India, representing about half of the ¬rm™s
global employees. The Indian staff included about 180 staffers of Indian origin who
were previously working in the US and volunteered to go back to India23
Microsoft Microsoft has traditionally been cautious about dispersion of its R&D, with nearly
all activities at its Redmond headquarters. Its four foreign centers, India, China,
Israel, and England, were set up in 1990s. Growth since 2000 has been primarily in
India and China. The ¬rm had roughly 300 employees in its Hyderabad (India)
locations scheduled to double within 2 years
Oracle Oracle began offshoring in 1990. By 2003, its Indian centers grew to 3000 developers
with a stated goal of doubling to 6000. Oracle also performs offshore R&D in Ireland
and China

The offshore spending is disproportionately concentrated in larger ¬rms, particularly
in ¬nancial services. But even among the largest ¬rms, only a minority is actively off-
shoring. Estimates regarding offshoring from the largest US ¬rms, the Fortune 1000, sum-
marized in Table 1.1, indicate that in 2004 only about 10% of these US ¬rms were past
the experimental stage of offshoring in which more than 10% of their budgets were
devoted to offshoring.
The landscape is quite different for American technology ¬rms. All the top 20 US
technology ¬rms perform at least some offshore software work. Furthermore, at all sizes
(small, medium, and large) high-tech ¬rms that are offshoring are much more prevalent
than for non-tech ¬rms. Table 1.3 presents a sampling of some US technology ¬rms™
offshoring activities.

Europe has been slower than the US in offshoring IT, even though the cost advantages

<< . .

( 36)

. . >>

Copyright Design by: Sunlight webdesign