This is a guest post by TechRepublic's Scott Lowe, CIO of Westminster College in Fulton, Missouri. Lowe walks us through the software as a service and cloud computing due diligence. For more posts like this see TechRepublic's IT Leadership blog.

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.

Sometimes, ignore the obvious decision and do what makes sense for the long haul

I mentioned the fact that there a quite a few centralized calendar systems out there. Westminster College faced a major need for just such a system earlier this year. Conventional wisdom dictated that we simply obtain, deploy and integrate an existing third party solution. Instead, however, we built our own SharePoint-based system and it’s been working out very well. Why did we do this? Simply put, a master calendar was a system that we could easily define and wrap our arms around, and my primary SharePoint developer wanted to gain more experience developing solutions as we face a growing list of similar requests.  She felt that, by undertaking and completing the master calendar project, she could better assess the build vs. buy question for future development efforts while also expanding her SharePoint development skill set. Although the development time was longer than it would have been had we simply acquired a productized system, the end result has been phenomenal and my team now has a much better understanding of one of our primary systems. Because of her familiarity with the calendar system, my SharePoint developer is now working on extending the system as a part of some efforts we have underway to tame our campus email deluge.

The Cloud Computing question

The number of questions that I receive regarding cloud computing is growing all the time.  From general questions asking what cloud computing is all about to specific “I got a call from this outsource vendor and we want this product” questions, organizations need to make sure that due diligence is performed regardless of how a service is ultimately addressed. For me, it’s imperative that any solution we obtain be supportable to include the ability to somehow integrate with existing systems.  With a major goal of increased operational efficiency, it wouldn’t make much sense to add services that require a lot of manual work to make operational. All that said, the rising tide of cloud vendors is making it more difficult to make sure that folks on campus work with products that won’t open us up from either a security perspective or from an efficiency perspective. My answer: We need to make sure that we’re adequately addressing the problem and that an appropriate build/buy decision is reached, even if a group goes off on their own and selects a product without involving us until the end. IT does need to sign off on technology product and service procurements, so we’re generally able to catch potential problem purchases before they take place.

The fact that so-called cloud-based services have a seemingly lower barrier to entry to other hosted solutions should not change the process that you undertake to identify the right path.  Make sure you continue intense due diligence efforts to protect your company and your data.

Summary

Summarizing this post is easy.  Simply put: Be careful and be diligent, but also recognize potential opportunities that may not be immediately obvious.