Future of Architecture: The Template

I remember like it was yesterday the day I was sitting at my desk back in 2005, watching the now famous Ruby on Rails screencast on how to create a blog in 15 minutes. It became the first screencast hit as far as I can tell.

Three years later and after a lot of personal reflection I've boiled Rails' success down to two reasons:

• It's based on a dynamic language (Ruby)
• It's a very successful architecture template

If you want, EJB 2.x become popular because it also enforced an architecture template. Grails followed Rails' lead and created an architecture template for Groovy/Spring/Hibernate/Java. AppFuse does a similar thing for web frameworks: it creates a hit-the-ground-running project template. So does Seam.

Typical for EJB, Rails/Grails, AppFuse and Seam is that you start with a re-usable infrastructure that's configurable and where you plug in your code. Rails/Grails are particularly interesting because they require very few choices to be made by developers.

These architecture templates are the future. People obviously like them a lot - if you consider for a moment EJB 2.x in its historical context. While the bashing Spring has caught me by surprise I now believe to have found the reason: Spring doesn't really offer a template (although Spring 2.0 and 2.5 do go a long way), or not enough effort is being done to put Spring in a template dress.

These templates are popular because of their mental bite size. But they're important for another reason too: they're true, reusable building blocks for architects. You have a complicated application, but building an administration console is easy with Rails/Grails/Seam.

What we need are more of these templates, in more domains. After all, re-using these templates not only drives down the costs and development efforts, it also reduce the amount of code that has to be written, thereby reducing the chances of introducing bugs, reduce testing and maintenance, ... .

Here are some domains where templates do not exist but where they would make a lot of sense:

• Batch: a template framework for plugging in batch code. Spring Batch would be an ideal base for this. It would provide a management console, configuration console, monitoring, reporting, event log, alarm log, ... out of the box.
• Web services: a template framework for plugging in application code. This template would be the deployment unit and start for applications that expose web services. It would provide message logging, JMS integration, authentication, authorization, event logging, administration console, message conversion, ... all out of the box. Spring, Spring Web Services and Spring Integration could form a good base for this. (Note: I don't mean a SOA orchestration framework)

Here are some other template frameworks that you may not yet have heard of:

• EventGnosis: a free (but not open-source) framework for handling monitoring events
• JMatter: an open-source framework for creating CRUD Swing applications (also check out this interview)

One interesting thing to notice about all these template frameworks is that apart from Rails none of the ones I mentioned generates code which you're not expected to modify.

Happy architecting!