Deciding whether to buy, build, or rent a content management system (CMS) is one of the most difficult decisions CIOs have to make. There are advantages and disadvantages with all of the three strategies. The long list of options can be confusing to the point that it may be difficult to decide where to start.

So how do you make the decision? That’s exactly one of the several questions I posed to two CMS industry experts: Jim Howard, CEO of Crownpeak Technology, and Jason Meugniot, Managing Director and CMS Practice Leader at Guidance. According to the experts, CMS success starts with having the right resources in place and understanding enterprise needs.

Ask good questions and assess development resources
TechRepublic: What factors should CIOs consider when deciding whether to buy, build, or rent?

Meugniot: The first question is: Do you have the right resources. Building a CMS without highly skilled software developers is risky and often leads to low quality systems that suffer from a lack of feature upgrades and timely enhancements. CMS build vs. buy evaluations typically start with a comprehensive assessment of in-house skills and support capabilities. If you choose to build your own CMS, it’s not enough to have highly skilled developers—you need seasoned project managers, designers, and support personnel. A CMS development initiative without the proper team and support infrastructure is likely to fail in the long run.

Consider the competitive advantage to be gained either by building or buying a CMS. For niche businesses with specific functional requirements, larger gains can be realized by building a custom application that aligns closely with your unique business processes. However, for companies with requirements that match those commonly associated with mature CMS packages, a custom solution will provide little or no competitive advantage. Here, an off-the-shelf product instead would offer greater advantages.

Understanding the long-term impact to the IT organization and the systems they support—whether built or purchased—is essential. Tech leaders need to answer the following questions: How will the CMS integrate with other systems? How will new requirements drive functional enhancements, and how will enhancements be realized? How are support infrastructures affected by market conditions or swings in the economy? Would a merger adversely affect the investment?

Howard: If the requirement is simply to enable a Web-page updating system on a site that doesn’t change frequently, or you’re simply publishing a content database to the Web, go ahead and build or consider a subscription system like OmniEdit, which is a browser-based WYSIWYG Web page updater.

If you plan on frequently changing the look, feel, and navigation of the Web site, a custom-built system may not be flexible enough to keep up. If you plan to add sites, push content to multiple places, or add multilingual functionality over time, make sure your custom system can handle these enhancements.

Is custom development really required, or is this just something cool that your development team wants to do? If you build a system internally, plan to have staff available for updates, modifications, etc. If an external firm is building a CMS for you, tech leaders should stay alert. Requesting simple changes could result in a hefty bill, unless the development firm already knows that these kinds of changes are likely to be requested. If you do decide to build, consider using a platform-type application as the framework. Buying a well-established CMS tool isn’t as sexy as building a custom CMS, but as project size and complexity increases, a packaged system is likely to be more economical and more successful. Rental can be a great option because support and implementation are normally included in the price. A turnkey, fully managed solution at a lower price can be hard to beat.

Why buy? Leverage proven technologies with a ready framework
TechRepublic: What are the advantages and disadvantages of buying?

Howard: CMS packages give your development team a ready framework to start with, letting you sidestep the dangers of fundamental flaws in the system architecture that might require a (costly) full re-build later.  You’ll also have access to features that you may not need today, but could well need over time (such as versioning, administration screens, task management, or reporting).  Additionally, if you require external help with the system, you can call upon experts who know it.

The biggest downside to buying a CMS is the cost of the package and, conceivably, the expertise required to work with the tool. In the past, some of the better-known tools on the market were difficult to work with. However, the better systems on the market today are largely standards-based. The market has matured, and is continuing to mature, so better products have emerged and major product flaws have largely been addressed.

Meugniot: You can leverage high quality software that closely matches functional requirements. When a CMS package can address 50 percent to 80 percent of business requirements with little customization, CIOs will be able to take advantage of mature technologies, cost-effectively.

However, buying a CMS offers companies little in the way of competitive advantage, especially for niche businesses with unique application requirements. If you’re looking to distinguish your business offerings, a packaged solution can be a huge disadvantage. Most packaged solutions offer commodity features that provide little opportunity to substantially increase competition based solely on a CMS investment.

Why build? Tailor-made to the way you want to work
TechRepublic: What are the advantages and disadvantages of building?

Meugniot: For companies with unique requirements that map directly to the bottom line, a custom-built solution can provide an enormous advantage: differentiation. Over time, however, custom-built applications tend to suffer from lower quality, primarily because you don’t normally get the quality, support, and return on investment offered by a mature, off-the-shelf CMS.

Howard: If you build a CMS, you can get it to work exactly the way you want it to. You won’t encounter any of the constraints built into packaged systems.

Building a full-featured CMS is onerous, but it won’t be so difficult if your requirements are well understood and relatively static. Also, letting your developers write software is likely to make them happy. Building is often taken to mean “start from scratch.” Still, some of the products on the market are more “framework” than “out-of-the-box.” A framework will have components that enable a development team to implement rapidly, based on the tool’s development environment. Open source tools often fit into this category, as do some of the commercial products that a development-oriented IT group is likely to select. When the choice is to build, using one of these environments can add structure and speed to the project—and possibly provide some flexibility over the long term.

The disadvantages occur when the project becomes large, or if the requirements change over time. The correct way to think of a “build” option is to regard it truly as “build and rebuild.” If you have a good handle on your build costs, and you are relatively certain that your requirements won’t change over time (a rare occurrence in the CMS world), you should be fine. Otherwise, building a CMS is like owning a boat; the cheapest part is the upfront cost. Also, it’s likely that only one or two people will really understand your custom code. If they quit, you’ll be left with code no one can support or extend.

Why rent? Lower cost, lower risk, and lower strain
TechRepublic: What are the advantages and disadvantages of renting?

Howard: The cost of renting a system is normally much lower than purchasing, installing, implementing, and managing a packaged system or building a custom system. Because outsourced systems are typically bundled with development, implementation, and support services, projects tend to have very rapid development cycles, based on rapid prototyping practices. This keeps the strain on a client’s internal teams very low.

The risk of an outsourced solution is typically lower than that for an installed product. First, implementation is likely to be quicker and simpler—and to be done by folks who are experts on the product. This reduces the risk of a poorly or partially implemented project. Second, a remotely hosted application means remotely hosted data and an additional layer of data backup. CMS applications hosted in the same environment as the Web site also don’t provide strong disaster recovery options, and the temptation is often to have only a single backup for both the site and the CMS. Outsourced CMS firms only keep their clients based on high service levels, so the risk of a distracted IT group providing poor service is eliminated. Finally, how many internally managed projects have 24/7 security experts on staff, monitoring the system against intrusions or other attacks?

However, not all CMS projects are suited to outsourcing. For example, an outsourced solution is not appropriate for high-security data. If the data you are publishing is not accessible to the public network due to security concerns, don’t connect via the public network to store or publish that data. An outsourced solution is also not appropriate for managing real-time transactional data.

For example, don’t select a remotely hosted CMS if you are publishing an extranet, and the bulk of the content is inventory availability, shipping information, and pricing data drawn from an existing back-office system. The public network creates a point of failure and could result in latency issues. Outsourced CMS firms have focused on the Web publishing aspect of CM, and while they will provide Web services type connectivity, these typically aren’t designed for tight integration with back-office applications.

About the CMS experts

Jim Howard is CEO of CrownPeak Technology, a content management ASP that provides content management as a service. Prior to CrownPeak, Howard spent six years working for Internet professional services firms W3-design, USWeb, USWeb/CKS, and marchFIRST, where he managed business development and operations, as well as the implementation of major content management projects for Global 3000 firms.
Jason Meugniot is a managing dDirector and CMS Practice Leader at Guidance, an application development and systems integration firm. Guidance helps companies improve the ROI of customer-facing Web initiatives that include content management, commerce, and customer management.