Programming codex

Build or Buy a CMS?

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 analyzes often reveals dangerous pitfalls and serious shortcomings 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 risks 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 organizations 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 meet the specific business needs of the organization.
For many developers, customization efforts quickly mean abandoning consistent architectures, or processes, in favor 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 thus 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 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 result is a template building system with extraordinary flexibility, enabling complex web applications including online catalog based shops, portals, and directories to be deployed rapidly, with no custom-ASP programming.
Some web development firms frequently promise to deliver a powerful CMS for an upfront 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 rollback: 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 organization 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 a system for managing template functionality, therefore change requires further development. The 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 other’s 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. The development of a sophisticated solution demands a clear understanding of all these layers.
Managing web-based applications and database servers running a customized 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 customized system. Working with pre-existing building blocks that are not properly documented, or are 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 the 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.
Customization 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 heavyweight 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 vision of the product.
Documentation is consistently organized, and growing as the system expands.
Online training is growing and becoming more sophisticated.
In comparison: Buy vs 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


Source by

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on whatsapp

Leave a Reply

Your email address will not be published. Required fields are marked *



Recent Posts