Good Drupal leadership begins with a good plan. A good plan requires a vision specific to its particular business. Drupal, like any software, is a tool that empowers an organization to build its vision and address its business requirements. The fact that a Drupal website/application consists of Drupal core, with contributed modules and themes, that are glued together using custom code, creates a unique set of challenges to ensure each aspect is done right.

Drupal is both a Swiss Army knife with a massive variety of tools and a set of Lego®-like building blocks used to compose a custom and ideally optimized solution that addresses each and every business requirement with precision. Drupal is highly flexible, and presents a variety of options. Having a plan is essential - without one, an organization could find itself in a pickle with an unstable and insecure website/application.

Recognizing that Drupal provides flexibility helps organizations work towards a plan for building and maintaining a stable website.

Drupal is a modular framework that allows developers to add and remove features as needed. There are several ways to solve common feature requests and dozens of ways to enhance existing features and functionality. Drupal's flexibility is one of its strengths that in turn requires effort to ensure stability and maintainability.

Drupal core provides a stable code base to build from, but as contributed modules are added to a Drupal stack, each module has different levels of support and stability. Realistically, regressions and issues will inevitably occur when updating Drupal core and modules. If a regression is caught before it is pushed to production, I think it’s reasonable to reconsider labeling it a regression or just part of the process of updating Drupal?

Since every module in Drupal is free to use with varying levels of support, this frankly translates to "use at your own risk." Each Drupal website/application is taking on a certain amount of responsibility to ensure the maintainability of its specific implementation as it applies to Drupal.

Guaranteeing maintainability is an ongoing process that requires planning. It’s important to make sure that each step forward doesn’t create a situation where you’ll have to step back. A Drupal website/application can create a lot of technical debt if a thoughtful plan and process are not established to implement and update modules and themes.

There are several planning-related tasks to consider to leverage Drupal's flexibility while ensuring its stability and maintainability.

Good planning is essential to a successful enterprise implementation of Drupal. A plan begins with defining the requirements and understanding what is and is not possible. With Drupal, I like to believe anything is possible. Still, teams need to ask if it makes sense to solve a particular requirement using Drupal, or if an outside solution should be used and integrated into Drupal.

Defining the requirements while recognizing potential challenges and solutions is, and should be, a constant collaboration with stakeholders, architects, and developers. This process leads to documentation.

Let's openly admit that Drupal does not have the best documentation. It is something many people in the community are actively working on. Anyone overseeing an enterprise Drupal implementation needs to take ownership of their internal documentation and contribute to Drupal's overall documentation. A module or core update will inevitably cause some regression, and every module regression should be documented to capture the problem and remediation. Most regressions are solved via the issue queues on Drupal.org; therefore, an organization should contribute to these discussions.

My best anecdotal and microcosm experience when it comes to documentation happened as I built out the Webform's module user interface and user experience. I concluded that every single configurable setting should always have a description. Including descriptions ensures that everyone, including developers, understands the scope of a feature. My conclusion is you can never have too much documentation, as long as it is organized and easy to navigate, especially with open source software.

A lot is happening in the Drupal community and also via an organization’s enterprise implementation of Drupal. As documentation provides a record of what is happening, it is equally important to communicate what is happening. Communication can occur via monthly internal meetups or newsletters, which can keep an organization's Drupal'ist up-to-date on events and trends in the Drupal community.

Good and honest communication creates solid relationships between team members and business owners. There is no shame in communicating when there is a mistake or problem with a Drupal website/application, especially when there is a process to fix issues and solve problems in conjunction - it can only help and lead to an improved experience for everyone.

A plan is only as good as the process for implementing. My next blog will explore "What is the process for building and maintaining a Drupal website/application?"

Do you have a plan that worked like a dream, a wish list, or ‘what not to do’ recommendations? I would love to hear people's experiences, thoughts, and suggestions on how best to plan a stable and reliable Drupal website/application.

Image provided by Wikimedia commons and taken by Doug Coldwell.