I've recently become involved in a project with a very clear idea of its functional and data requirements - so much so that the presentation technology has been selected and the database vendor and schema determined. The suppliers of these have also been chosen and brought in. So, you've got your data, you've got your user interface, all you've got to do is connect the two.

At first glance the omission of an application tier is just an oversight; the majority of functions can be delegated to the database: little more than a bit of remoting and a bit of transformation. On closer inspection it becomes evident that the hole between the presentation and the data is more than just technical. In fact, it's a dumping ground for all the requirements that didn't fit neatly into either of the other two. It's the region in which misaligned assumptions are going to be magically ironed out. For example, the presentation tier assumes (or at least prefers) synchronous calls whereas the database would be better addressed asynchronously. Sure the app tier could hide the asynchronous nature of the database call from the presentation tier but that's simply patching over the hole.

In reality, the omission of the application tier is a clear sign that the exciting technology choices have led to a project starting without a clear system architecture. It sounds to me like another case of trying to introduce architecture during implementation.

I'm not sure you can architect and implement at the same time - there are always some aspects of the architecture such as technology, team and methodology selection that need prior thought.

Add a comment

Posted by Kevin Seal on 24 September 2007 16:05:32 BST #