The end of database-centric design?
By Sean Mc Grath
As I write this, it is early June. Early June is a period that strikes fear into school-going Irish teenagers as it ushers in the season for high tension, high drama, all-or-nothing examinations.
For those taking examinations in the Irish language at this time of year, two words are sufficient to drain the blood from their faces. The words are "conditional mood" or, in Irish "modh conniolach".
The conditional mood in the Irish language is a grammar tense used to express something that may or may not happen in the future. It causes irregular verbs - which are hard enough to deal with at the best of times - to go completely ga ga.
It struck me that I spend a lot of time in this future conditional mode of expression. Not in the Irish language but in a variety of computer languages. Like all other enterprise application developers, I worry a lot about how to deal with things that may or may not happen in the future. It's hard. Indeed, unlike natural languages, the mainstream languages that are used to talking to computers do not even have a way of expressing "may or may not happen".
It is as if programming languages are basically stuck in the present tense. In other words, given this set of circumstances, right now, do the following things. Unfortunately, As we all know, when the set of circumstances changes, programs cease to function and require the application of that great misnomer 'maintenance'. A costly exercise.
Perhaps programming languages of the future will give us modes of expression for handling the unknown, the change which typifies business processes. Until that happens, if it ever does, we need to proactively take steps to prepare for the inevitability of change in our systems. We have a word for it - flexibility.
Looking across the vista of enterprise applications, one word stands out as being very problematic when it comes to flexibility. That word is 'database'. A working database is essentially a set of nouns and verbs created to model a business process in the present tense. What happens to the database when the business process changes? We typically see a technology meltdown. Tables need to change which means that the data entry screens break, the SQL statements break, the business logic breaks, the reports break etc. Database's are something of a flexibility train wreck. Can we do better?
Back to Irish language students for a moment. Students of the Irish language, when faced with the complexities of the conditional mode, soon pick up a trick. By using more words than strictly necessary - by adding a level of indirection - they can avoid the need for the conditional mode. It's not beautiful but it works. Beauty and raw speed are sacrificed in return for getting the job done.
Is there an oblique lesson there for enterprise application development? I believe there is. The levels of indirection take the form of loose coupling between the component parts of a system. Is it less beautiful? I don't think so, but beauty is in the eye of the beholder. Is is slower? My answer to that is "who cares"! This is business not computer science. If I need a few more Linux machines to speed up my loosely coupled systems I'll buy them from petty cash. CPU power and RAM are cheap. A darn site cheaper than ripping up my database application all because I need and extra field in the customer record.
Perhaps it is time we started asking the ultimate question about databases as classically deployed. Do we need them? Given the difficult of making them respond to change, can we afford them? Are there ways of doing what a database does that are perhaps less optimal but that handle the inevitability of change gracefully?
I believe we are seeing a deemphasis of database technology in enterprise application development. Look at architecture diagrams for Service Oriented Architectures, for Agile Processes or for asynchronous web services. There was a time when most IT architectures for business featured a database holding pride of place in the center of the diagram.
Not any more. Why? Because we simply cannot afford to design for the present, when everything, from tomorrow onwards, is the future.