14 Aug Build versus buy: Gray areas challenge IT judgment
If you’re familiar with the term “situational ethics,” you have an idea of what companies go through in deciding whether to build or buy a software application.
There are some scenarios where the right direction is pretty obvious, but there also are gray areas where the decision isn’t as clear cut. For the majority of small and mid-sized businesses today, several trends point toward buying and making do with packaged software, including the high percentage of information technology projects that are not completed on time, come in over budget, and have far less functionality than originally envisioned.
Wausau attorney Tim Nuckles, who advises clients on information technology matters, said the trend among his clients is moving away from build. “Most of my clients are working with downsized IT functions, and they want to buy as much functionality as possible off the shelf,” he said. “They are definitely not building stuff in-house like they did 10 years ago and prior to that.”
Yet thanks in part to some costly IT failures that were caused by excessive customization of software, there are merits to building from scratch – especially in large organizations with astute software developers. Given their resources, it’s much more typical for larger companies to build, often times after the “buy” decision doesn’t work out.
Advantage build: Flexibility and control
The advantage of a build is that you have control over the requirements and control over what the software does, notes Madison software developer Robert Merrill, principal of uFunctional, LLC. By building, he said organizations get exactly what they want, they can change their minds in the future, and “they always have that flexibility and control.”
“Once you understand that, you understand that the critical thing is the requirement flexibility,” Merrill said. “If there is something about the software that is very particular to what you do, or to what your business is trying to do, and you can’t buy something that will do that, then you’re in a situation where you have to consider building it.”
Another advantage of build stems from the challenge of aligning off-the-shelf software with business processes. Mike Bernhardt, president and co-founder of the Madison-based Dane Solutions, said each company has its own business model and requirements, and so changing business processes to fit software products doesn’t always work out.
In addition, those who aren’t careful can spend a lot of internal time incorporating software into their business processes. If it’s a large application that you’re only using a fraction of, excessive blocks of time can be spent adding modules because the off-the-shelf product “is mostly fluff that you’re working around,” Bernhardt added.
What’s more, buyers may become overly dependent on others after the purchase. “If you go the buy route, you’re at the mercy of vendors and you may have to wait for patches on their schedule,” Bernhardt said. “If you build it yourself, you’re on your own schedule.”
Advantage buy
The advantages of “buy” are the speed of production and the lower cost. Software development is an expensive proposition, Merrill said, and if a software company already has developed what you need, you can spread it out over 100 or 1,000 or 10,000 users. The cost of duplicating that software is very small, and the ability to spread that development cost over a lot of users is why the economics of buying software licenses is so compelling.
The recommendation to buy usually is based on the cost difference. If a company really doesn’t require flexibility, and if it can afford to take the software “as is” and live with it, why expend labor resources on build?
That’s especially true if you’re looking for a software application in a “mature” field – accounting and payroll, for example – that offers several viable commercial options. Whether it’s Microsoft Word, Quickbooks, or “bug tracking” products, off-the-shelf solutions are readily available.
“There are a lot of products out there, including open source, that handle everything,” Bernhardt said. “There is no need to build in that situation.”
Nuckles, offering the flip side of changing processes, said his clients are starting to realize that some changing of business needs to conform to an existing software product – versus creating every bit of functionality to match current business needs – is often the prudent way to go. In addition to outsourcing IT needs in general, they prefer to minimize development and risk.
Gray area
The ultimate decision, however, is not always that cut and dried. Gray areas always exist where there is software on the market, but there are specific business needs that go unmet. Or perhaps because of changing business conditions, the organization isn’t always sure what its future needs will be.
Brian Rust, communications manager of the University of Wisconsin-Madison’s Division of Information Technology, said DoIT was faced with a build versus buy scenario in the late 1990s. The result was uPortal, a sharable Web portal used by UW-Madison and other universities to deliver information to students, faculty, and administrative staff.
Initially, UW-Madison purchased a vendor product, Epicentric, to replace its course-management system, but the product and the market both were immature. When it was time to decide whether to renew the license, the price went up and DoIT wanted software that would do things that weren’t in Epicentric’s near-term plans.
Facing a lack of viable commercial alternatives, the university got involved in the development of uPortal, and hired a software developer to tailor its own version of the open-source product. Since very few software projects are perfectly suited for individual universities, each school involved in the project had the flexibility to develop it to suit its own needs.
Rust said the Epicentric software had become more difficult to adapt to existing campus tools like PeopleSoft, and the open source uPortal could be integrated more easily. “Our thinking was that if we were going to invest time in modifying commercial software, we might as well invest it in open source software and have more control over the product,” he said.
Rust said one of the build-versus-buy calculations is understanding the extent to which the organization will make modifications to the software over time. DoIT’s first step was conducting a needs assessment to identify requirements both now and in the future, and for the preparation of a Request for Proposal that would seek vendor information on price range, support, and their track records in running environments like Unix and Windows.
The RFP process usually is associated with government agencies, but Rust said more private sector IT departments are going through a similar process. In addition, the RFP is not always a strict “buy” proposition because part of the RFP process could include a draft proposal to “build it yourself,” Rust said.
“In some cases, the modifications become so significant that it’s better to build from a sheer cost standpoint,” Rust said, citing the UW Systems’ experience with Lawson software as an example of how modifications can get out of control. “That’s why it’s important that a complete assessment be done before you make a decision to build versus buy, or you could start down a path of endless expense trying to adapt the software to your needs.”
Unlike the Lawson software project, uPortal has proven to be a boon to the university, recently winning a national award from EDUCAUSE.
The Open Source option
In the private sector, open source often is an overlooked alternative to building and buying, but it offers elements of both, particularly the speed to market of buying and the flexibility of building. Those who consider this option must think about the licensing issues and obligations associated with it, but the advantages are undeniable, according to Merrill.
Open source often is overlooked because it’s a relatively new concept and a relatively new market. When people think of open source, usually software infrastructure such as Linux and the Apache web server come to mind, but open source applications are gaining traction. They are being used in the e-commerce, customer relationship management, and enterprise resource planning systems.
As is the case in the build scenario, companies have development capabilities, and therefore flexibility, available to them, but open source saves a lot of development effort, and it shortens the development cycle. With e-commerce, for example, you would already have a shopping cart, customer log in, and a product catalog.
“Rather than building those things from scratch, you could spend your development dollars on very focused customization,” noted Merrill, who was part of developing an e-commerce open source program when he was with Berbee Information Network’s application development group. “If we only need to change the price model or if we only need to change the checkout flow, we can focus our attention on that without reinventing the wheel.”
If an organization needs to change open-source software, it has access to the source code and permission to change it. “Even if you don’t change it, a technical person can look around in there and find out what’s going on,” Merrill said. “Sometimes, that’s very valuable in a support scenario.”
Relative to a buy, organizations have the flexibility to make changes, and it’s easy to evaluate and test it. A lot of the commercial software vendors have gone in this direction because it’s easier to get a hands-on evaluation copy, Merrill said.
Vendor pressure
Whatever the choice, Rust said it’s important to have a strong project manager in place to conduct an assessment of current system, what’s needed, what’s available in terms of commercial options, and the feasibility of modifying the current system.
“Just because you have the resources and wherewithal to build a system, that doesn’t mean you should build,” Rust said. “You need a thorough assessment of buy options despite any pressure from a particular vendor.”
Related story
• UW-Madison open source project shares national IT honor
• Speaker announces business members of IT Task Force
• Robert Merrill: Defining the X-factor: What is an ounce of software worth?
• “My UW Madison” portal migrating to uPortal