Feature

Application Development: Special Report

Forget the build vs. buy debate. Today's midmarket CIOs take a mashup approach to create software that's right for the business.

Editor's Note
To view our complete multimedia package, visit our

    Requires Free Membership to View

application development special report.

CIOs, take note: In today's midmarket environment, application development is a huge priority. In fact, it's the top strategic IT priority for 2007, according to CIO Decisions research of nearly 400 subscribers. One-third said they exclusively build applications in-house, while another third said they use a mix of staff and contractors. The final third said they use staff, contractors and partners.

That's not to say they don't buy software as well. Commodity or standard applications (think Office) plus many flavors of ERP software, among other types, are much more often bought than built. But in today's IT shop, buy vs. build is not a binary choice. Like the Toyota Prius, a hybrid model is taking hold.

This approach to application development blends the delicate arts of building new applications, working with contractors and integrating everything into one overarching strategy. CIOs still buy software when they find something that satisfies a business problem; but, rather than modify the purchased application, they develop ancillary programs around it.

In Web 2.0 circles, this buy-and-build strategy is considered a "mashup" in that it draws upon existing Web applications or data sources and combines these resources to create a new application. Jeffrey Hammond, a senior analyst at Forrester Research Inc., a market research firm in Cambridge, Mass., says that instead of repeating or mimicking functionality between off-the-shelf and custom apps, this approach extends and amplifies the functionalities that are already there.

"At the end of the day, it doesn't matter how you approach application development so long as you're doing it to some degree," he says. "Build it, buy it -- whatever you need to do to get an application working."

An Evolution

It wasn't always this convenient. For years, the thinking around buy vs. build was that CIOs would buy packages when they couldn't find developers with the right expertise, and would build packages when off-the-shelf failed to fit the business problem. Naturally, while this dichotomy had its benefits, it also had shortcomings.

One problem with the "buy" strategy was obvious: price. Solutions from companies such as Oracle and IBM were anything but cheap, and many midmarket companies struggled to fork over implementation and annual licensing fees. Smaller vendors could go out of business or be acquired, jeopardizing maintenance or upgrade paths for their products.

The problem with the "build" strategy was more subtle: scope creep. That circa 1990 statistic from The Standish Group that about 80% of all software projects were being abandoned, finished late and delivered over budget or short of expectations is still true today. Indeed, CIO Decisions survey respondents indicated that their three biggest concerns with development are getting requirements right, completing projects on time and on budget, and getting buy-in.

Brian Kilcourse, managing partner of RSR Research, a consulting firm in Miami, calls in-house software development the "wild child" of IT.

"There have been instances in which in-house people get rolling on a project, and suddenly the project would snowball into something bigger and more obtuse than anyone expected it would be," he says. "Does the project get done? Eventually. But when you're building something from scratch, you run the risk of projects taking a while."

This reality has changed somewhat on both the buy and build fronts. The buy landscape has changed in that now there is a "rent" option -- Software as a Service (SaaS). Renting software is usually an operating rather than a capital expense, upgrades are automatic, and an application can be easily rolled out for a few or many users. On the build side, today's hottest approaches -- service-oriented architecture (SOA), Web services and open source software (see story) -- have simplified development. The coding is generally easier than with the proprietary languages of yesteryear, and the talent is plentiful. New college graduates are well versed in open source, and highly experienced talent is available via contractors and partners, the result of big-company layoffs. The SOA model itself, in its facilitation of reuse, makes development more efficient.

"For us it comes down to a price-per-function equation," says David Sockol, CEO of Emagined Security, a solution provider in San Carlos, Calif. "If I need a $10,000 tool and I have to buy a $100,000 solution in order to get my minimum requirements met, obviously that's not the kind of situation I'm going to like."

This was first published in September 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: