There we are – writing applications for a vertical market – we get some specs, we have to understand what the business people want from us and then we have to implement it. After a while we’re done with the application and then the business people find out it’s not what they wanted. Where did we go wrong? Sometimes it’s the business analysts/developers that did not get it right, sometimes the vision of the business people/process owners is not clear enough. Who knows. I think the question should be ‘what can we do so there is an easy way out of that situation’? The second problem I see is that once an application is deployed in the business world the requirements change – a new marketing strategy, new laws or just another company policy may require changes. We have to go back and change a running system, retest, redeploy, etc. My question again: What can we do so there is an easy way out of that situation?
This brings me to the following observations:
- Business users like to change stuff around
- Business users like to modify text and marketing information (especially if it’s customer facing)
- Small to medium changes are required over the lifetime of an application to adapt to new situations
If we do not want to engineer ourselves into a corner and end up with work that we do not want to do in the long run we have to find a solution for the above requirements. Those requirements translate into the following for me:
- Make sure an application can easily be deployed
- Give the business users a tool to change the appearance of the application
- Use a DSL, XML structure or properties file to drive most of the application
Some of the projects we have done in the last two years are web based applications. I found by using a CMS or WCMS system such as magnolia we can build on a solid foundation that takes care of 1). We then store all properties used for the application in the content management system as well sattisfying 2) and we added a form renderer and task engine to the CMS in order to sattisfy 3). We also get full access management through the CMS and since magnolia is based on jackrabbit (JSR-170 compliant content repository) all content is stored in a way that other applications can access it as well.
Things that became easy to address because of magnolia as a base framework:
- changing any text on the site
- moving pages, form elements tab orders, validation
- changing the look of the site
- error handling
- rewriting all form pages to support ajax
- implementing the forms in a different framework
- allowing form handling for different browsers in different technologies
- staging to life deployment through an activation and review process
This list is not complete – by choosing a CMS and implementing the required functionality on top of it we are able to move a lot of the work that seems to come up because of misunderstandigns between the business users and the developers into the hand of the business users (they can take action themselves) or make the change easy for the developers (it’s just a property or two to change in a UI instead of having to change it in code, recompile and redeploy).
I’d love to hear from you what other approaches you take to solve this issue.