Caution to all readers, I’m about to make very bold, controversial statement, “Drupal may not be the right tool for every project.”Blasphemous, I know, but bear with me here for a minute. To believe that Drupal is the best fit for every project, forces us to begin every project with a fixed mindset. This can be a very dangerous perception, as we may start to view every project as a nail that requires a Drupal hammer. In doing so, we risk delivering a mediocre product that may not meet the actual needs of our clients. When deciding how to build a given project, it’s imperative to take a step back and make sure we’re not looking through Drupal-tinted glasses. That way, when the time comes to decide on Drupal, we’ll know it is the right choice.
At Genuine (the agency I work for), we implement a variety of frameworks to build out projects. To make sure that we’re using the best one for the job, we kickoff our projects by asking four questions. These questions, when asked, can help determine if Drupal is, or is not, the best fit for your project.
- Does the client or project need a software license?
There’s a long list of reasons as to why a client may need licensed software: regulatory and legal compliances or even company mandates. If a client requires a software license, then Drupal may not be the right fit for them. What about requiring an SLA? If that’s the case, Drupal may be an option in conjunction with a service provider such as Acquia.
- Does the client have a strong opinion for or against open source software?
This often goes hand-in-hand with the need of a software license. The client’s opinion about open source can play a big part in selecting the best framework to use. In most cases, clients may not have a preference or even know the difference. When they do, it is important to work with and understand their reasoning. The client may need to integrate with proprietary code or an internal system; in which case, a closed codebase would actually provide them better control. On the other hand, the client could be looking to leverage code from, and contribute back to, an open source community; in which case, with the active contribution community, Drupal might be the appropriate fit.
- What does the client like and dislike about their current system?
When building a project, we always set out to develop something better than what currently exists. To do this, it’s essential to know what the client likes and dislikes. If the framework implemented does not perform in the way a client expects or prefers, then, to them, there’s been a delivery of a bad product. There are a variety of frameworks – including Drupal – that are flexible enough to accommodate heavy volumes of workflows, but it has to be executed within the given timeframe and budget constraints. Drupal is a great option in this case, as its flexibility offered via community modules allow the platform to meet the needs of most projects requiring heavy lifting.
- How does the client plan to use internal resources?
There’s a bevy of instances in which a client can remain involved with a project, especially post-launch. Some prefer that the product be handled and maintained for them, while others look to perform maintenance, updates and even host the project themselves. Understanding what a client expects in the long term, can be a deciding factor in which framework to choose. Does the client want to leverage an internal .NET team without the need to retrain them in PHP? If so, then Drupal may not be the best fit. Is the client looking maintain the project externally on a long-term basis? If so, what resources will that external team have at its disposal? Deciding on and delivering a framework solution that works best for the staff assigned for the project’s upkeep is crucial.
The aforementioned questions are those commonly asked at the beginning of a project. And while each of us have our own partialities towards particular frameworks, it’s important to ask, “if we select to build a project on X, what will the result be?” By asking these questions, it’s easier to gain insight into the actual wants, needs and requirements of the project at hand. This allows for the selection of the appropriate framework based on the needs of the client and not on a preferred bias. Sometimes the answer is going to be Drupal, but other times it might not. However, it’s only when you place the needs of the project above that of a preferred framework that you are truly able to build and deliver amazing results.
As seen in Drupal Watchdog Magazine’s Spring ’17 issue