For the last 15 years, the overall trend in IT has been towards outsourcing -- but that trend is apparently beginning to reverse.
The Sloan Management Review (Summer 2006, p. 12) notes that according to a recent Deloitte Consulting LLP study, 70 % of large organizations studied "had negative experiences with outsourcing … [and] 64 % of the organizations … have brought at least some functions back in-house because of their negative experiences."
Moreover, the same article notes that IT finds outsourcing "increasingly dangerous." Other reasons for moving back in-house include the "lack of flexibility and velocity ... to handle complex tasks directly related to core business practices," problems with quickly-outdated contracts, and increased regulation such as Sarbanes-Oxley that makes monitoring the outsourcer much more difficult (and whose penalties do not fall on the outsourcer).
What implications does the new insourcing trend have on the mainframe? In this article, we examine the strategies for a less outsourced organization. As an example, we'll use the development offshoring market that has been at the core of outsourcing in the last five years.
Mainframe development outsourcing
Development outsourcing (outsourcing development of new applications or upgrade and maintenance of existing ones) is about improving the effectiveness of development. Therefore, it is in a sense about programmer productivity. That is, outsourcing is not about producing more lines of Assembler code per programmer, but producing more lines of code per dollar spent.
On a purely cost basis, offshore outsourced development is highly attractive. Despite factors such as infrastructure and communications costs, and a rapid increase in Indian wages, it is estimated that the cost of an Indian programmer continues to be 55-75 % of the American programmer. Meanwhile, a new pool of low-cost programmers is increasingly available in Eastern Europe and China.
Yet, problems with outsourced development, especially offshore outsourced development, persist and have not been completely overcome. In some cases, these include language barriers (programming is subtly English-biased), remote and geographically distributed communications barriers, the need to pass in-house knowledge to the outsourcer, and the loss of scarce in-house mainframe programming and system skills.
Communications barriers between IT and the service provider remain a key problem with remote or offshore outsourced development. Communications are typically in a "limited bandwidth," via phone or data transmission, not face to face or over an intranet. Offshore sites such as Ireland and India have at least a five-hour time difference to contend with. Thus, communication often tends to crowd toward the narrow "overlap windows." Communication across companies adds an extra layer of constraint and misunderstanding of corporate development procedures.
Offshore development sites have made great strides in overcoming many of these communications difficulties in recent years. Examples include techniques such as "round-the-world handoff" programming, which leaps from time zone to time zone as the globe turns; collaborative software, which allows remote programmers to share a task; "nearshore" development (e.g., in Canada); and project management over the Web. However, it remains true that most offshore outsourced development for the mainframe or other platforms involves creating a detailed specification at the start of the project and shipping it to the offshore site. This is done while minimizing communications (and changes) until the end of the project.
Where offshore development makes sense
The following project conditions are most favorable to offshore outsourced development today:
Slow change in project or product specifications.
Relatively simple programs that are more easily and more rapidly specified.
Projects that involve less knowledge that is proprietary to the contracting company.
By the same logic, offshore development is least suited to the following development projects:
Rapid change in specifications.
Complex environments with complicated specifications or for which no specification is available.
Projects involving poorly specified existing code, unspecified "business rules," or poorly specified proprietary interfaces to proprietary databases and applications.
Much of today's mainframe development involves upgrading existing corporate applications for maintenance or incorporating new technology, including connecting existing applications. It also involves, to a lesser extent, the creation of new applications. Table 1 shows what the "fit" is between offshore development and these tasks.
Table 1: Development tasks and offshore services
| Development Type |
Characteristics |
Fit With Offshore In-House Development |
| Existing application maintenance |
Newer well documented; older poorly documented, proprietary | Newer – good fit; Older – poor fit |
| Existing application upgrade |
Newer easier to upgrade/well documented, but may be fast change;
older poorly documented, proprietary, complex |
Newer – some good fit, some bad
Older – poor fit |
| New IT application |
For competitive advantage: leverages proprietary information, medium to fast change, often complex;
Not business critical: medium to fast change, well documented, typically simpler |
Competitive advantage: poor to moderate fit
Not business-critical: poor to moderate fit |
Source: Infostructure Associates, August 2006
Moving mainframe development back in-house
The same cost problems that led to offshore development outsourcing in the first place will remain unless IT improves its mainframe development processes. This is not simply a matter of "learning from the outsourcer," or hiring the outsourcer's programmers away.
Mainframe development processes need to be more clearly aimed at reducing maintenance costs over the long term via application modernization strategies and to focus new applications and features on competitive advantage while speeding the development process.
For the mainframe shop, insourcing should improve flexibility and velocity in key comparative-advantage and regulatory initiatives, reduce IT risks, and improve corporate security. But a company should only do so if it learns lessons from the outsourcer and adopts better processes and strategies.
Enterprises should also keep in mind that mainframe technologies (especially software) are increasingly merging with those of other platforms in areas such as service-oriented architectures (SOA); cross-platform operating systems, infrastructure, and applications (Linux/DB2/SAP); and middleware (WebSphere). The "re-insourced" mainframe can now take advantage of IT efforts on other platforms and vice versa.
T.S. Eliot once wrote that the end of all our striving "is to return to where we began/and recognize it for the first time." The "less outsourced mainframe" returns IT to where it began -- and offers the opportunity to leverage the mainframe far more effectively than ever before.
