Forget the build vs. buy debate. Today's midmarket CIOs take a mashup approach to create software that's right for the business.
|To view our complete multimedia package, visit our 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."
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."
The Bonus of Both
Greg Seyk understands these realities. As CIO of VisionQuest, a Tucson, Ariz., company that offers intervention services for at-risk youth and their families across the country, Seyk recently took the build-and-buy approach to creating a Medicaid billing package that would accommodate billing in multiple states, since every state's method of doing business and calculating reimbursement is different.
The buy was an upgrade to the company's Lawson ERP system (from version 7.0 to version 9.0). But since the Lawson system didn't address the individual vagaries from state to state, there was a build component as well. VisionQuest partnered with a small Pennsylvania software development company to write applications that would get the job done. Company programmers did the work in a matter of weeks.
"I try to approach these situations from the perspective of what the CFO or CEO would ask me about risks," says Seyk. "Can we mitigate those risks by doing both build and buy, and if so, is it reasonable to accept those risks in the name of the business?"
Another variant of the hybrid approach is to do both through service providers. That's what Doug Harr, CIO of Ingres Corp., a database company in Redwood City, Calif., often does. Because he has a tiny IT shop, Harr has signed up for on-demand applications and application development in the areas of customer relationship management (Salesforce .com), ERP (Intacct), human resources (ADP) and email (Insight).
Some could argue that because Harr is purchasing this software from vendors, he's adopting the buy method. Harr, however, disagrees, noting that he only pays for the applications when he needs them, and he has support contracts that include customization where applicable.
"Let's say I go and buy a big SAP or ERP solution -- I'm going to depreciate that over the life of that product," he says. "If instead I can get into a solution where I can pay by the month or year, it's a better way to do business when, as we know, the market goes through cycles."
Of course, often the decision comes down to whether the functionality of an application can give your business a competitive advantage. "If you can differentiate yourself in the marketplace or with your customer base by writing your own software, then you should do it," says Larry Bonfante, CIO at the United States Tennis Association in White Plains, N.Y. "If you can't differentiate yourself, don't." Bonfante, who runs all the IT for the annual U.S. Open tennis tournament with a staff of 30, usually tries to find an off-the-shelf package. While the USTA considers itself a .NET shop, the organization will go outside that for certain projects that would be better served by Web services or perhaps open source.
IT leader James Woolwine, who spent years as CIO of Majestic Insurance, today is PMO executive at CT Summation, a software company in San Francisco. His view: The key to application development is the initiative to make all off-the-shelf packages table-driven. This allows CIOs to tweak products on their own, tackling every aspect of the mashup approach in-house. Ultimately, he adds, these tables will be so easy to use that business analysts could make the changes, obviating the need for application developers altogether.
"Many CIOs will say, 'Our business is so unique that we can't buy off-the-shelf software,' or, 'We are special and we have to build,' " he says. "Choosing this path and freeing up IT people for bigger and better projects could save everyone a ton of aggravation down the road."
Where the Buzz Is
Web services, open source and agile development are top of mind in development
In the world of application development, three approaches these days are generating all the buzz: Web services, open source and agile development. These aren't mutually exclusive -- you can engage in agile processes and still use open source software to build a product. Here is more detail on each.
1. Web Services
Web services has become the hottest aspect of application development today as companies look to develop applications with this XML-based tool set. Nearly half the respondents in a CIO Decisions survey reported using them.
If programs are seen as buildings, Web services are the hammers and nails used to build them. Organizations most commonly use XML for three types of operations: Remote Procedure Calls (RPC), Representational State Transfer (REST) and service-oriented architecture (SOA). The most prevalent of these is SOA, where the basic unit of communication is a single message. According to Jeffrey Hammond, senior analyst at Forrester Research, this type of Web service is both flexible and easy to use.
SOA comprises loosely coupled and transparent services that speed delivery of software by leveraging reusable services. Organizations embracing the architecture can make changes to services one at a time, which minimizes disruption. Other benefits: increased quality through independent testing and verification; ability to integrate disparate programs more easily through open standards and technology; and reduced cost and risk through leveraging existing transport protocols and Internet infrastructure.
Of course, this flexibility also can be a negative. Security is always an issue, with hackers finding holes in even the most seemingly bulletproof apps. Performance can be a problem, too, as XML-dependent services and loosely coupled architecture are not built for speed.
"[SOA] is traditionally a text-based, metadata-loaded document format, which makes it incredibly inefficient from a network, processor and storage performance perspective," says Ron Schmelzer, senior analyst at Waltham, Mass.-based ZapThink.
There are ways to address the performance issues, though. Schmelzer says there are three approaches: using specialized hardware accelerators, an optimized software and compression approach, or binary XML to replace the unparsed, text-based XML.
Versioning an Issue With Web Services
| To some CIOs, the process by which application developers assign unique version numbers to unique states of software programs can be distinctly counterproductive.
Take Web services, for example. As growth in this development paradigm has exploded over the last few years, programmers are changing code frequently, constantly upgrading their apps to talk to other ones. While this practice increases usability, it also complicates the user experience by requiring that the very latest version is installed.
This is a pet peeve for Alex Krapf, CEO of Codemesh, an independent software vendor in Carlisle, Mass. Krapf's company specializes in language interoperability, and he says he's experienced problems with customers who change details in particular code without knowing who uses the code and what they use it for.
"We see these instances where users change the service and three days later they get nasty phone calls from people they didn't even know were using it," he says. "It's bad enough to manage versions inside your monolithic application, but when someone publishes a new version for everyone to use, those problems are compounded."
Technically speaking, the versioning problem is one of incompatibility. Each new version of a program may add new top-level constructs (such as elements, types and groups) and extend existing constructs with optional content. Instances created based on earlier schema lack these elements, and require new schema with new target namespaces.
One solution to this problem is for clients to ignore the extra data. Another solution is to use a mapper; both the .NET XML-to-object mappers (XmlSerializer and DataContractSerializer) do this. Java Architecture for XML Binding (JAXB) 2.0 (which is used by Java API for XML Web Services) has an option to do it, too.
2. Open Source
The benefits of open source software are well known. Among them: Open source can encourage software re-use, improve quality and security, protect against vendor lock-in and even allow greater flexibility in customization. From a short-term perspective, open source software or services can be utilized easily to address a specific pain point.
Typically, this narrow focus allows a team to recognize a return on investment (ROI) relatively quickly, especially if longer-term goals or objectives for an application are not included in the project justification or funding criteria. For Doug Harr, CIO at Ingres Corp. in Redwood City, Calif., this is part of the appeal. Harr hails open source for three main reasons: reduced cost, large-scale availability and access to a large community of developers who have crafted either portions of the solution or extensions to it.
"At the end of the day, while we CIOs want something that's not too expensive, what we really want is reliable software," he says. "We're not looking for free, we're looking for something that's cost effective and solves the business problems at the same time."
Open source has become a key part of the strategy for organizations building on to packaged applications because it can easily be used to tweak off-the-shelf software packages. Furthermore, while most companies handle open source in-house, a number of solutions from vendors such as Red Hat and Novell are products that CIOs can buy and build on to at some point down the road.
Especially with the rise of RubyCLR, open source software for writing .NET applications, CIOs like Harr predict that reliance on open source for application development will continue to increase. Recent headlines about Oracle offering support for Red Hat Linux and Sun Microsystems launching an open source Java project emphasize these trends.
Perhaps the only downside to open source at this point is security. Alan Cox, a prominent figure in the U.K. open source movement, has been warning for a year that hackers have open source software in their sights. "Things appear in the media, like 'Open source software is more secure, more reliable and there are [fewer] bugs,' " Cox told delegates at London's LinuxWorld conference last year. "There is a lot of money going into security, but the situation is worse, because there is a lot of money going into breaking security, too."
The Challenge of Offshoring: Management
| So you've decided to build your own software . Now it's time to evaluate cost.
For coding, you'll find that it's significantly cheaper to outsource programming to developers in India, Russia or the Far East. Overall, however, offshore development efforts may end up costing more than keeping the work at home.
Dale Polekoff, director of IT at Jacob Stern & Sons, an agricultural products company in Santa Barbara, Calif., learned this lesson first-hand. This spring, Polekoff sent a small (sub-$5,000) development project for his ERP system to China.
Though the price was right, the project cost Polekoff several hours per day directing overseas developers on what to do and how to do it.
Equally expensive was the quality assurance procedure. Because of the language barrier, Polekoff had to give some directions two or three times to be clear.
"Sending smaller projects overseas, despite the great quality of work, is just not practical," he says. "I would do it again for the right project, but I think it'd have to be a more substantial project where I could spread some of the management over more development hours."
Peter Sterpe, senior analyst with Forrester Research, says these and other problems are common for CIOs who turn to offshoring for development work. Pertinent ramp-up questions should include: Who looks after offshore staff? Who manages them? How many insiders are necessary overall?
Another issue for CIOs who offshore is managing change at the partner overseas. Sterpe says he's spoken with some CIOs who have been victimized by turnover when nobody stepped up to train the new employees at the offshore site.
"There are a lot of variables when you send development work overseas," Sterpe says. "It's not necessarily a bad idea, but it's something a CIO must think through thoroughly before committing to it."
3. Going Agile
Agile is a conceptual framework for software engineering projects that embraces and promotes evolutionary change throughout the lifecycle of a project. To veteran developers (and business-savvy CIOs), this strategy might seem like common sense. But the framework has created some controversy due to its lack of structure compared with traditional methods.
Most agile development methods attempt to minimize risk by developing software in short time frames called iterations, which typically last one to four weeks. Each of these iterations is like a miniature software project and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design coding, testing and documentation. While a particular iteration may not add enough functionality to warrant releasing the product, most agile projects result in the release of software at the conclusion of every minor milestone.
"Agile development refers to teams that are nimble, flexible and responsive to business needs, using a variety of iterative development processes," says Liz Barnett, principal analyst at EZ Insight in Bedford, N.Y., and editor of AgileJournal.com. "It's as much a philosophy as a way of life."
Technically speaking, the notion of agile software development refers to a specific set of processes that have evolved over the past 15 years and include Extreme Programming (XP), Scrum, Feature-Driven Development (FDD), Crystal, DSDM and Lean Software Development, to name a few. The Agile Alliance (www.agilealliance.org), a nonprofit organization created by the thought leaders behind most of the agile processes, promotes the "Agile Manifesto," which emphasizes a core set of values that all agile processes must follow, such as valuing individuals and interactions over processes.
Granted, agile isn't right for every project. Particularly with large development efforts that require an overarching structure to make sure everything gets done, the laid-back atmosphere of agile can lead to chaos. Barnett herself warns that because agile, by its nature, requires programmers to deliver frequently, this, too, can create problems for a development team that may be all-too accustomed to taking its sweet time. Still, Peter Sterpe, a senior analyst at Forrester, says the benefits of this framework far outweigh the potential negatives.
"Because agile shows working results quickly and frequently to stakeholders, you get a lot of benefits knowing if you're on track or off track sooner," he says. "If IT is all about delivering the code, it has to be code that meets the need and is truly on target and valuable for the business, and agile helps you get there with lower risk."
Matt Villano is a freelance writer living in Half Moon Bay, Calif. Write to him at email@example.com.