In almost any virtualization project, you will run into the need of converting physical machines to virtual machines. Both VMWare and Microsoft provide solutions for that. Here is the link that gives the details of the vmware converter. And here is the link for the Microsoft Virtual Server Migration Toolkit and another one that details VMM (Virtual Machine Manager) over here.

We have used the vmware one quite a few times and it is pretty easy to use and very robust as well. It does not require any downtime either. Haven’t had any experience with the MSFT toolkit so will post on it once we play with it in our labs.

Transparent Data Encryption (TDE) is another new feature in SQL Server 2008 which implements database level encryption. SQL Server 2005 already had the column level encryption and with TDE we can now prevent scenarios where the backups or the physical media (tape drive) which contains sensitive data is stolen and then someone reads it by restoring the backups or re-attaching the database files. This encryption is done at the page level. The data that is read off the disk is decrypted when reading the data and encrypted when writing it to the disk. The encryption is done using a database encryption key also called as DEK which is protected using a certificate that is stored on the master database of the instance.

One thing to note (and something that we had not realized when initially working with TDE) is that if any user database on an instance uses TDE, then the tempdb system database will also be encrypted. We have not done benchmarks yet to see the performance penalty of this but wanted to point this out so that you are aware of it. The column level encryption which was introduced in SQL Server 2005 offers more granularity but TDE can be useful as well since not only does it protect your back-ups, it allows the ability to search encrypted data.

Let’s create a new database and then a table in it that has credit card information, SSN information etc.:

create database decipher_test
go
use decipher_test
go
create table dbo.test_encryption
(
first_name nvarchar(10),
last_name nvarchar(10),
ssn nvarchar(10),
credit_card_nbr nvarchar(16)
);

set nocount on
go
insert into dbo.test_encryption values (’Joe’, ‘Snyder’, ‘234423456′, ‘1234567890123456′);

Now, let’s take a backup of this database. After taking the back-up, if we open it up using Notepad, we can easily read this data - see the image below:

Please do note that we searched for “J o e” since this is unicode. The whole point of doing this exercise was to show that the native backups are readable. One can also easily restore this database on another instance and take all the SSN and Credit Card related information. There are third party tools out there that allow for the encryption as well for the backups but that is a discussion for another post. When this functionality is already built in SQL Server 2008, why should we invest in another third party tool.

So, how do we go about using TDE? We first need to create a database master key:

USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ’supersecret!Nahhhh’;
GO

Next, we will create a certificate to protect the DEK:

CREATE CERTIFICATE DCTEST WITH SUBJECT = ‘DEK DCTEST CERTIFICATE’;
GO

And now, we can set the encryption for the DECIPHER_TEST database by creating the DEK:

USE DECIPHER_TEST
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE DCTEST;
GO

We used 128 bit AES as our encryption algorithm but you can choose from others as well. Those are listed in BOL and you can also access them in the online version over here.

The last step is to bring it on! (Sorry - turn it on!):

ALTER DATABASE DECIPHER_TEST SET ENCRYPTION ON;

And now, if you try to take a backup and open it up with notepad, you will see that the data is not readable. This time, let us try to restore this encrypted database. If I try to restore this on another instance on which the certificate does not exist, it will fail with error message:

“Cannot find server certificate with thumbprint…”

In order to be able to restore that backup on another instance, we will need to backup the certificate as well:

USE MASTER
GO
BACKUP CERTIFICATE DCTEST
TO FILE = ‘E:\DCTEST.cer’
WITH PRIVATE KEY (FILE = ‘E:\DCTEST_Key.pvk’ ,
ENCRYPTION BY PASSWORD = ’supersecret!Nahhhh’ )
GO

The next step is to then copy the certificate to the other instance, create the master encryption key just like we did above (with a different password):

USE MASTER
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘gotit!Nahhhh’;
GO

And now, we can simply import the certificate that we copied over:

USE MASTER
GO
CREATE CERTIFICATE DCTEST
FROM FILE = ‘E:\DCTEST.cer’
WITH PRIVATE KEY (FILE = ‘E:\DCTEST_Key.pvk’ ,
DECRYPTION BY PASSWORD = ’supersecret!Nahhhh’ );

Instead of “TO FILE”, we used “FROM FILE” and instead of “ENCRYPTION”, we used “DECRYPTION” in order for the import to go through. After the certificate has been created on the other instance, the restore will go through fine and we can look at the data the same was as on the source system.

There is one more feature along the same lines that needs to be mentioned here. Besides using a certificate in the master database to protect the DEK, we can also use what is called as the EKM (Extensible Key Management) feature. EKM allows us to store the keys used to encrypt the data separately as compared to the data that we are protecting. This is made possible by exposing the encryption functionality to the hardware vendors that address EKM using Hardware Security Modules (HSM). More and more acronyms, eh! We will discuss EKM and HSM in a future post.

On this blog, we have covered how to export data out from the database and different ways to import data into the database tables from different sources. We have covered that for all the three major RDBMS that we cover on this blog: Oracle, DB2 LUW and MS SQL Server. Sometimes, these tasks are adhoc in nature and sometimes, they need to be more repeatable in nature. In this post, we will cover how to create a SSIS package for exporting the data out to a text file in the case of SQL Server. If you are new to SSIS, see our basics sections here and here. And the details of the Execute SQL task were then covered in a series of posts that you can access here , here and here.

In order to make the process repeatable, one should create a SSIS package for the data exports that one needs to do frequently.  The task we are going to accomplish in this example is to send the information pertaining to customers and the orders placed by the customers. For this purpose we are going to make use of the AdventureWorks Database in SQL Server 2005. First we are going to write a query to retrieve the information required from the database. Typically this query can also be replaced by a database view to retrieve the information from the database. That way, even if the view logic changes, your code in the SSIS package does not need to change.  And if there is a need to have procedural logic in place, then you can use a stored procedure or a UDF.  Here is the query which we are going to use to retrieve the required information and export it to a text file.  Typically, there will be filter criterias and other conditions associated with such queries – the query in this post is just to illustrate the concept.

SELECT

c.CustomerID,Title, FirstName, MiddleName, LastName, c.AccountNumber, C.CustomerType, pa.AddressLine1,
City, StateProvinceCode, CountryRegionCode, PostalCode, SalesOrderNumber, so.AccountNumber as SalesAccountNo,
OrderDate, DueDate, ShipDate, SubTotal, TaxAmt,
Freight, TotalDue

FROM Sales.Customer c
INNER JOIN Sales.CustomerAddress a on a.CustomerID = c. CustomerID
INNER JOIN Person.Contact pc on pc.ContactID = c.CustomerID
INNER JOIN Person.Address pa on pa.AddressID = a. AddressID
INNER JOIN Person.StateProvince sp on sp.StateProvinceID = pa.StateProvinceID
INNER JOIN Sales.SalesOrderHeader so on so.CustomerID = c.CustomerID

ORDER BY CUSTOMERID

The ideal scenario would be sending the order and customer information to the client for the orders placed on the current day.  For this post’s example, entire data in the database is exported to a text file and the text file would be named as ‘CustomerOrders_<mmddyyyy_HHMMSS>’. Since we are dealing with the flow of data in this example our package would require a Data Flow Task.

Creation of the SSIS Package:

Open up the SSIS designer by navigating to

Start => All Programs => Microsoft Sql Server 2005 => SQL Server Business Intelligence Development Studio.

This will open up the SSIS designer to create the SSIS package. Create the new project in the SSIS designer.

1. Creation of a new variable:

To create a new variable right click on the control flow pane and click on the Variables option. This will show the Variables window on the left. Create a new variable ‘FileLocation’ at the package level. We are going to make use of this variable to specify the location of the destination text file. We are going to make use of the location C:\SSIS in our example. The following image shows the creation of the variable.

2. Exporting the Data into the text using Data Flow Task:

Our next task is to define the data flow task which exports the data from the database into the text file pointed by the location in the variable FileLocation. Drag and drop the Data Flow Task from the Control Flow Tool Box into the Control Flow Designer. Double clicking on it will automatically take us to the Data Flow Tab of the SSIS Designer.

3.1 Configuring the Source in the Data Flow task:

On the Data Flow tab, drag and drop the “OLE DB Source” from the Data Flow Sources in the Data Flow Tool Box. Double click on the task which opens up the editor for the OLE DB Source. Create the new OLE DB source connection manager by clicking on “New” button on the OLE DB Source Editor. The creation of the connection managers has been dealt with in detail in the earlier posts. The data access mode option in the OLE DB source editor gives us various options of retrieving the data from the database. The image below shows the various options available to retrieve the data from the database.

The various options available are:

1. Table or View:

This option allows us to choose a database table from which we are going to export the data. This option is useful only when we are retrieving the data from single table or view only.

2. Table Name or View Name Variable:

This option enables us to pass the table or view name as a variable into the SSIS Package. Again this option is useful only when we are retrieving the data from single table or view only.

3. Sql Command:

This option allows us to specify the SQL Command (even a stored procedure) to retrieve the data from the database. This is the most viable option for us to use. Since we are retrieving the data from multiple tables inside the database, we are going to make use of this option.

4. Sql Command from Variable:

This option is very similar to the above one except that we can pass the sql command through a variable.

Choose Sql Command option in the Data Access Mode in the OLE DB Source Editor. It will display the space to write the sql command. Copy the sql command provided earlier in this post and paste it in here. One can use the Build Query option also to build the query. Clicking this opens a GUI to define the tables to retrieve the data from. The image below shows the configured OLE DB Source Transform in SSIS. Click OK to return to the data flow designer pane.

3.2 Configuring the Destination in the Data Flow task:

The next step in our task is to configure the destination for the data to be exported. On the Data Flow tab, drag and drop the “Flat File Destination” from the Data Flow Destinations in the Data Flow Tool Box. Drag the path (green arrow) from the OLE DB Source and join to the Flat File source . Double click on the task which opens up the editor for the Flat File Destination.

Click on New to create the New Flat File Destination Connection Manager. It will open up a dialog which asks us to select if the destination data is delimited or if the data is of fixed filed length. In our example, we will choose the Delimited option.

The image below shows the configuration of connection manager of Flat File Destination.

Click on OK and SSIS will open up the GUI for configuring the connection manager for the Flat File Destination. Rename the Connection Manager Name if required and for the File Name Option, click browse and give the destination file name. For the purpose of our example, we are using the file at C:\SSIS\orders.txt. The following image shows the configuration of Flat File Connection Manager.

Click on Open to go back to the connection Manager.

We have an option to choose the delimiter for the header row in this General Page. Choose the New Line delimiter ({CR}/{LF}) option for our example. Check the ‘Column names in the first row’ if the column names are required in the first row. In this example we are checking this option since we require the column names in the output flat file.

The following image shows the General Page of the Flat File Connection Manager.

Open up the Columns Page on the Left hand side. Here we can choose the row and the column delimiter for the text file. For our example, choose the New Line as the row delimiter and the Tab{T} as the column delimiter. Click OK to go back to the Flat File Destination.

The following image shows the Columns page of the Flat File Connection Manager.

Navigate to the Mappings page on the Flat File Destination Editor and map the source columns to the destination columns. The following image shows the Source and Destination Column Mappings.

The following image shows the Data Flow task after the configuration of the source and the destination.

The following image shows the entire package for exporting the data in the database to the text file.

Execute the package by hitting F5. The executables will turn green indication the successful execution of the package. We can to go the location C:\SSIS and see that the flat file orders.txt is indeed created with the retrieved data from the database.

Now we fulfilled part of our task of exporting the data from the database to the text file. But the issue here is the name of the text file is static. Every time we run this package will overwrite the destination text file which is not what we want. Ideally, we would like to create the text file with the name CustomerOrders_<mmddyyyy_HHMMSS> or something similar to it. This means that we have to create the file name dynamically.

To do this let us go back to the control flow task and add the Script Task to our package. The configuration of the Script Task has been discussed in the earlier posts. In the script task editor, in the Script Page specify the ReadWriteVariables as FileLocation. We are going to make use of this variable to generate the full file name of our destination file. Open up the Script editor by clicking on the Design Script button on the Script Task Editor. This will open up the visual studio where we write the code to generate the file name. Copy and paste the following code to generate the new file name for our destination file based on the format described earlier.

Dts.Variables(“User::FileLocation”).Value = Dts.Variables(“User::FileLocation”).Value.ToString + “\CustomerOrders_” + CStr(Format(Now(), “MMddyyyy_hhmmss”))

This code is going to append the file name generated using the current date and time to the File Location pointed by our variable FileLocation. In this way we can also control the location in which the destination file is stored by just changing the variable value. The variables are very powerful piece of SSIS architecture. They are used to alter the properties of the package at run time.

Our next step is to tell the flat file connection manager to point to this file which we generated in the earlier step. As discussed in the earlier post, in order to dynamically alter the package at run time we have to make use of the expressions page of the SSIS executable.

In our example, we have to open up the Expressions editor for the Flat File Connection Manager. To do this right click on the Flat File Connection Manager and click on the Properties option in the menu. This will open up the properties window for the connection manager. In the properties window click on the ellipse (… ) in the Expressions. This will open the Expression Editor for the connection manager. The following image shows this process.

Select the Connection String Option in the Property of the Editor and click on the ellipse of the property. This will open up the Expression Builder to edit the property value. In the Expression Builder, drag and drop the variable FileLocation. Since the FileLocation variable contains the entire file path and file name of the destination file, the connection manager now will point to that location and file. The image below shows the expression builder for the connection manager.

Click OK and go back to the Control Flow pane. This completes our SSIS package which will export the data from the AdventureWorks database to the text file which is named according our naming convention. Now execute the package by hitting F5. Now we see that the flat file with the required name is generated with the data populated from our AdventureWorks database. The following screen shot shows the successful execution of the SSIS package. Note that we changed the name of the Executables to some meaningful names rather than leaving them at default name what SSIS gives.

In this post we discussed the need of the data flow task and also looked at the configuration of the Flat File Destination and OLE DB Source. We also discussed the export of the data in the text file from the database by naming the text file dynamically based on the current date and time. In the upcoming posts we are going to look at the export of the data from any OLE DB source to other destinations like excel files.

It was an interesting trip down the memory lane last night when we had a company meeting and were discussing code names for one of our products.  The code names for SQL Server releases came up and we thought we would post it on the blog to see how many people recognize them:

MSFT SQL Server Release     Project Code Name
SQL Server 2008                          Katmai
SQL Server 2005                          Yukon
SQL Server 2000 64 bit                Liberty
SQL Server 2000 32 bit                Shiloh
SQL Server 7.0                             Sphinx
SQL Server 6.5                             Hydra
SQL Server 6.0                             SQL95

Here is a simple SQL to track the information on the login accounts (Windows as well as SQL Server accounts):

select
name as login_name,
type_desc as login_type,
LOGINPROPERTY(name, ‘PasswordLastSetTime’) as Pswd_last_Set,
LOGINPROPERTY(name, ‘IsLocked’) as Locked_Account,
LOGINPROPERTY(name, ‘IsExpired’) as Expired_Login,
LOGINPROPERTY(name, ‘IsMustChange’) as Must_Change_On_Login,
LOGINPROPERTY(name, ‘HistoryLength’) as Account_Tracked_For,
LOGINPROPERTY(name, ‘LockoutTime’) as Date_Account_Locked_Out
from sys.server_principals
where type in (’S', ‘U’)
order by type

It uses the function LOGINPROPERTY() and lists out the different login names, their type and then selective properties that you are interested in tracking.  For SOX compliance as well as SAS70 requirements, it is good to have this SQL run every now and then in order to collect the information.  Also, there could be alerts set up based on the data set that is returned in order to alert the admin about expired/locked accounts etc.

In SQL Server, one way to look for the instances that one can connect is to simply run:

osql -L or sqlcmd -L

which will list out all the instances on the network that you can look at. You can also look at this through the GUI as shown below:

However, when doing this I noticed that one of the servers that I was looking for was not available in this list. I knew the IP address of the box and it was a default instance so I was able to connect through fine using the credentials but it set me thinking why would that particular instance not be available in the list. Then, I terminal serve’d into that box and noticed using the server configuration manager that we can chose not to expose the name of the instance if we do not want to. In the image below:

You can see that, the the “Hide Instance” property was set to Yes. Once that was changed to “No”, I was able to see the instance in the browse list as well as using osql -L. This, however tells us that if we want, this is yet another way to secure a SQL Server instance on the network.

We were planning a get together with some of our friends and other community members in our sub-division and were thinking about some games to keep everyone interested and occupied and one of the suggestions was to do a lottery at the end of it and award prizes - so, tickets were issued and we wrote our own random number generator for the lottery system. If you look into our blog posts, we have posted similar solutions in the past by using a CTE and generating a table of sequential numbers as well as random numbers and have covered the generation of random numbers quite extensively in some of the posts. This solution was very much similar to those with a combination from both those posts. Here is how the SQL portion of that code looked like (used a SQL Server Solution for this one). In this post, we use the same type of CTE solution as we had used in another post here.

with
N1 (n) AS (SELECT 1 UNION ALL SELECT 1),
N2 (n) AS (SELECT 1 FROM N1 AS X, N1 AS Y),
N3 (n) AS (SELECT 1 FROM N2 AS X, N2 AS Y),
N4 (n) AS (SELECT 1 FROM N3 AS X, N3 AS Y),
Number AS (SELECT TOP (1000) ROW_NUMBER() OVER(ORDER BY (SELECT 1)) AS X FROM N4 order by X),
Option_Val AS (SELECT TOP (5) X FROM NUMBER ORDER by NEWID())
SELECT stuff((select ‘,’ + CAST(X AS VARCHAR(10)) AS [text()]
from option_val
order by x
for xml path(”)
), 1, 1, ”) as Lottery_Numbers;

And if you run this SQL code, you will see separate set of 5 numbers which will be pulled each time. This was used using an application front end to provide a good look and feel and a “real” application interface to the end users - it was a fun activity. We made it a bit simpler - if anyone had 3 of those numbers, they got the first prize, if they had two of those numbers, that was the second prize. Had a couple of draws and then gave that application to the kids who had fun pressing the button and magically seeing different numbers popping up on the screen

This is one topic on which I hold a slightly different opinion from my colleagues. I have seen in every shop that I have been to that they clear out the cache prior to doing another benchmark run - whether they are using Oracle or SQL Server.  In SQL Server, one could use the DBCC commands to flush out the cache - DBCC FREEPROCCACHE would do that for you.  It is granular enough to allow you to even remove a specific plan if you provide it with a plan_handle or a sql_handle.  What this command does is that it clears out the plan cache and say you have a stored procedure that you are benchmarking, it would cause it to recompile since there is nothing in the cache.  Some people while doing benchmarking do this for every iteration of the benchmark in order to get “real world” numbers.  Ask yourself, do you clear out the cache in your production system as well every day?  Plan re-use and changing of the plans as one provides different input values and as one puts on the load on the system and increases up the data volume is what (IMHO) needs to be tracked rather than trying to clear out the cache each time to make a VP happy

Other forms of such DBCC commands are DBCC FREESESSIONCACHE and DBCC FREESYSTEMCACHE.   You can look up more information on the syntax and their usage in BOL.

In Oracle, prior to Oracle 10g, in Oracle 9i, one could use the “alter tablespace offline/online” command to flush the buffer cache of the blocks that pertain to that tablespace.  In Oracle 10g and 11g, there is an alter system command to flush out the cache:

alter system flush buffer_cache;

Benchmarks should reflect reality and unless your benchmark consists of a single query where you want to not account for what is in the cache, I don’t see any reason for using these commands in a benchmark.  In a real world, the buffer cache is never 100% empty.  So, where are these commands useful then?  They would be useful for a developer/DBA who have their own instance and are doing performance testing on some code.

UDFs (User Defined Functions) are a great feature in every RDBMS. We have covered their usefulness before in our blog posts. Based on some of the questions that we have been getting, we thought about writing a blog post that just talks about the limitations of the UDFs in SQL Server, so here goes:

1) The TRY…CATCH block cannot be used in a UDF. Infact, other error handling modes: @@ERROR or RAISERROR are not supported either.

2) Non deterministic functions like getdate() cannot be used with a UDF. Though there are workarounds for it.  And it is allowed in SQL Server 2008.

3) A UDF (any of the three variations - scalar, inline or multi-statement) cannot be used to return multiple result sets.

4) UDFs cannot call stored procedures. They can, however, call extended stored procedures.

5) UDFs cannot make use of dynamic SQL or temporary tables within the code. Table variables are allowed though.

6) Any type of SET commands are not allowed with a UDF.

Again, do remember that UDFs have a lot of use in T-SQL. The above points are just to summarize the limitations since many questions like why can’t I use TRY-CATCH in a UDF or why doesn’t usage of a temp table (though through a table variable, that is hardly a limitation) work in a UDF get addressed by the above post. All this is very well documented in BOL as well.

This post is non technical in nature. We are posting it here because recently we helped one of our clients to go through a selection process of choosing an off-shore company for their development and QA activities. This was our third such engagement in which we have helped our clients get the most value from a consulting engagement. Outsourcing to an off shore company has a lot of advantages as well as things to be vary of. A lot of material is available on the internet in that regard so instead of writing a dissertation on it, we will point you to the IAOP (International Association of Outsourcing Professionals) site which has a lot of good whitepapers in this regard. You can access it here.

The process that we took the client through consisted of these steps:

1. Interviewing the key stakeholders to learn about the needs of the company - short term as well as a long term vision.
2. Forming the goals statement and matching those goals against a list of outsourcing companies from off-shore locations. A mix of Tier-1, 2 and 3 companies were chosen as well as non-Tiered companies were chosen as well to give the client an opportunity to consider more than one outsourcing off-shore vendor (this has benefits and challenges that we will cover later on in this post).
3. Having discussions with the client to discuss the different companies and narrowing it down to a list of top 5.
4. Contacted those 5 companies and established the communication between the client and the representatives from these companies. All of them also had a presence in the US.
5. Prepared a preliminary agenda for the first conference call between the client and the 5 companies. This was to go over an Agenda that was inline with the client’s needs and to make sure that both sides understood what the goals were.
6. The next step was to prepare a RFI (Request for Information) document while working with the client (different departments) and send it to the 5 companies.
7. Collected the RFI responses and had discussions with the clients to narrow it down to the top 3. A rating system was developed in three categories: Technical, Operational and Commercial & Legal. All three had sub-sections against which each reviewer (including us and members from the client team) rated the vendors on a scale of 1-5. Weight measures (how important each category was for the success of the company) was also put in on a scale of 0-5 (0 because some sub-sections in a particular category might not make sense for the goals of the employee - there was only 1 such sub-section in this case which related to hosting. The client wanted to host the systems here (an ASP model is followed by this client).
8. Next step was to prepare an RFP (Request for Proposal) and to send it to the top 3 vendors. We co-ordinated the questions and helped answer the questions on both sides related to the process and having worked with the client’s IT department, we were aware of the business needs as well.
9. Upon receipt and review of the completed RFP from the vendors, we sent follow-up questions that were addressed during the face-to-face meetings with each. An agenda with proper targeted questions was prepared for these meetings.
10. The ratings were done again for the 3 vendors against the RFP responses.
11. Weight measures were averaged out and where there were significant differences, they were discussed among the team members and normalized.
12. References were checked to ensure a recommendation was made to go with two outsourcing vendor companies.

This whole process was completed in 2 months time frame and was a very pleasant experience for both the client as well as the outsourcing vendor companies. As far as going with multiple outsourcing vendors is considered, it is a complex process and has risks associated with it but if managed properly, it does provide a lot of benefit as well to the company. Here are the benefits and disadvantages of such an approach:

Benefits:

1. The big bang outsourcing with a single vendor can lead to issues for the company since if the decision turns out to be not working for the company, down the line it is difficult to recover from it.
2. By choosing to work with 2 outsourcing off shore vendors, the company can cut costs and also foster a healthy competition between the vendors while taking advantage of vendor specialization and technical expertise. In this client’s case, one of the vendors (a Tier-1 company) was pretty expensive in terms of rates (nearly 3 times the cost prices of the second vendor (a Tier-3 company)) but they did have more business knowledge of the domain.
3. The second vendor did not have related business domain experience but did have a rich pool of technical resources and was ranked very well as compared to the Tier-1 vendor in the evaluation process.
4. It mitigates the risk for our client since down the line, they could switch from one vendor to the other if things do not work out with a vendor. Since the vendors would have been already engaged on a T&M basis, that transition for the team would be seamless.
5. It also gives them an opportunity to engage the Tier-1 vendor with probably a fixed cost project for one of the projects that requires a good amount of domain expertise in order to be successful in a short span of time.

NOTE: As per the Gartner group, multi-sourcing will remain the dominant sourcing model. Organizations like GM, Kodak, P&G have done this quite successfully by managing the relationships better. As per a survey from CIO magazine (from Feb. 2007), here was the break up:

• 3 or more outsourcing vendors: 42%
• 2 outsourcing vendors: 36%
• 1 outsourcing vendor: 22%

Disadvantages/Challenges:

1. Managing 2 outsourcing off shore vendors is a time consuming and a complex process. It also adds to some cost upfront since the client now needs to have 2 separate resources for managing these 2 relationships. If appropriate governance is in place, then this risk is mitigated.
2. If not properly managed and explicitly stated in the contracts, this can lead to a blame game. We can mitigate this by explicitly defining the contract terms.
3. This typically requires some extra legal documentation work.

If you have a need for finding an outsourcing partner company at an off-shore location, please feel free to contact us at: info@decipherinfosys.com