In previous posts on content granularity I discussed the trade-offs in the level of content granularity and tips for RedDot, Sitecore and Ektron. To conclude this series on granularity I would like to share a scenario of two firms who are upgrading their web content management software.
Both organizations deployed a content management solution in the late 1990’s. The first selected a commercial product, while the second firm contracted programmers to custom build a content management application.
Come early 2007 and both firms are looking to upgrade their current platforms. A major driver is to improve the job board functionality that they provide to their customers. Having undertaken a serious evaluation of the available products, both firms selected (different) content management products. The job board functionality required by both organizations is to:
- allow their customers to post job opportunities
- allow potential candidates to apply for the job
- report on the job/application status
- port their existing job data from the current system to the new one.
Firm A, with the existing commercial product, had designed their job postings to have a low level of granularity. Firm A’s concept of a job was a description, company, opening and closing date – a low granularity. Firm B, who used a customized solution, implemented a highly granular view of the job posting with over 20 separate fields for each job posting.
Because of the highly granular information maintained by Firm B, a programmer was able to create scripts to automatically migrate the 5,000 existing jobs to the new system. The total time taken was 5 days. Firm A, with the unstructured job posting could not automate the process. Instead content authors had to manually examine each job posting and re-enter the information. Firm A’s database of 2500 jobs took 2 people almost 3 weeks to move to the new system.
The earlier decision by Firm A to implement a low granular job posting cost them 6 times the effort of Firm B, to migrate only ½ the number of job posts.
The lesson is that long term plans for your content should be considered. If the content is going to have a long shelf-life, the uses for the content and the systems using that content will change. Taking a longer term view will introduce some extra effort in the beginning, but it would have saved Firm A, the 6 man-weeks of repetitive copying and pasting of content.