The classic conundrum is IT has always been between building the solution yourself or buying it from someone else. Let's look at some of the common build vs. buy scenarios and see how to make the best decision between them.
The classic conundrum in IT has always been between building the solution yourself or buying it from someone else. Let's look at some of the common build-versus-buy scenarios and see how to make the best decision between them.
Probably for as long as man has existed the question has been asked: "Do I do it myself or get someone else to do it for me?" This has also been a classic problem in IT. Whether it's building PCs out of parts to outsourcing the entire IT function, there's an ongoing debate about whether it's better to solve a problem by building a solution in-house or buying it from elsewhere.
It's possible to have a build-versus-buy debate for just about every aspect of IT, as well as the entire IT function. In a build-versus-buy debate, each function has its own particulars that will control which solution is a better choice. At the same time, however, there are some common arguments that flow through the topic of build versus buy.
First, there's the standard cost/benefit analysis. All you have to do is break down the problem into pure dollars and cents. It's a relatively simple comparison. How much will it cost you to assemble the solution yourself vs. having someone else to do it. Compare that to how important the solution is, and then you can decide whether it's worth your time or not.
The second common decision factor is related to the first, and that's just how strategic the function is that you're making the decision about. Functions that are core to your organization and may be key to its survival or basic business may be too important to trust to another source no matter the cost.
I call this one the "Blue Lights and Bullets" factor. When I worked for the local police department, we wanted to buy a certain computer system, and the major in charge said "How important is it? All the cops need is blue lights and bullets. You can't catch bad guys without blue lights and bullets." In tight times, the system would have cut into the basic budget, which was core to the department's function. It was important, but not as important as other things.
Finally, the last thing that's common to any build-versus-buy debate is the customization factor. You can build a solution exactly the way you want it, but often bought solutions are strictly off the shelf for a large audience. Most bought solutions are generic, and you need to make sure you that you don't have any special needs that fall outside the generic solution. Additionally, with a generic solution, you may have to alter business processes to match it, rather than the other way around. Although you can sometimes modify a bought solution, that can add needless cost and complexity.
Desktops and other hardware
From the time Jobs and Wozniak started assembling Apples in their garage, people in IT have been assembling computers from parts for their own use. There has been a big back and forth over time about whether it's better to build or buy PCs.
It's essentially impossible to custom assemble something like a laptop out of parts, but you can still do so with desktop PCs. The problem is that except for high-end gaming machines, the prices of basic computers have dropped so low that there's not that much of a price difference between a purchased computer and an assembled one.
If you're considering building PCs, don't forget to factor in other things. First, a preassembled PC will come with its own warranty and support centralized in one place. Although individual components in a custom unit may have warranties, tracking them all may be problematic.
Additionally, among all the needless software that's loaded on almost every preassembled machine, there is a lot of basic software that you may need, including an operating system, which will cost you extra on a self-built machine.
Software can come in three different flavors. First there's the off-the-shelf commercial application. You also have prepackaged software sold by developers who then customize the software to your needs. Finally, there's software written from scratch -- either in-house or by contractors.
Off-the-shelf software is usually less expensive than custom software, but obviously it is much more rigid. You must adjust to the way the program works and do without unsupported features. You then have to balance what the program does for the price compared to the value of what you have to have it do but it doesn't.
Customizable pre-written software is more expensive than off the shelf, but you can alter it to meet your needs. For example, a country club I do consulting for has an accounting package to track sales in its bar and restaurant. However, due to vagaries in local law, it must track alcohol sales from a member's personal account rather than out of general inventory. No standard accounting package did this, but they were able to find a company that would modify their software, for a price naturally, to accomodate it. That allowed the club to be able to computerize their accounting system while still following local law, and it was cheaper than having the system programmed from scratch.
The complete custom solution is usually the most expensive. This was the option we took when we did a 911 system for the police department. We could create custom screens based on dispatcher input, customize coding and acronyms, and so on. When we were done, we had exactly the system the dispatchers wanted, but it wound up being more expensive than other pre-packaged semicustomizable solutions. In the final analysis, the cost was justified based on the importance of the package and the needs of the dispatchers.
The last two solutions also have an added twist. The complete or partial customization can be done in-house or contracted elsewhere. From there you can consider the cost and time it will take to make the final decision.
In-house datacenters vs. colocations
Traditionally small and medium businesses have just set up small server rooms to house data. As applications become more complex and needs grow, more and more of these organizations need full-fledged data centers. A-not-as-common decision that's increasingly important is whether to build a datacenter in-house or to use a colocation instead.
The cost considerations here are much greater than they are with simple systems. You have to consider the cost of the servers, racks, air conditioning, and ongoing power costs. There's also the issue of security -- whether you trust corporate assests with another firm or you retain physical control.
Colocated data centers have an advantage of being easily scalable. The colocator probably already has all the servers, climate control, and everything else on-site. All you have to do is pay for the added space.
Performance may be an issue however. If you don't have the resources on-site, you might be constrained by bandwidth issues getting data to and from your users. Plus, you add another point of failure that you may not have control over, that being the line being used to connect you to your colocator.
Outsourcing all of IT
A decision being made by some organizations is to just buy an entire IT organization by outsourcing the department to IBM, HP, or the like. Rather than building expertise in-house, a company will contract IT out to a services organization. This has been a pretty good business for companies like IBM, and it can save large businesses lots of money. From a business perspective, if your business is running through a rough patch, they can just cut back on the contract, which is easier than laying off employees.
Even small to medium businesses can use local consultants and contractors to take care of their IT needs. The shops may be too small to afford their own IT guy or just have only occasional work that needs to be done. In that case, there's no reason to train someone on-site to do IT or to hire a person.
The problem with outsourced IT is that outside people you hire to do the work don't necessarily have a vested interest in your organization. If something goes wrong, they can just move on to another contract. Plus, because they aren't connected to the organization, they may take less of an interest in the business in general. They may not make the relationships necessary and have the insight into your organization that an internal employee may get. An internal employee may be able to make positive suggestions based on such knowledge that a detached contractor may not.
Building vs. buying resources
There are a few other resources you can look at on TechRepublic and elsewhere to help make the case for building vs buying a solution. Some of these include
- Consider These Points when Making the Build vs. Buy Decision
- Should SMEs Construct Their Own Data Centers or Purchase Space in a Colocation?
- Server Colocation: Technology Toolbox
- Selecting an ERP System: Build or Buy?
- Should You Build or Buy Your End Users' PCs?
- Building vs. Buying Your Own Computer, Revisited
- The Best Software Developers Are Built Not Bought
The bottom line for IT leaders
There's more to a build-versus-buy debate than simple numbers. Although cost is an important factor, there are other things to take into consideration. Sadly, too often organizations merely look at the numbers and the bottom line. As an IT leader, it's your role to look beyond that and make other decision makers fully aware of the implications of building or buying a solution.