Cloud computing, software as a service, outsourcing… to me, these are all synonymous terms.  While “cloud computing” as a concept has gained tremendous traction and mindshare, the fact remains that this sector of computing is nothing more than today’s de jour term for outsourcing and the decisions around and challenges regarding outsourcing should remain front and center all the way through the process.

One of the first questions that comes up almost immediately after problem identification and before solution creation lies in the decision as to whether to build a solution or to acquire a product or outsource the development of a solution. There are a great many factors that go into this decision and here, I will discuss a few important points.  Over the past few months, Westminster College has had a number of opportunities to ponder this very question and our answers have been varied depending on circumstances.

Cost. Obviously, cost plays a major factor in the build vs. buy/outsource question. If it’s cheaper to buy and integrate a third party solution, or to move a solution to an outsourcer, that is often the best way to go, particularly for IT shops with limited development resources. At Westminster, we have very limited development resources, so we often make use of third party products and services as a part of our solutions. We don’t do this 100% of the time, though.  Don’t forget that costs analyses should always include the time that a develop would spend on a particular project.  There are also opportunity costs to consider; if a developer is spending time on project X, that’s time not being spent on project Y. All that said, there are times when we build a solution ourselves, but many of those solutions still make use of third party products.  More on this later.

Time constraints. Often, cost is not the determining factor in a build vs. buy decision. In many cases, there is a need for fast-tracked time to completion for a particular project so outsourcing the task to a company with a focus on the particular problem area or to a company with a product solution is undertaken. After all, if a company has taken the time to productize a solution and they are actively supporting a product, it’s likely that the product will undergo continued development, thus relieving the internal IT department of the need to continually expand and enhance a solution. In these cases, cost plays a secondary role to the immediate business need.

Security and Compliance. Highly secure environments remain that way by connecting themselves to as few other environments as possible. Every time an organization outsources a particular process or service, lines of communications need to be established and remain open to facilitate that process or service.  While many outsourcers have enviable security measures in place, IT groups that want to outsource must make certain that vendors maintain regulatory compliance as well as security measures. Failure to do so can and will open an organization to major liability.

Ability to identify a product. Let’s assume that your default position is to buy a product or service or outsource whenever possible. If the process or service you’re trying to outsource is something common, like a centralized calendaring system, there is plenty of product choice out there. If, however, you’re trying to implement something more esoteric, your outsourcing options might be limited and you might be better off building the product yourself. You might also run into problems finding a product that exactly fits your business processes. In these cases, you need to determine if it makes more sense to modify your processes to match product capabilities or to develop a product that meets your exact process.  Many organizations are loathe to change even the most basic processes even when it’s in their best interests to do so.

In-house expertise. Do you even have the in-house staff that can build a particular solution? If not, you’re pretty much relegated to the “buy” portion of the equation. As a part of this question, ask yourself if you have the staff time and expertise to maintain a product, too. After all, once you build something, you own it – both the good and the bad.

Read Source


Related posts