I’ve dealt with a couple of companies in web media publishing over the last two years and if there is one recurring constant, it is that everything changes. Third party systems need to be integrated, new business requirements arise quickly or greater focus has (quite rightly) been brought to bear on the importance of data analysis.
For myriad reasons companies can run with a Content Management System (CMS) solution that is too tightly-coupled with their applications. This could be because they lacked the resources or there were members of the tech team who were particularly evangelical about some solution. Sometimes it’s come about because of time constraints and it’s always better to have to deal with that tight-coupling later rather than come to the market late. It more usually is caused by the initial conditions of the project being completely satisfied by the original design and at that time, while the architecture of individual components may have been done in a very clean manner, no strategy has been planned for decoupling the content management and the content rendering.
The real difficulty arises when the tech team is faced with the CMS itself becoming a blocker to progress. I’ve worked on projects which required very involved migration of content from one CMS into another as titles were merged or where it was already a legacy nightmare, worked on by various teams over the years, resulting in a total rats’ nest of interdependent modules.
War is declared
Over the next couple of posts I’m going to tackle this problem by first creating a very simple CMS/Web App, using spring, hibernate and a H2 database and then demonstrating how we can use a middle tier of lightweight web applications and a key-value store/NOSQL DB, separate out content for the web apps from the creation and maintenance of the content in the CMS or even shared out between several CMS solutions.
The code for each of the stages of this feature will be posted to gitub so do check back to see how I’m progressing.