Drupal occupies a strange place in the web framework landscape. It’s not a pure framework, like Ruby on Rails, Symfony or Zend Framework. Nor is it just a CMS or blogging product with the ability to host plugins, like WordPress. It’s somewhere inbetween, giving the developer a fully functional CMS as a platform but providing many of the flexible basic services and abstractions that would be expected in a more generic “framework”. <!–break–> For this reason, talking about “architecture” in Drupal can be confusing. From one perspective, Drupal is the architecture. To consider this properly, let’s unpack the metaphor:
When we talk about system architecture, we’re talking about the bits of the project that aren’t going to change, or will change only very slightly, in response to feedback and information gathered during the project itself. The architecture is the stuff that we can rely upon to remain true for a long time. In this sense, the metaphor with building architecture is very accurate: when planning a new house or office block, we begin by figuring out where the walls, foundations and windows will go, and how the heating, power and water will be provided - we don’t worry about what colour to paint the walls, or whether to have carpet or wooden floors (in a Drupal project, this kind of thing is handled by the theme). And on a Drupal project, the main fundamental part is, well, Drupal. It defines how the user permissions system works, how content is stored in the database, the entire operation of the presentation layer, and with a few additional modules it can also define a lot about how integration with other systems works too.
So if Drupal gives us an architecture to work with already, do we need architects on Drupal projects? My answer is a tentative yes - there’s clearly a need for architects to design the overall system, of which Drupal may be only a part. And the other parts of the system, which are built from much lower levels of abstraction (say, on top of a Java framework) will need architects to design them. But when working with Drupal itself, the job of the architect is different from these other cases. If an architect tries to plan how a Drupal site should operate from first principles, he will be wasting a lot of his time since many of these decisions have already been taken - and tested in the real world - by others in the community. The job of an architect on a Drupal project is not to design but to understand how to get Drupal to do exactly what is needed in the most efficient way possible.
An architect with little knowledge of Drupal may look at the requirements for his system and say “aha, we need a service for querying large amounts of information from an external data store”. A more experienced Drupal architect would say “aha, we need to use Views, Schema and Table Wizard”. The experienced architect knows that contact forms can be done easily via Webforms and don’t require a custom module. This seems obvious to experienced Drupal developers, but it really is a quite strange concept to developers and architects from other backgrounds who are used to building applications from extremely flexible basic components.
Consider an organisation that needs to have multiple contact forms, allowing users to submit different kinds of information on each. Using something like Zend Framework, this would involve writing code to generate each form using ZendForm, enforce validation rules using ZendValidate* classes and ultimately send the submissions via ZendMail. Now, each of those components is well-architected and de-coupled, and each can be subclassed and replaced easily. Zend_Mail has various implementors for different mail transports and encodings - it’s a very flexible library. But the amount of effort required to implement even a very simple user story with ZF is considerably greater than the effort required to do the same with Drupal, because Drupal provides pre-built architecture for this very common web pattern. In ZF, each form will require a separate form class which contains all of the form element definitions, labels, error messages and validation rules - and that’s before we consider the possibility of administrative users adding extra form fields without any code changes. In Drupal, the entire set of user stories is handled by the Webforms module, with little or no code to be written at all. Thus the Drupal architect’s greatest asset is the knowledge of the patterns already implemented by others, rather than the ability to produce designs of how to re-implement this system from first principles (which would probably end up looking something like the Zend Framework example, and would take as long - or longer - to code).
This example explains why Drupal is different. Other frameworks value - correctly, in some cases - flexibility over functionality. Adherence to the formal structures of object-oriented (or perhaps that should be called class-oriented programming) is prevalent here. This can make these web frameworks extremely flexible, with every component pluggable and replaceable, with intricate inheritance trees providing - in theory - code reusability. But in practice, Drupal’s approach of providing the developer with a set of prefabricated components that satisfy 90% of the likely user stories is simply more productive. Reusability is achieved by having modules that implement large chunks of functionality, with the potential to inject new functionality or override behaviour via Drupal’s aspect-oriented hook system. Whilst this might feel limiting to a design purist, it is an extremely pragmatic way of building high-functioning websites; quite simply, it’s easier to tweak the pre-fabricated components than it is to build new ones. When properly understood, Drupal allows architects and developers to skip ahead in huge leaps, building on top of the components already provided, focusing all efforts on the new and unique parts of a project, where those efforts are truly needed. This does mean accepting a limited scope for the architect, but this limited scope can be traded off against faster delivery and more time for in-depth consideration of the newest - and, by definition, riskiest - parts of a project. Architects can still add value and get satisfaction from solving the truly difficult problems.
So, my answer to my original question is that Drupal projects do need architects. But they need to understand that they’re not designing the whole system from the ground up - they’re designing only those parts that aren’t already there, and their greatest asset when doing so is their understanding of how the existing parts work.Share