All servers in the production environment run Sun Microsystems Solaris UNIX operating system. The web server is NES (Netscape Enterprise Server) with the addition of JRun engine for running Java servlets. The database server is Oracle. The CORBA application server is IONA OrbixWeb. CORBA clients use an internally developed API (Application Programming Interface) and wrapper Java classes developed on top of OrbixWeb.
The challenge in this project was to develop software in a distributed fashion without any physical presence at the production site, while still adhering to the very strict bank's security rules.
First, per the bank's development protocol, software developers do not have direct physical access to the production system. Instead, the developed software is handed over to the production system staff for final testing and installation on the production system.
Second, for security reasons, the already developed software cannot be taken out of the bank's premises for installation on a remote development system. It means that copies of the database and the applications running on the CORBA server were not available at the development site. Instead, stubs had to be developed to emulate the behavior of CORBA and database servers.
The entire software described in this article was developed on a single Windows NT Workstation. The CORBA server was one that comes with the JDK (Java Development Kit). The database was Microsoft Access. The web server was Apache with the JServ engine for running Java servlets. Software was developed using Oracle JDeveloper IDE (Integrated Development Environment). Obviously, the development and the production environments were very different, which was one of the development challenges.
The only contact between the development and the production sites was over the phone and via e-mail, thus software was developed solely in a telecommuting fashion. Once the database and CORBA stubs were set-up on the development site, and a basic skeleton of the application was set-up on the production site, it was easy to gradually build the application on the development site and test it on the production site. Software was shipped via e-mail in the form of compiled JAR (Java Archive) files and static text, HTML (Hyper-Text Markup Language), and graphic files.
Throughout the rest of this article, we will describe some of the tricks of trade used to overcome the development challenges.
CORBA standard was, at least in theory, developed to standardize invocation of remote applications in networks. However, in practice, this is far from reality. In theory, the development of code which invokes remote, already developed applications, involves the following steps:
1. Use the remote application's IDL (Interface Definition Language) specification, and an IDL compiler to generate API stub code for invoking remote applications in the desired programming language (Java, C, C, C++).
2. Develop code for initiating the ORB (Object Request Broker) within the calling application under development.
3. Develop code for invoking remote applications from within the calling application under development.
However, in practice, there are a number of problems:
* CORBA applications developed in different programming languages may have problems talking to each other even when the development tools and the underlying libraries are produced by the same vendor.
* Java API specification is developed to standardize API and IDL stubs of all Java applications, thus maximize code portability. However, vendors of CORBA development tools like IONA did not adhere to this standard, so software developed using JDK and it's IDL compiler and CORBA name server cannot run using IONA's CORBA name server.
* Even different CORBA development tools of the same vendor, like IONA's OrbixWeb and Orbix 2000, are not mutually compatible, and require different application code.
Fortunately, the differences and incompatibilities in the application code apply mostly to a relatively small portion of the ORB initiation code. For that reason, it was possible to develop code using JDK CORBA environment and port it to the OrbixWeb production environment as follows:
1. Use the JDK IDL compiler to compile IDL specification and generate Java stubs for the development environment.
2. Develop and test the application using the ORB initiation code appropriate for the JDK environment.
3. Use the OrbixWeb IDL compiler to compile IDL specification and generate Java stubs for the OrbixWeb production environment.
4. Replace the ORB initiation code with the code needed for the OrbixWeb production environment.
Once this porting procedure is established, delivery of code modification is very efficient with a little help of code building scripts.
The other problem with the development of CORBA code was unavailability of the original CORBA application server. This problem was solved by developing a simple stub application server that emulates responses of the real application server. The stub server loads test data from a text file and upon request passes it to the CORBA client, i.e., to the requesting servlet in this case.
Portability of JDBC (Java Database Connection) code is significantly better than CORBA related code. As long as database operations are restricted to standard SQL (Structured Query Language) and free of triggers and stored procedures, developed Java code runs on virtually any database. Porting to a different database type performed by simply specifying a different database source and driver in a database configuration textual file such as:
JDBCDriver = sun.jdbc.odbc.JdbcOdbcDriver
JDBCConnectionURL = jdbc:odbc:DbSource
The above two lines define database source named DbSource defined in the Windows ODBC (Open Database Connection) manager and the Sun Microsystems' JDBC-ODBC bridge database driver. By modifying the two lines in the database configuration file, one can switch from, e.g., Microsoft Access database at the development site to Oracle database at the production site. As a matter of fact, this approach is so convenient that the author used it in many other Java projects that involved databases. Microsoft Access allows quick prototyping and modification. Once the database design is finalized, the database can be ported to Oracle using an Oracle database porting tool. In addition, this approach allows the use of a laptop computer for demonstration of work in progress at a customer's site.
This approach was used in the project described in this article to quickly create the database stub that emulates behavior of the database at the production site. Since the application used a small subset of tables and fields in the actual database, replication of their structure at the development site was quick and easy.
When it comes to database Internet applications, another trick worth mentioning is the use of database connection pools. A typical servlet-based Internet application that uses a database involves three steps when a servlet is invoked: connecting to the database, accessing data, and disconnecting from the database. Connecting to the database is a time-consuming operation. For that reason, pools of pre-established database connections are maintained. Each servlet maintains a connection pool which consists of a configurable number of pre-established database connections. Instead of waiting for the connection to be established, a database request takes an already established connection from the pool, uses it, and later returns it back to the pool for further reuse. The use of connection pools significantly improves the application's performance. Oracle's JDeveloper IDE comes with a library that implements a connection pool manager. However, the author uses one of many connection pool implementations available for download from the Internet.
Nowadays in North America, finding a developer from India to back up the software you are using is probably as easy as finding "Made in China" on the tag of the jacket you are wearing. But, have you ever thought that one day China—the mighty "hard" goods producer—will become much stronger on the "soft" side?
The past few years have seen China's tremendous efforts on promoting its software development capability—and it has gained a strong hold over one specific area: the embedded software sector. In fact, embedded software accounts 2/3 of the $10 billion software export that China accomplished in 2007 [1]. Moreover, China's outsourcing business is doing exceptionally well in Japan. In 2007, over 65% of the country's software outsourcing workload was sent to China. [2] Based on these achievements, it's clear that China certainly wants to increase its share in more software sectors and in a wider geographic range. The question is "Should North America accept what China wants to offer in the software outsourcing business?" Before answering this question, let's take a look at some major risks and opportunities of outsourcing to China.
Managing Risks
There are many risks related to outsourcing. In this article, we will look at only a few of the greater ones. Since North American clients have built strong partnerships with Indian outsourcing vendors, comparisons between India and China might be more efficient in addressing major risk factors.
Vendor Availability
As the global software and business process outsourcing center, India has established a stable outsourcing ecosystem with a number of qualified outsourcing vendors. In the list of The 2008 Global Outsourcing 100, produced by the International Association of Outsourcing Professionals [3] , China has less prominence than India. One may then pose the question, "Even if I want to send my software projects to China, how can I locate the right vendors if there are not many available?"
The truth is that China does have a lot of software developers—but most of them are small and have low presence on the global stage. According to Liu Jiren, the leader of Neusoft (one of the largest software outsourcing providers in China), the software industry in China and India are about the same size in terms of total revenue, but their revenue structures are very different. About 90% of China's software revenue comes from the domestic market, but India only receives about 10%–20% from its home market [4] . This means that China has strong software development forces. Chinese software developers just haven't done outsourcing as much as their Indian counterparts.
Quality of Service
By working with North American clients on numerous development projects for a long period of time, many Indian software developers are able to reach satisfactory service levels. But, are Chinese software outsourcing vendors able to achieve the same level of functional completeness, an absence of bugs, proper documentation, on-time delivery, and so on in order to deliver quality services? It is hard to answer without really trying out any Chinese outsourcers, but evidences show that Chinese developers are growing quickly.
Chinese software developers now believe that third party capability maturity model integration (CMMI) is the way to reach the global market. During the past few years, China has made tremendous progress and has seen more CMMI certified software developers than ever before. In less than 3 years since 2006, China has had more than 360 companies certified with CMMI (level 3 or higher) [5] . While being CMMI certified doesn't mean that the adopters will automatically receive overseas orders, the certification does play an important role in both process improvement and marketing.
Copyright Protection
Since outsourcing vendors will have certain access to clients' intellectual property in order to develop software, copyright protection should be enforced on both the input side (clients' patents, development methodology, application programming interfaces [APIs], and so on) and the output side (the finished software). In China, copyright regulations have been enacted but the enforcement is yet to be more robust. Will the situation be better? It seems likely.
The improvement of copyright protection is expected to be a long process, but it seems to be on the right track. For example, it is very easy to find unauthorized video content on various Chinese web sites, but this summer Beijing did a great job on protecting authoritative Olympic Games videos. The success shows clearly the Chinese government's gesture to tackle copyright issues, and it also indicates that copyright protection is technically and politically feasible in China. The lawsuits that some Chinese dot-com companies recently faced due to violating online copyright regulations are also encouraging signs for copyright holders.
Experience Dealing with Chinese Vendors
The truth is, many North American clients are not as skillful as their Japanese counterparts when dealing with Chinese software outsourcing vendors. However, it is also true that Chinese vendors feel less confident dealing with North American clients. The beginning stage of the partnership is like a blind date—both parties have to act carefully due to their lack of information. But eventually some partners may get along well with each other and achieve positive results.
Decades ago, when North America needed to find Chinese manufacturers, the situation was substantially worse than what it is now. Since China has opened its doors to the world for the last 30 years or so, communication barriers have been significantly reduced. And in the IT industry, China now has more people with work or study experience within the North American setting. Also, it is not too difficult for a North American client to hire people who have competencies that help bridge the western and eastern ways.
Identifying Opportunities
With the majority of companies going to India for software outsourcing, there isn't much space for organizations to gain a competitive edge. Exploring opportunities in other regions that are not yet popular may lead to different risk exposures, but it is also rewarding if you can operate properly.
Cost Savings China's gross domestic product (GDP) per capita is more than double than that of India [6], but software programmers in China don't earn as much as their counterparts in India. In the article Dealing with Cultural Nuances in Offshore Outsourcing Relationships, Kathleen Goolsby writes that "IT salaries can be 30 times higher in India than in China" [7] . Although the number seems somewhat high to me—based my understanding of the Chinese labor market—I do agree that there is a good cost savings opportunity in China today.
Price convergence may occur sooner or later since China is one of the countries that have recently recorded high salary increases (7-8% in year 2006 and 2007) [8] . This means North American clients should become early movers in order to take the full advantage of lower labor cost.
Domestic Market Demands
Based on the revenue volume and structure mentioned previously, China's domestic software market is about six times greater than India's. Hence, China is a place where North American software vendors cannot only develop cheaper software, but where they can also sell more products. Electronic data systems (EDS), an HP company focusing on global business and technology services, is promoting its Best Shore® Outsourcing approach [9]. One of the main ideas behind this approach is to take the advantages of proximity between development and delivery. Following this idea, it makes a lot of sense to develop software in China and sell it to the Chinese market.
An additional benefit of building partnerships with Chinese software vendors through outsourcing is that some major Chinese software outsourcing vendors are also significant players in business application integration and implementation in China. SAP seems to understand this well. In May 2006, SAP announced it would invest 10 million Euros ($12.8 million USD) to buy a nearly 3 percent stake in outsourcer Neusoft. "The agreement will help integrate SAP's technology and Neusoft's national network across China", said Henning Kagermann, president and CEO of SAP [10]. If you are not ready to invest in Chinese market leaders, like SAP did, one alternative could be outsourcing to them to show your willingness to build up partnerships.
Building Your Strategic Plan for Moving to China
The above analysis shows that due to the recent development of Chinese software industry, risks can be managed and China has become a feasible outsourcing destination for more North American clients, especially when you need to think about further cost reduction during the economic crunch or you want to expand your business reach to the world's most populated country.
In the manufacturing sector, building a vendor portfolio is a common practice to mitigate risks associated with vendor reliance. A North American manufacturer usually has a few major subcontractors and a lot of minor ones. From cost and quality control perspectives, it might not make sense to keep subcontractors that produce small quantities of goods at a higher cost per unit. However, one day, a smaller supplier might become a bigger and better supplier than the current major ones—given the efforts by both your company and the small subcontractor. The same idea is applicable to the software industry, and opening your door to China means you have a bigger pool to select your minor vendors, if you are not ready to make them your major outsourcers at the moment.
Moving to China also makes sense if we consider the complementary factors between China and India. Although the two neighboring countries have some major similarities—both are highly populated and are in the development phase, there are also some significant differences (e.g., social system, culture, economic structure, etc.). By building a vendor portfolio that includes India, China, and other countries (such as Ireland and the Ukraine), North American software vendors will be able to offset risk factors and achieve stable product or project delivery.
If you are not familiar with specific Chinese software outsourcing vendors, I've included a few tips that might be helpful for you to expand your outsourcing footprint in China.
* Try out a few pilot projects before you send out important ones.
* Outsource certain parts of the development processes (such as coding and testing) instead of the whole package. Japanese companies use this approach.
* Contact the Chinese government at different levels to seek sourcing supports. Sometimes, the services they offer are very generous.
* CMMI certificate increases creditability, but don't use it as the only criterion for vendor selection.
* If you find significant language mistakes in a vendor's marketing materials, it might be an early warning sign that you shouldn't proceed further.
* Don't be scared if the price is too low. It might be a scam or it could be that the vendor wants a project without profit in order to build its overseas business.
* Use the Outsourcing Evaluation Center to evaluate vendors. There is a good selection of Chinese vendors and their number keeps growing.
The challenge in this project was to develop software in a distributed fashion without any physical presence at the production site, while still adhering to the very strict bank's security rules.
First, per the bank's development protocol, software developers do not have direct physical access to the production system. Instead, the developed software is handed over to the production system staff for final testing and installation on the production system.
Second, for security reasons, the already developed software cannot be taken out of the bank's premises for installation on a remote development system. It means that copies of the database and the applications running on the CORBA server were not available at the development site. Instead, stubs had to be developed to emulate the behavior of CORBA and database servers.
The entire software described in this article was developed on a single Windows NT Workstation. The CORBA server was one that comes with the JDK (Java Development Kit). The database was Microsoft Access. The web server was Apache with the JServ engine for running Java servlets. Software was developed using Oracle JDeveloper IDE (Integrated Development Environment). Obviously, the development and the production environments were very different, which was one of the development challenges.
The only contact between the development and the production sites was over the phone and via e-mail, thus software was developed solely in a telecommuting fashion. Once the database and CORBA stubs were set-up on the development site, and a basic skeleton of the application was set-up on the production site, it was easy to gradually build the application on the development site and test it on the production site. Software was shipped via e-mail in the form of compiled JAR (Java Archive) files and static text, HTML (Hyper-Text Markup Language), and graphic files.
Throughout the rest of this article, we will describe some of the tricks of trade used to overcome the development challenges.
CORBA standard was, at least in theory, developed to standardize invocation of remote applications in networks. However, in practice, this is far from reality. In theory, the development of code which invokes remote, already developed applications, involves the following steps:
1. Use the remote application's IDL (Interface Definition Language) specification, and an IDL compiler to generate API stub code for invoking remote applications in the desired programming language (Java, C, C, C++).
2. Develop code for initiating the ORB (Object Request Broker) within the calling application under development.
3. Develop code for invoking remote applications from within the calling application under development.
However, in practice, there are a number of problems:
* CORBA applications developed in different programming languages may have problems talking to each other even when the development tools and the underlying libraries are produced by the same vendor.
* Java API specification is developed to standardize API and IDL stubs of all Java applications, thus maximize code portability. However, vendors of CORBA development tools like IONA did not adhere to this standard, so software developed using JDK and it's IDL compiler and CORBA name server cannot run using IONA's CORBA name server.
* Even different CORBA development tools of the same vendor, like IONA's OrbixWeb and Orbix 2000, are not mutually compatible, and require different application code.
Fortunately, the differences and incompatibilities in the application code apply mostly to a relatively small portion of the ORB initiation code. For that reason, it was possible to develop code using JDK CORBA environment and port it to the OrbixWeb production environment as follows:
1. Use the JDK IDL compiler to compile IDL specification and generate Java stubs for the development environment.
2. Develop and test the application using the ORB initiation code appropriate for the JDK environment.
3. Use the OrbixWeb IDL compiler to compile IDL specification and generate Java stubs for the OrbixWeb production environment.
4. Replace the ORB initiation code with the code needed for the OrbixWeb production environment.
Once this porting procedure is established, delivery of code modification is very efficient with a little help of code building scripts.
The other problem with the development of CORBA code was unavailability of the original CORBA application server. This problem was solved by developing a simple stub application server that emulates responses of the real application server. The stub server loads test data from a text file and upon request passes it to the CORBA client, i.e., to the requesting servlet in this case.
Portability of JDBC (Java Database Connection) code is significantly better than CORBA related code. As long as database operations are restricted to standard SQL (Structured Query Language) and free of triggers and stored procedures, developed Java code runs on virtually any database. Porting to a different database type performed by simply specifying a different database source and driver in a database configuration textual file such as:
JDBCDriver = sun.jdbc.odbc.JdbcOdbcDriver
JDBCConnectionURL = jdbc:odbc:DbSource
The above two lines define database source named DbSource defined in the Windows ODBC (Open Database Connection) manager and the Sun Microsystems' JDBC-ODBC bridge database driver. By modifying the two lines in the database configuration file, one can switch from, e.g., Microsoft Access database at the development site to Oracle database at the production site. As a matter of fact, this approach is so convenient that the author used it in many other Java projects that involved databases. Microsoft Access allows quick prototyping and modification. Once the database design is finalized, the database can be ported to Oracle using an Oracle database porting tool. In addition, this approach allows the use of a laptop computer for demonstration of work in progress at a customer's site.
This approach was used in the project described in this article to quickly create the database stub that emulates behavior of the database at the production site. Since the application used a small subset of tables and fields in the actual database, replication of their structure at the development site was quick and easy.
When it comes to database Internet applications, another trick worth mentioning is the use of database connection pools. A typical servlet-based Internet application that uses a database involves three steps when a servlet is invoked: connecting to the database, accessing data, and disconnecting from the database. Connecting to the database is a time-consuming operation. For that reason, pools of pre-established database connections are maintained. Each servlet maintains a connection pool which consists of a configurable number of pre-established database connections. Instead of waiting for the connection to be established, a database request takes an already established connection from the pool, uses it, and later returns it back to the pool for further reuse. The use of connection pools significantly improves the application's performance. Oracle's JDeveloper IDE comes with a library that implements a connection pool manager. However, the author uses one of many connection pool implementations available for download from the Internet.
Nowadays in North America, finding a developer from India to back up the software you are using is probably as easy as finding "Made in China" on the tag of the jacket you are wearing. But, have you ever thought that one day China—the mighty "hard" goods producer—will become much stronger on the "soft" side?
The past few years have seen China's tremendous efforts on promoting its software development capability—and it has gained a strong hold over one specific area: the embedded software sector. In fact, embedded software accounts 2/3 of the $10 billion software export that China accomplished in 2007 [1]. Moreover, China's outsourcing business is doing exceptionally well in Japan. In 2007, over 65% of the country's software outsourcing workload was sent to China. [2] Based on these achievements, it's clear that China certainly wants to increase its share in more software sectors and in a wider geographic range. The question is "Should North America accept what China wants to offer in the software outsourcing business?" Before answering this question, let's take a look at some major risks and opportunities of outsourcing to China.
Managing Risks
There are many risks related to outsourcing. In this article, we will look at only a few of the greater ones. Since North American clients have built strong partnerships with Indian outsourcing vendors, comparisons between India and China might be more efficient in addressing major risk factors.
Vendor Availability
As the global software and business process outsourcing center, India has established a stable outsourcing ecosystem with a number of qualified outsourcing vendors. In the list of The 2008 Global Outsourcing 100, produced by the International Association of Outsourcing Professionals [3] , China has less prominence than India. One may then pose the question, "Even if I want to send my software projects to China, how can I locate the right vendors if there are not many available?"
The truth is that China does have a lot of software developers—but most of them are small and have low presence on the global stage. According to Liu Jiren, the leader of Neusoft (one of the largest software outsourcing providers in China), the software industry in China and India are about the same size in terms of total revenue, but their revenue structures are very different. About 90% of China's software revenue comes from the domestic market, but India only receives about 10%–20% from its home market [4] . This means that China has strong software development forces. Chinese software developers just haven't done outsourcing as much as their Indian counterparts.
Quality of Service
By working with North American clients on numerous development projects for a long period of time, many Indian software developers are able to reach satisfactory service levels. But, are Chinese software outsourcing vendors able to achieve the same level of functional completeness, an absence of bugs, proper documentation, on-time delivery, and so on in order to deliver quality services? It is hard to answer without really trying out any Chinese outsourcers, but evidences show that Chinese developers are growing quickly.
Chinese software developers now believe that third party capability maturity model integration (CMMI) is the way to reach the global market. During the past few years, China has made tremendous progress and has seen more CMMI certified software developers than ever before. In less than 3 years since 2006, China has had more than 360 companies certified with CMMI (level 3 or higher) [5] . While being CMMI certified doesn't mean that the adopters will automatically receive overseas orders, the certification does play an important role in both process improvement and marketing.
Copyright Protection
Since outsourcing vendors will have certain access to clients' intellectual property in order to develop software, copyright protection should be enforced on both the input side (clients' patents, development methodology, application programming interfaces [APIs], and so on) and the output side (the finished software). In China, copyright regulations have been enacted but the enforcement is yet to be more robust. Will the situation be better? It seems likely.
The improvement of copyright protection is expected to be a long process, but it seems to be on the right track. For example, it is very easy to find unauthorized video content on various Chinese web sites, but this summer Beijing did a great job on protecting authoritative Olympic Games videos. The success shows clearly the Chinese government's gesture to tackle copyright issues, and it also indicates that copyright protection is technically and politically feasible in China. The lawsuits that some Chinese dot-com companies recently faced due to violating online copyright regulations are also encouraging signs for copyright holders.
Experience Dealing with Chinese Vendors
The truth is, many North American clients are not as skillful as their Japanese counterparts when dealing with Chinese software outsourcing vendors. However, it is also true that Chinese vendors feel less confident dealing with North American clients. The beginning stage of the partnership is like a blind date—both parties have to act carefully due to their lack of information. But eventually some partners may get along well with each other and achieve positive results.
Decades ago, when North America needed to find Chinese manufacturers, the situation was substantially worse than what it is now. Since China has opened its doors to the world for the last 30 years or so, communication barriers have been significantly reduced. And in the IT industry, China now has more people with work or study experience within the North American setting. Also, it is not too difficult for a North American client to hire people who have competencies that help bridge the western and eastern ways.
Identifying Opportunities
With the majority of companies going to India for software outsourcing, there isn't much space for organizations to gain a competitive edge. Exploring opportunities in other regions that are not yet popular may lead to different risk exposures, but it is also rewarding if you can operate properly.
Cost Savings China's gross domestic product (GDP) per capita is more than double than that of India [6], but software programmers in China don't earn as much as their counterparts in India. In the article Dealing with Cultural Nuances in Offshore Outsourcing Relationships, Kathleen Goolsby writes that "IT salaries can be 30 times higher in India than in China" [7] . Although the number seems somewhat high to me—based my understanding of the Chinese labor market—I do agree that there is a good cost savings opportunity in China today.
Price convergence may occur sooner or later since China is one of the countries that have recently recorded high salary increases (7-8% in year 2006 and 2007) [8] . This means North American clients should become early movers in order to take the full advantage of lower labor cost.
Domestic Market Demands
Based on the revenue volume and structure mentioned previously, China's domestic software market is about six times greater than India's. Hence, China is a place where North American software vendors cannot only develop cheaper software, but where they can also sell more products. Electronic data systems (EDS), an HP company focusing on global business and technology services, is promoting its Best Shore® Outsourcing approach [9]. One of the main ideas behind this approach is to take the advantages of proximity between development and delivery. Following this idea, it makes a lot of sense to develop software in China and sell it to the Chinese market.
An additional benefit of building partnerships with Chinese software vendors through outsourcing is that some major Chinese software outsourcing vendors are also significant players in business application integration and implementation in China. SAP seems to understand this well. In May 2006, SAP announced it would invest 10 million Euros ($12.8 million USD) to buy a nearly 3 percent stake in outsourcer Neusoft. "The agreement will help integrate SAP's technology and Neusoft's national network across China", said Henning Kagermann, president and CEO of SAP [10]. If you are not ready to invest in Chinese market leaders, like SAP did, one alternative could be outsourcing to them to show your willingness to build up partnerships.
Building Your Strategic Plan for Moving to China
The above analysis shows that due to the recent development of Chinese software industry, risks can be managed and China has become a feasible outsourcing destination for more North American clients, especially when you need to think about further cost reduction during the economic crunch or you want to expand your business reach to the world's most populated country.
In the manufacturing sector, building a vendor portfolio is a common practice to mitigate risks associated with vendor reliance. A North American manufacturer usually has a few major subcontractors and a lot of minor ones. From cost and quality control perspectives, it might not make sense to keep subcontractors that produce small quantities of goods at a higher cost per unit. However, one day, a smaller supplier might become a bigger and better supplier than the current major ones—given the efforts by both your company and the small subcontractor. The same idea is applicable to the software industry, and opening your door to China means you have a bigger pool to select your minor vendors, if you are not ready to make them your major outsourcers at the moment.
Moving to China also makes sense if we consider the complementary factors between China and India. Although the two neighboring countries have some major similarities—both are highly populated and are in the development phase, there are also some significant differences (e.g., social system, culture, economic structure, etc.). By building a vendor portfolio that includes India, China, and other countries (such as Ireland and the Ukraine), North American software vendors will be able to offset risk factors and achieve stable product or project delivery.
If you are not familiar with specific Chinese software outsourcing vendors, I've included a few tips that might be helpful for you to expand your outsourcing footprint in China.
* Try out a few pilot projects before you send out important ones.
* Outsource certain parts of the development processes (such as coding and testing) instead of the whole package. Japanese companies use this approach.
* Contact the Chinese government at different levels to seek sourcing supports. Sometimes, the services they offer are very generous.
* CMMI certificate increases creditability, but don't use it as the only criterion for vendor selection.
* If you find significant language mistakes in a vendor's marketing materials, it might be an early warning sign that you shouldn't proceed further.
* Don't be scared if the price is too low. It might be a scam or it could be that the vendor wants a project without profit in order to build its overseas business.
* Use the Outsourcing Evaluation Center to evaluate vendors. There is a good selection of Chinese vendors and their number keeps growing.
0 comments:
Post a Comment