Build or Buy a CMS?

Creating a content management system either from scratch, or using pre-existing building blocks, may sound like the ultimate way to get the exact solution you require.

However, careful analyses often reveals dangerous pitfalls and serious short comings with many custom built content management systems.

In comparison to today's mature, tested and carefully designed products, most home-grown systems are quirky, poorly thought-out, and difficult to maintain.

However, even now many will seriously consider custom development. Like any IT custom development project, you could be taking on serious risk when it comes to delivering your project on time and budget, not to mention the downside of expensive support and the lack of upgrades in the future.

Two main reasons organisations choose to build

Perceived Flexibility

The decision to build rather than buy is frequently based on the assertion that no off-the-shelf product could possibly meet the specific business needs of the organisation.

For many developers, customisation efforts quickly mean abandoning consistent architectures, or processes, in favour of meeting seemingly complex requirements. Such an approach is short-sighted, paying no respect to the need for change, and a consistent model to ensure scalability, security and true-flexibility.

In reality, the information management and publishing requirements of a broad range of possible applications can be successfully contained in a well thought out system. If requirements are found that do not fit the system, instead of developing at a tangent to meet some specific unusual need (and thereby creating an island of development investment), we rather prefer to adjust the system, so the need can be met predictably again and again.

With that in mind:

• .A good CMS should offer a dynamic Information Store that allows any conceivable structure of content to be created. Any number of meta-data fields can be defined and complex database record structures can be configured, enabling structured data to be managed with the same ease as free-form articles. All this without any custom programming, and in a consistent interface for managing information.
• The template system must truly separate presentation and content, and eliminates the need for any programming in order to create flexible page functionality. This may be made possible through a system of Skins (the HTML) and Views (the rules that bind information to presentation), and some form of rendering or mark-up language.
  The end result is a template building system with extraordinary flexibility, enabling complex web applications including online catalogue based shops, portals and directories to be deployed rapidly, with no custom-ASP programming.

Cost

Some web development firms frequently promise to deliver a powerful CMS for an up front cost that may sound attractive.

It is a well known fact that IT development projects frequently run well over time and budget expectations. Heading down the custom development path is almost guaranteed to result in project blow-outs, missed deadlines, and unexpected complications.

Close examination of many custom CMS implementations reveals serious oversights in the design of the publishing engine and the flexibility of the system.

Considering a robust product based solution represents many person- years of development time, it is little wonder a comparable custom system cannot be constructed in a matter of a few weeks or months from scratch.

For example, many custom-built systems lack the following important features:

• 100% audit trail and roll back: Quickly built custom systems frequently present live database records to the web site visitors, rather than versioning approved content, and moving into a flat file format that can be more quickly served, with less load on your live web server.
  This is risky from a security point of view, and could leave your organisation exposed to unnecessary legal risks because of a lack of historical data on your web site publishing.
• True separation of presentation and business logic. Instead, templates are custom built with programming code, and presentation, in a single page, creating a tightly inter-dependent code base that is complex to maintain. Design changes need to be made by programmers rather than designers, meaning the cost of change is time consuming and expensive. There is system for managing template functionality, therefore change require further development. Cost of ownership rapidly escalates as the inevitable need for changes continues.
• Consistent user interface for managing different structures of information, or content. Instead, many systems bolt-on separate modules, that don't truly integrate into the core platform, function differently, and don't work with the same security or publishing model.
• Integrated security, down to the field level. Unless there is a consistent model for managing user permissions across all aspects of the system, security is difficult to manage, let along understand.
• True support for concurrent users, with proper record-locking, and item check-out. In a complex web based client-server environment, proper management of concurrent attempts to edit information is critical to ensuring authors do not stomp on each others work.

The face of custom development

Heading down the custom development path is not for the faint hearted.

• Custom development is time consuming, and requires considerable diligence in scoping and planning requirements to avoid becoming an iteratively resource hungry monster.
• Web development is not like building desktop applications. The nature of the Internet creates inherently complex requirements from a client-server perspective. There are many layers of technology ranging from client-side browsed based code (such as DHTML, JavaScript, Flash) to Server-Side languages (VBScript, Jscript, PHP etc), query languages and procedures (SQL), server components (C, Java, VB) and more. Development of a sophisticated solution demands a clear understanding of all these layers.
• Managing web based application and database servers running a customised solution is more complex than managing a documented product.
• Testing on different platforms, and loads, can be extremely time consuming.
• Documentation may never be written to cover 100% custom systems, or elements of a customised system. Working with pre-existing building blocks that are not properly documented, or are really only code libraries, can be as time consuming as building from scratch.
• Support for a non-standard custom system can be painful to extract, and expensive to continue.
• Maintenance is more complex, more time consuming and more likely to be fraught with the problems of undocumented functions, that have been long forgotten by programmers that have moved onto other projects.

Working with a proven solution

Better CMS products are not merely tools, or a collection of loosely defined modules. They are proven, solid solutions, that can be installed and operated out of the box.

• Deploying a product leverages the expertise of a team focussed on development of a solution that has enjoyed the attention and tuning of thousands of hours of development.
• Through minimal levels of configuration, a good system can meet the content management needs of a broad range of applications.
• Customisation of your business presentation layer is fast, thanks to a well defined flexible template system that is managed by the product.
• Deployment times are typically weeks not months, and cost a fraction of the product license cost ? not a multiple of it ? like some so-called heavy weight solutions.
• Training and support, plus the on-going commitment to provide you a working solution that can grow with your needs, is a core part of the products vision.
• Documentation is consistently organised, and growing as the system expands.
• Online training is growing and becoming more sophisticated.

 In comparison: Buy vs Build

Buy

Build

·         Lower cost of ownership

·         Higher cost of ownership

·         Rapid deployment

·         Lengthy deployment

·         Rapid integration

·         Slow integration

·         High level of functionality

·         Low-moderate functionality

·         Easy to use and maintain

·         Harder to use, complex maintenance

·         Follows best practices

·         Custom design may be poor

·         Features you could never afford to build

·         Lacks sophisticated features

·         Committed support

·         Contingent support

·         Upgrades and improvements

·         Limited or no upgrades

·         High quality

·         Low Quality