Should we build it with Drupal? (Or Drupal 8?)

Joshua Lieb, Product Strategist

As Drupal becomes an increasingly popular development framework for public sector websites and platforms, the answer to the question "Can we build it with Drupal?" is often a given. In fact, I explored that question in my previous blog post, concluding that, in most cases, we can build it with Drupal (whatever "it" is).

That's a relatively easy answer, as evidenced by the vast array of government sites. But if you want your Drupal project to succeed, you need to ask a second question: Should we build it with Drupal?

Is Drupal right for your project?

Let’s look at a case study.

A large government client needed an HR application that would be used to manage the review, selection, and vetting process for employees. The new application would replace a set of legacy systems that were written in a couple of different languages, and it would digitize a number of complex review processes that previously had been done offline using Excel spreadsheets and custom querying tools.

We knew the client favored Drupal for this project - we had worked with them on several large-scale Drupal projects, so institutional support was already in place. However, several red flags popped up immediately, and we proposed to start with a Discovery phase to assess the technical architecture. We wanted to see if the answers to "Can we build it with Drupal?" and "Should we build it with Drupal?" would match.

Drupal is node-centric. Are you?

When I am describe Drupal's modular framework, I often use a fractal hub-and-spoke metaphor. If you think of Drupal core as the central node in the larger universe of contributed modules, drawing links to the most common and widely used "near core" modules, plus links to modules related to those modules, you start to see a network emerge. Drupal core is at the center, orbited by Views, Context, Features, and similar "near core" modules, surrounded by concentric layers of modules used less frequently. 

This architecture is node-centric: the central architectural assumption is that the node is the base unit of content. By and large, contributed modules have at this assumption at their core - they extend the node, they operate on the node, they display the node, etc. If you find an interesting module that does something central to your goals, it’s likely going to be working at the level of the node; entities, users, taxonomy terms, and another objects in the system can’t leverage code in the same way.

In the case study of the HR application, we used entities to represent each candidate. Unfortunately, this decision meant that we couldn’t use existing workflow modules like Workbench (since those were node-centric). We had to write custom code to do very basic things, despite the fact that pre-existing modules could already do those things. Had we been able to use node-based content types, this would not have been an issue.

So, what can you do to avoid a similar dilemma? Compare your project or product to the marketplace. If there are Drupal sites with similar functional profiles (sites that already do what you want your site to do), it’s a good bet that your site won’t be breaking new ground, architecturally speaking (and this is a good thing!). If there aren't many examples, then you may need more time to understand the architectural implications of your project.

Red flag requirement examples

From a Drupal point of view, what types of requirements should raise a red flag?

Some examples from our case study: 

  • Transactional reporting: Our clients needed to be able to capture information at every stage of the review workflow. Because our system was built on entities, we were forced to build the reporting framework entirely from scratch. If your requirements for reporting are that granular, there’s a good chance you’re generating custom logs based on actions specific to your use case, making it challenging even when you can use nodes.
  • Custom queries: Because visibility into the ongoing candidate review process was necessary, the admins were used a lot of custom queries with their legacy system. However, Views was not really suitable for this type of querying, and simply writing SQL queries wasn’t feasible either. Drupal’s underlying table structure is built to allow for extensibility, not simple query writing.

These were important requirements, and there were reasons why they needed to access the data in this way. That said, just about everything we did to meet these requirements required custom code, flattened tables that duplicated data held elsewhere, and extensive user testing and iteration. 

It's also important to consider the implications that requirements have on each other. In isolation, you might flatten data for ease of reporting, but if there is a requirement that users be able to view a log of edits (for example), you need to either store user information or write custom functions to pull that data when your reports run.

Can we use Drupal 8?

Who doesn't want the latest and greatest? Answering this question requires taking a look not only at what you need your product to do, but also to the larger picture of how you plan to build and support it. Just as Drupal 7 offered new features and capabilities that opened up entirely new use cases, Drupal 8 will do the same, and it will be tempting to jump forward. Still, it's crucial to think about whether your project and Drupal 8 fit each other.

As a general rule, right now Drupal 8 makes particular sense for two types of projects:

  • Where the core objectives and architecture align closely to Drupal’s core strengths
  • Where the core objectives of the site depend on the new features offered in D8. For example, Drupal 8's omni-channel capabilities would be a good fit for a platform requiring diverse publication paths.

In both of these cases, though, you have to be prepared to invest time and resources. You can’t estimate the work based on how you’ve been building with Drupal 7. Learn how to mitigate risks with Drupal 8 in Michael Le Du's recent blog post.

Assessing your architecture

A historical note on our case study: this was undertaken very early in the Drupal 7 release cycle and was one of the first D7 sites we built. In fact, when we started working out the architecture of the HR application, it became clear to us that for various reasons nodes would not be suitable, and the only way we could proceed with Drupal would be to use Entities, which were new to D7. This presented some challenges.

To return to our hub-and-spoke model, the further down the spokes you go, the less stable and mature the intersections between modules gets. And the longer the distribution is out there, the more code is contributed to knit the downstream modules together. For example, there are any number of field types available - for addresses and locations, geo co-ordinates, dates, media files of different types - and because the Fields and Views modules and APIs are so mature, they work well together. Add a field of this new type, and you can query on it using Views.

In our case, because we had decided to use Entities, we needed to build a lot of connections between common modules and Entities. It was work that wouldn’t have been necessary two years later.

Be prepared for extra work

If you decide to use Drupal 8, your project plan will need to account for some extra work. In our example case study, where we chose to use Drupal 7:

  • We needed to account for the time required for developers to ramp up on the new version. This was a valuable investment for professional development, but it took a considerable amount of time. Find ways to amortize this investment (book some time to a professional development budget, for example, to keep the project budget focused and tight). For Drupal 8, themers will need to learn the Twig framework.
  • Many contributed modules did not have stable production releases when we started, and we had to spend extra time debugging and contributing patches.
  • We were guinea pigs - we didn’t have models and examples of how to do things so we had to prototype and iterate, and our initial estimates needed to be constantly recalibrated.

Sometimes it shouldn’t be Drupal

There are many reasons why you might choose not to use Drupal, even if it's capable of meeting the basic business and technical requirements:

  • Functional architecture might not be node-centric
  • Requirements may require too much customization, or may be too restrictive
  • Institutional or contractual constraints

Of course, this is not to say that these conditions should always preclude you from using Drupal. They should simply cause you to either rethink using Drupal, or rethink HOW you use Drupal.

Joshua Lieb

Product Strategist