Is separation of responsibilities always the best solution? Why would I even ask that question? Of course the answer is yes. Except for the fact that separation comes with a cost. Separation takes more time to implement. It makes the application more complicated. And it expects there is going to be a need to modify something in the future…a major point of separation is future proofing.
Let’s say you have an application that is a simple, standalone tool. It will never handle large amounts of data. There will not be any need to create new screens or reports from the same models. Perhaps this application already exists. Under these circumstances I would say an existing application, if it works correctly, doesn’t need to be re-tooled to follow code separation standards.
There is a whole niche market of decision support developers providing tools for different unique needs, developing them quickly using 4GL type tools. Typically, these tools do not separate layers, although many have moved in that direction. From a pragmatic standpoint, I’m not sure it is really relevant. Most likely, a tool that has proven its value through a Decision Support implementation will not be upgraded to an enterprise design. It will most likely be re-designed from the ground up.
The fun part is when you need to take over a decision support app that was created quickly. Often, a customer who remembers creating the first version will not understand why additional time and money are necessary to create an application capable of higher stress than the average decision support app.
Have you taken over decisions support sytems? What was your experience like? Share your comments or drop an email to btaylor@sswug.org.
Cheers,
Ben