--special thanks to the Engine Room Development Team for helping me with all this info!
Running a company that provides web development services, and having been in web development for over twenty years has given me a wide-eyed and fairly objective view of the Content Management System (CMS) landscape. That wide-eyed understanding leads me to be very skeptical of any company or service claiming to be a panacea or some sort of “wonderful-website-builder”. If our website is the beautiful house that we want to build, a CMS is more akin to the type of materials or tools we are using, than the engineer or the skilled craftsman. The tool can be beautiful, but without the skill and knowledge to use itm it’s worthless. Same goes for a CMS.
But with that warning, let’s focus on the tools, and put the discussion of what makes a great web development team for another day (Incidentally, if you are unsure about what makes a great web development partner, check out our 10 questions to ask your development partner). I am often asked about the differences between CMSs. Usually, things like ease of use, security and affordability are the attributes that come into the calculus of landing on a CMS (no small decision). These attributes are usually secondary characteristics, or derived from, the architecture of the CMS itself. So, today let’s focus on the architecture of Drupal, to understand how it may or may not be a good fit for your team.
Built in Flexibility
Drupal provides out of the box flexibility through the very mature and robust Drupal Core. Drupal Core has grown over the years to incorporate more of the add-on modules that nearly everyone was using anyway. By swallowing these modules into the Core, we get a more dependable and centralized, and stable foundation. Here is a list of the core components. You will see most are built for moving, storing or displaying data for the website.
Most of our clients have websites that display a lof content in different places. For example, a blog article may have links to it and excerpts also displayed on a structured search results page. There may also be links to the article throughout the site as ‘related content’ or on a campaign landing page. Obviously, we want that content syndicated across the site without having to rewrite anything, or store information in multiple places (this drives non-technical content editors crazy). Drupal core provides modulus like Taxonomy for this purpose. Views and Views UI modules come in handy for filter views on pages (for example, displaying all articles about ‘how to save’ displaying in a Knowledge Center on a retail banking website).
There are also ‘collections’ of components for Drupal that may not be part of core, but are still grouped and maintained as one cohesive project. An example of this we have used is Drupal Commerce. While not yet a fully baked end to end commerce solution, Drupal Commerce provides core commerce functionality like Shopping Cart and Product Listing. Most importantly, it plugs in seamlessly with the Drupal Core, avoiding a disjoint Commerce Site vs. Marketing site experience. Keeping your shopping and brochure-ware experience cohesive leads to more operational efficiency and better SEO boost, among other values.
Back to flexibility: While there are a lot of Drupal Best Practices, there is more than one way to do just about anything, giving a lot of creative control to the developer, based on the business requirements.
For example, a page can be built on Paragraphs or Drupal content types or custom data collections, based on how the content needs to be used and displayed. You are not shoehorned into one Drupal Way of doing things. The flip side, is that the Drupal web developers must think a little more broadly and strategically. They must think critically about requirements, lay out pros/cons. It’s not just about the functional requirements of the site (the ‘what’). It is also about the non-functional requirements (the ‘how’). Things like scalability, reusability, performance, and security must be considered as well. For more on non-functional requirements, check out this nice write-up on FURPS+, a way to organize product features.
Admin theme out of the box is feature rich and easy to use
Remember, the view of the CMS , warts and all, that most of your company will see and interact with is the Admin UI. This is where most configuration will happen. More importantly, this is where all of the content editing by non-technical users will happen. Most of these folks will be on the Marketing team. In case you haven’t noticed the marketing team is not exactly twiddling their thumbs all day. They are likely overloaded by competing priorities, sub-optimal budgets and have no patience for a clunky experience when they need to add a new campaign or update a product line on the site under a deadline.
The Drupal Admin UI, while utilitarian, is one of the easier to use in the industry. It also can be ‘hooked into’ based on specific events or triggers. For example, when a new user views pages within a certain product category, say roofing shingles, their Salesforce record can be updated, thus alerting the sales team.
Furthermore, Workflows are part of Drupal Core. Let’s say you need legal approval whenever you update the Prescribing Information for a certain drug advertised on your site. A workflow can be set up so that legal must sign off on any changes to those pages (or content blocks) before they go live. Legal team members can be alerted via email when they need to react.
Developer-friendly Drupal Community
Helen Keller said “Alone we can do so little; together we can do so much.” Put another way, teamwork makes the dream work! When using the Drupal CMS, you become part of a community of thousands of Drupal Developers and Content Managers. Drupal has one of the strongest open source communities in the world. There are Slack Channels to stay up to date on security, email lists, forums and the like. Your developers will not be alone in the world of Drupal.
One oft-overlooked part of the critical path to building a new website, is migrating data and content from the old website. Drupal has many tools for doing this in a more-automated way (beware anyone who promises complete automation here. It does not exist!). For example, Drupal 7 has node export/import. Content Migration is made easier in Drupal 8, which has built in support for multiple methods of accessing data programmatically.. There are also third party tools, like Gather Content which have integrations for Drupal and other CMSs.
We have many clients who need content in a central repository that must be syndicated into different contexts. For example, marketing content that must be displayed in their mobile app, website, and in-store kiosks. What’s a developer to do? Using a Headless CMS strategy, you can use Drupal as that central repository, without compromising the user experience on the app or kiosk. Without having to do clunky workarounds like iFrames, you can free yourself from having to change the content in three places. Here is an example from Pantheon, our preferred Managed Platform for Drupal.
The CMS is just the start of the foundation for the Website. You will need to manage security patching, caching, logging, dev-ops and a host of other things. Enter managed platforms. A managed platform acts like a wrapper or, well, a platform, to support the CMS, so you don’t have to worry about a lot of the management of the CMS without paying for an expensive dedicated team. You will still need a web development team to write and manage code, and respond to issues, but a lot of the other stuff is taken care of for you. For example, Pantheon allows you to deploy code through their web interface, and even allows you to horizontally scale your site. Acquia also has similar functionality.
To summarize, Drupal is a mature, Enterprise-ready CMS, especially when used on a Managed Platform. Just be sure you have a development team experienced with , and knowledgeable of the platform so you can make the most of it.