Is it better to model the business around the software or the software around the business?

This is clearly the era of information overload. But the overload doesn’t stop for the end users of the web; it is also overload for those who are tasked to maintain the content. Thus, a problem exists: How can all this content get managed in an orderly, sane way without losing the dynamic nature of the information and the industry business model.

The market is saturated with software products to help manage content. I can’t help but asking, with all the emerging business models of syndication, co-branding, re-branding, premium content, etc, how can any package keep up? On the other hand, how flexible of a programming model can an IT shop build to accommodate a continuously progressing business model?

A dilemma indeed. It was assumed for many years that buying a package was the cheaper, faster way to deploy. Studies shown in the last several years show that buying a system can be much more expensive then building from scratch. “I’d say that the buy- build cost ratio is 3:1in terms of cost,” says Joris Van Dan Eeckhaut of Navint Consulting, a Pittsburgh-based management consulting firm.

What causes this ratio is a complex and curious question. When these content management packages are being evaluated by potential customers, many people tend to get seduced by the myriad features that the software has, look at the licensing costs and believe this is the final cost.

The hidden cost for package implementation comes from the nature of vendor software as much as it does from not understanding how the package will effect the organization. One of the largest costs for a company to absorb is the reworking of business procedures – which is almost certain to happen with the implementation of packages. Work flow has to change, processes adjusted or completely uprooted, data needs to be converted and a host of unforeseen events.

Software vendors try to reach a vast audience with their packages, so they tend to add a huge amount of functionality. Often much of this functionality cannot be used by an organization. This often leads to systems that are complex to use and require a great deal of training and learning curves.

According to Van Dan Eeckhaut, “In best case scenarios, I’ve seen packages that will solve approximately 80% of the business needs of an organization.” This means building stand-alone applications to meet the remaining requirements – or worse- living without that functionality- at the mercy of the vendor until they add the functionality. Vendors will often offer to customize the software or perform training, but generally at top dollar.