An Enterprise Perspective of Software Offshoring

Transcription

1 An Enterprise Perspective of Software Offshoring Wing. uen University of Wisconsin Oshkosh Oshkosh, WI Abstract - Enterprises engaged in software offshoring are reticent about their involvements. This paper presents a view of software offshoring from an enterprise perspective based on the author s extensive globalization experience. It addresses the wide spread fear of decline of software development in developed countries due to offshoring by presenting a case study of a large scale software development offshored to China. Aspects include motivation, benefits, risks, decision making, requirements, architecture, process management, project management, and security. The case study shows that offshoring helped to enhance market, increase capacity, access to special skills while most of the software engineering roles were kept in the developed countries. The reader may also get a glimpse of the software skills valued by an enterprise. The paper concludes with what worked and what did not work in the case study. With the declining Computer Science and IT enrollment, educators are concerned about the future of the software industry and inquire about what can be done. Globalizing enterprises that supposedly gain the most are reticent about their involvement. This paper presents an enterprise view of offshoring derived from the author s extensive experience in establishing subsidiaries and joint ventures on hardware and software development overseas. It analyzes the offshore structures of software development in global enterprises and decision making process via a case study of offshoring a large scale software development to China. The case study illustrates that increased capacity, access to specialized skills, cost reduction, and quality in offshoring may all be achieved with due diligence and most of the higher skilled software jobs are kept onshore The paper also discusses what worked and what did not work. Index Terms globalization, offshore insourcing, offshore outsourcing, software engineering education. INTRODUCTION Considerable debates surround offshoring and in particular, offshoring of software among the major stakeholders: the media, outsourcing providers, globalizing enterprises, and educators. The U.S. media have raised wide-spread alarms by attributing job losses of Information Technology (IT) workers to the explosive growth of offshore outsourcing of IT-enabled services and application software development to developing countries. The outsourcing providers and consultants, on the other hand, project double-digit annual growth and emphasize the outsourcing benefits such as low cost, access to technical skills, staffing flexibility, and quality. owever, current literature [7][9] show that outsourced jobs are mostly IT-enabled services and application developments which are restricted to non-core and commodity development and testing roles considered to be lower skilled jobs: Modifiers/Extenders and Supporter/Tenders[6]. Study [7] indicates that the Indian outsourcing projects remain low value and low risk while some providers are striving to work on high value, high risk projects of consulting, design and product development but without much success. In addition, two recent survey studies [1][2] reported that anticipated benefits of outsourcing such as cost reduction, expanded capabilities, and increased flexibility often failed to materialize; and that growing numbers of companies were dissatisfied and had abnormally terminated outsourcing relationships due to poor performance, changed in strategic direction, or moved back in-house. TERMINOOGY Terminology in the literature and media concerning offshoring and outsourcing is inconsistent. We will use the term offshoring in this paper as transferring some of an enterprise s operations such as manufacturing, services, or software development to another country, especially a country overseas. There are two categories of offshoring relationships: offshore insourcing i.e. setting up in-house centers overseas and offshore outsourcing i.e. contracting an operation or service to an external company overseas. The term enterprise denotes the organization that sends projects offshore and the term provider the company that supplies the offshore service. The term software engineer refers to a software practitioner, who works on any aspect of software including customer front-end interface, requirements, architecture, design, coding, unit and integration testing, customer delivery and acceptance, process engineering, project management, and product engineering. OFFSORE REATIONSIP OPTIONS A spectrum of offshore relationships is available. At the heart of the offshore decisions is the selection of the relationship that will maximize income and minimize cost and risks. Enterprises usually prefer to sell directly into a country with little or no local value added. owever, localization requirements and economic factors such as higher duties on finished products than subassemblies, parts and components and cost differentials in labor, material, and transportation may preclude direct sales. S2C-17

2 The next decision is between licensing and the other alternatives. The deciding factors are profit level and Intellectual Property (IP) risks. icensing has the advantage of guaranteeing some level of profit, often with little or no cost or risk of capital losses; however, its disadvantages are often less profit than a subsidiary or joint venture and the risk of establishing a competitor via the transferred technology. The remaining offshore insourcing relationships are: Subsidiary established by the enterprise itself or through Build-Operate-Transfer, or Merger and Acquisition approaches. The enterprise has full control of the subsidiary. Joint Venture (JV) is a popular mechanism for expanding business overseas by partnering with a foreign partner who can usually provide market and in-country expertise. The two parties share the profits and responsibilities. The establishment and management of the JV will be most difficult. An insourcing relationship may achieve localization via research and development, software development or foreign exchange balancing. Offshore outsourcing provides a new alternative in offshore strategies, not in enhancing revenue and market but in enabling the enterprise to reduce cost and resolve productivity problems. Outsourcing may be achieved by: Direct contracting a project with an Outsourcing Service Provider (OSP) Engaging a provider to provide dedicated facilities and staff in a longer term relationship, referred to as a captive Offshore Development Center (ODC). OFFSORE OUTSOURCING VERSUS INSOURCING An outsourcing provider typically sends a small team to be stationed at the engaged enterprise s site for interfacing with the enterprise on requirements, integration, and system testing while most of the work is done by an offshore team on coding and unit testing [3]. The role of OSP or captive ODC is one of contract development according to specified requirements. An insourcing facility, as an overseas extension of the enterprise, is usually assigned a wider range of work. Centralized processes for software development are usually most efficient. owever, with the increasing complexity of software products and short development schedules, an organization usually cannot do it all. A software engineer must use the available resources wisely to adopt a process that produces high productivity, high quality and low cost. There are benefits, risks, and limitations associated with each relationship. We will compare insourcing and outsourcing in general with respect to benefits and risks, without considering the refined options in each, as shown in Table 1. The decision maker may assign weights to the benefits and risks to determine the appropriate path. TABE 1. BEFITS-RISK COMPARISON INSOURCING VERSUS OUTSOURCING. Insource Outsource Development Subsidiary/JV OSP/ODC Revenue benefits/risks Market entry/presence no everages/incentives no In-country customer support NA Cost benefits/risks Cost reduction Risk: Initial investment yes no Risk: idden costs NA Risk: Other offshore costs Risk: Employee issues Productivity benefits/risks Increased capacity Solving talent shortage problem Freeing up internal resources Offshoring non-core activities Risk: Institutional knowledge loss Risk: IP rights/ security Risk: Control of offshored software Range of SW development Resource flexibility Management complexity Quality Benefits/Risks Motivation to improve process Requirements flexibility Other Risks Employee issues/backlash Provider underperformance risks Geopolitical risks I. Revenue Benefits/Risks M to varies / yes some to M M M more An insource facility, viewed as a foreign investor, is capable of contributing towards enhancing in-country sales, enjoy the government incentives, leverage political and economic benefits, as well as supporting the local or regional customers. II. Cost benefits/risks Cost reduction due to low costs in labor, manufacturing, and transportation is common in both insourcing and outsourcing options. Just the wage level of a developing country does not guarantee cost reduction. The insourcing enterprise incurs capital risk of startup costs on infrastructure and personnel services while the outsourcing provider already has the development facilities in place. owever, outsourcing costs may be hidden as the winning provider may low-bid and re-price later. The enterprise must factor in other costs, S2C-18

3 whether outsourcing or insourcing, such as reorganization costs, layoffs, requirements support, acceptance support, project management, integration, travel, knowledge and technology transfer, documentation etc. III. Productivity benefits/risks An example of solving talent shortage problem is Nortel [5] pioneering to outsource telephone switching software development to Indian software houses in the early 1990s due to difficulties in hiring scientists and engineers in North America. Short lifecycle of software products [6] puts pressure on enterprises to free up high powered software engineers from maintenance of sunset products to new developments. An enterprise should carefully assess whether an operation is core or non-core. abeling a software function as non-core implies that it is not critical to the mission of the enterprise. Usually it is hardly true unless it is a commodity process. If the enterprise subsequently regrets and brings the operation back in-house, the staff knowledgeable in the area may have been re-assigned or displaced already. The enterprise must then depend on the provider to re-educate the organization. Conversely, bringing a mislabeled operation from a subsidiary back to the home base is relatively simple. IV. Structural risks to outsourcing The three risks: institutional knowledge loss, IP protection/security, and control of offshored software are structural obstacles to outsourcing that cannot be fully mitigated. IP protection/security may be the most serious risk in that subcontracting may potentially create a competitor for the enterprise due to the knowledge transfer. Similarly once a software project is contracted out, the enterprise loses direct control of development. On the other hand, the insourcing enterprise has better process control. A consequence of these structural risks is that enterprises may outsource only those software components that are generic and peripheral. V. Resource Flexibility One of outsourcing s value propositions is that it provides flexible resources. As an enterprise s resource needs ebb and flow, the provider s supply can be adjusted accordingly. As the outsourcing business grows rapidly with a high rate of staff turnover, providers may reach the flexibility limit. Moreover, the outsourcing business model is based on economy of scale. owever, most of the IT services and application developments, let alone complex software development, are custom tailored thus invalidating the economy of scale. In addition the outsourcing talent pool may not have the domain knowledge of specific industries. On the other hand, it is feasible for a subsidiary of a large enterprise, for example GE Capital Services India[5], to achieve the economy of scale by supporting multiple divisions with its specialized operation. VI. Management Complexity Management of offshoring relationships is intrinsically complex due to the distributed development, geographical, time-zone, and cultural differences. In addition, outsourcing contracts impose constraint between the enterprise and the provider. The most difficult on-going relationship to manage is that of a JV since all parties interests have to be satisfied. VII. Motivation to improve process While insourcing gives the advantages of better process control, protection of Intelligent Property rights, domain knowledge retention, and security, its quality process tends to be exported from the enterprise and becomes entrenched. Conversely, outsourcing has the inherent incentives to improve its processes and is exposed to the best practices among its clientele. VIII. Requirement flexibility It is imperative for the distributed software development to have stable requirements and stable processes to be successful. It is natural that the outsourcing provider will be reluctant to entertain late changes since the payment is dependent on the performance. In situations in which the end-user demands late changes, insourcing can be more flexible. IX. Other Risks Employee issues and backlash may happen in both cases but tend to be more manageable for insourcing. Provider underperformances and geopolitical risks such as political instability, power shortages, strikes, infrastructure problems, are shared by both camps. X. Summary of Offshore Decision Making Model The offshore decision making may be summarized in a series of tests: Will the offshore relationship satisfy the goals? For example, free up internal resources, enhance the revenue in the foreign market by providing market information, taking advantage of incentives and leverages, or supporting customers. Will the cost be reasonable? Will the IP rights be protected? Will the institutional knowledge be kept? Will the offshored software be controllable? Is a quality improvement process in place for the distributed organization? If a feasibility study provides affirmative answers to all questions, the offshore project is approvable. Outsourcing usually is unable to generate in-country revenue and keep institutional knowledge. In special cases such as the development of a commodity process that is commonly S2C-19

4 known, outsourcing may be considered given reasonable costs and a quality provider. A cost benefit analysis will be discussed in the following section on an offshore case study. AN OFFSORE CASE STUDY The offshore case study is a network management system of Synchronous Digital ierarchy (SD) optical network, based on the International Telecommunication Union (ITU) standard for communicating digital information using lasers or light emitting diodes over optical fibers. An optical network is physically composed of optical fibers and Network Elements (), which are Add-Drop Multiplexers, lightwave terminals, digital Cross Connects etc. SD specifies Synchronous Transport Modules (STM) and rates: STM-1 (155 megabits per second), STM-4 (622 Mbps), STM-16 (2.5 gigabits per second), STM-64 (10 Gbps), and STM-256 (40 Gbps). A customer needs a network management system to handle the day-to-day operations. Multiple s may be managed by a single Element Management System (EMS) and multiple EMS s by a Network Management System (NMS) according to the ITU-T TMN (Telecommunications Management Network) Framework standard as shown in Figure 1. This enterprise under study, headquartered in the U.S., had developed, via subsidiaries in U.K., Netherlands, France, and Germany, and deployed nine different s with speeds up to 2.5 gigabits per seconds and releases of NMS and EMS. New and customer requested network management features remained to be developed for the existing s and higher speed s under development. I. The Challenge Amid heavy demands for larger and faster optical systems around the late 1990 s, the enterprise faced several challenges in the product development of network management: 1. Enhance Asian market positions by providing better support to the customers in Asia, especially the Chinese customers who had been procuring optical networks with STM-4 and STM Expand development capacity by developing new network management features for the existing s in Asia and relieve development resources in Europe to develop the STM-64 and faster network elements and the associated network management systems. 3. A shortage of software developers was keenly felt [4]. Furthermore it was extremely difficult to find engineers conversant in SD and TMN in U.S. and even, to a less degree, in Europe. Offshore development in another country became a serious consideration. II. Feasibility Study An offshore relationship in China would definitely enhance the market position with close proximity to the customers and enjoy lower tariff and incentives. Protection of intellectual property rights and institutional knowledge retention were important factors since there was ongoing profit and development for the product. Insourcing was more favorable since the enterprise wanted to preclude the possibility of inadvertently educating an outsourcing vendor to become a future competitor. Additionally employees in an offshore insourcing facility are under U.S. law. egend: WS Workstation X Cross Connect SD Network Element EMS Multiplex Element evel Management System NMS Network ayer Management System FIGURE 1. Networked NMS and EMS managing an SD network Forming a joint venture with a customer or local partners capable of expanding the market was a possibility. owever, joint ventures have the disadvantage of lengthy (usually years) negotiations in order to satisfy all parties in the partnership. The remaining alternative was to establish a subsidiary. Thanks to the highly specialized Chinese university system, some graduates especially those from the universities of post and telecommunications do have strong background in optical communications and network management technologies. Graduates with training in inux, C/C++, Java, OSI model, and databases were commonplace. A quality process had to be set up initially on training of TMN and SD; existing product and development processes; technology transfer; and subsequently on continued process improvement. Training on third party products included Common Object Request Broker Architecture (CORBA), Marben OSI Stack, Informix and Oracle databases. S2C-20 WS Wide Area Network WS EMS NMS EMS X X

5 III. Cost Benefit Analysis Companies surveyed in [1] complained about outsourcing providers lack of cost transparency. In this insourcing example, the enterprise had the responsibility and control to research the cost, which can be obtained from government agencies, auditing firms, legal firms, financial institutions, and other enterprises in similar business. The cost-benefit analysis was a modified project financial analysis. It contained models (what will be produced), volume (how many will be produced), and integration strategy (what products will be integrated and when) to generate a 10- year revenue projection and the associated production costs. The cost list, at minimum, contained personnel head count by category, the technology transfer upbringing estimates (training weeks; in-country support weeks; enterprise s support weeks; documentation cost; training of subsidiary personnel in home countries; expatriate cost in China; fixed assets required for production, development platforms, load building systems, test labs, infrastructure, telecommunication cost; and overhead costs). After in-depth and iterative analysis of the costs, benefits, and risks, the project decided on creating a subsidiary in China and offshore development from U.K. to China. We will present next what to offshore to China and the roles of the other sites. IV. Role Allocation China subsidiary roles: The China subsidiary was assigned to develop enhancements to configuration management, account management, fault management, performance management, and security management for s deployed in Asia. Configuration management includes provisioning of equipment and user channels. These enhancements give the user a cost-effective deployment scheme, reduce provisioning time, improve performance quality, increase service quality, and reduce operating expense. U.S. roles: Most of the software engineering roles were kept in the U.S. with limited responsibilities delegated to the subsidiaries or joint ventures. Customer Interface and Product Engineering roles were centralized in the U.S. Initially U.S. maintained customer contact with Asian customers on new business discussions, writing requirements, and customer delivery incurring considerable cost of communication and travels. As the China site grew in expertise, it took over the responsibilities of front-end interface to Asian customers, requirement specification, development, and customer acceptance. Proximity to the customer improved the customer relationship considerably. The parent enterprise was still responsible for the worldwide requirement engineering and prioritization of requirements in the software life cycle. Product Family Planning: Product engineers planned the evolution of the product by introducing s and network management features in phases based on market and competitor trends. It is essential to maximize reuse for the network management systems to support two standards. Since the product is a family of network management systems controlling various s, the product engineer worked closely with the system architect so that the product plan was reflected in the system architecture to maximize reuse among s. System Architecture and Product Family Architecture roles were centralized in the U.S. with responsibilities of modularity, extensibility, and reusability. The EMS is a product family, required to manage a growing list of various s including other vendors s. As new s were introduced, the architecture enabled reuse of common properties and only the incremental or different features need be developed. The class/subclass concept of object-oriented design was expedient here. Similarly new functionalities in future releases may reuse existing classes. The EMS satisfies the requirement to manage network elements from different vendors through class inheritance. U.K. roles: Core functions such as architecture, database definition and administration, change management system, load building, and integration test were kept in U.K. The latter three were to avoid duplication of expensive facilities and protect IP. As a part of the training process, both teams would develop jointly two releases over six months together. Roles common to the distributed development sites: Project Management: Distributed teams usually create unnecessary delays [8]. The project managers in the three sites need to drive the following key issues: Planning of Cost and Schedule for the complete product and deliveries. Promotion of effective communication via project meetings; tools for change management system, load building, and integration; phone and video conferencing Shared context: aving some Chinese engineers being trained at the U.K. and U.S. sites and short term expatriates from U.S. and U.K. guiding the China site initially helped the three teams to get acquainted with one another and the development processes. This shared context expedited problem solution across continents when future needs arise. A communication tool on the expertise and current responsibilities of engineers at both sides was also useful. Classroom and lab training were carried out on site. Security: access to the software base and intranet by Chinese employees was restricted. Employee Issues: Employee resistance in home countries was reduced considerably by the management s announcement of the product evolution and development plans of asking the U.K. and U.S. employees to focus on new products. This move helped to boost the morale and avoid rumors. S2C-21

6 Process engineering: This case study illustrates the process engineering of utilizing global resources and expertise from distributed teams in a collaboration mode. As the China subsidiary demonstrated success, the distributed organization as a whole needed to be readjusted to gain the full benefits of the offshoring engagement. These included transferring the customer interface, requirements engineering, and more project management responsibilities to the China team as well as transitioning more U.K. engineers to new development. Quality Process: The process engineer must specify clearly the output expected, acceptance criteria, and completion milestones to all development centers and across all the releases. The quality process should also enable repeatable processes to drive predictability and reliability of the deliveries. WAT WORKED Development capacity was expanded by transitioning development resources in U.K. in stages to newer products and by establishing a network management software development center in China The China subsidiary was able to provide better support to customers in Asia and China. A demanding Japanese customer was highly appreciative of the quality of a delivery. Outstanding graduates with M.S. and Ph.D. from first-tier universities were recruited including some conversant in SD and TMN. The salary was competitive compared with other in-country companies or foreign companies. It was the challenging project that attracted the employees. Cost reduction was achieved with the average headcount cost ratio for U.S., U.K. and China as roughly 3:2:1. The software development was insourced mainly because the enterprise wanted to retain institutional knowledge and protect its competitive edge and IT rights. A dedicated E1 carrier (2.048 Mbps), though a major operating expense, helped speed the transmission between China and U.K. especially for load building. Teamwork was fostered by transitioning U.K. employees to new challenging project and training about half of the Chinese employees in U.K. and sending short-term expatriates to China. For security, some of the key functions such as database, architecture and load building were kept in U.K. and process, product family planning, system architecture, marketing, sales channels, product family architecture, customer interface, technologies, and product engineering were kept in the U.S. Access to the intranet from China was restricted. The software was also protected by a source control system located in U.K. The Chinese employees tended to work long hours partially to interface with U.S. and U.K. and partially out of work ethics. One or two U.K. employees were on call to ensure continuous operation of the load building system. WAT DID NOT WORK Chinese universities have a narrow recruitment window, typically around late November and early December, for companies to interview students graduating in the coming year. In the first year, we missed the deadline of recruitment reservations with some of our target universities. Better communication between upper management and engineers in the home countries would help to alleviate fears of job loss due to offshoring. The Chinese team could be more fully utilized if decisions on which project to be transitioned were made sooner. Mismatch of culture. Chinese employees taking a habitual nap during lunch hours might be perceived as slothful to the eye of western visitors though they often work hours a day without overtime pay. SUMMARY While distributed software development via offshoring is suboptimal, it is often necessary due to other considerations such as market enhancement, lack of technical skills and schedule pressures. Increased capacity, cost reduction, access to specialized skills, quality and IP protection in offshoring are still achievable with due diligence. REFERENCES [1] Deloitte Calling a Change to the Outsourcing Market, April 2005, Deloitte Consulting P. [2] DiamondCluster 2005 Global IT Outsourcing Study, DiamondCluster International Inc [3] Gopalakrishnan, S., Kochilar, V., Yegneshwar, S. The Offshore Model for Software Development: The Infosys Experience, Proceedings of the 1996 ACM SIGCPR/SIGMIS Conference, pp [4] ITAA elp Wanted: The IT Workforce Gap at the Dawn of a New Century, Information Technology Association of America, Arlington, VA, [5] Bajpai, N., Sachs, J., Arora, R. and Khurana,. (2004) Global Services Sourcing: Issues of Cost and Quality, CGSD Working Paper No. 16, Center for Globalization and Sustainable Development, Earth Institute, Columbia University, June 2004, pp [6] Freeman, P. and Aspray, W. (1999) The Supply of Information Technology Workers in the United States, Computing Research Association (CRA), Figure 2-4, pp ; pp [7] Khan, N., Currie, W.., Weerakkody, V. and Desai, B. Evaluating Offshore IT Outsourcing in India: Supplier and Customer Scenarios, Proceedings of the 36th awaii International Conference on System Sciences (ICSS 03), [8] erbsleb, J.D. & Mockus, A. An Empirical Study of Speed and Communication in Globally-Distributed Software Development, IEEE Transactions on Software Engineering, 29, 3, 2003, pp [9] Wired Magazine US IT Jobs Sent Offshore, Feb 2004, Wired Magazine. S2C-22