Drupal Discovery Game Plan

When building a game plan for discovery, you may have a fairly strong process in place with a series of elicitation, analysis, and specification techniques. You might even use a requirements engineering tool in order to model and map these requirements as the project evolves. Assuming that you have a basic understanding of this process, let's discuss a unique perspective in order tackle the process of requirements gathering in a new way.

First, let's discuss the end goal paradigm, or rather—the perspective you would need in order to review a system after the work is completed. Technical auditors offer a unique perspective on this, and some of their constraints when performing a technical audit are a great jumping-off point for this discussion.

Auditor Contstraints1

Am I able to audit this?

  • Technical proficiency consists of:
    • Experiences in delivering technology;
    • "Horizontal" cross-cutting knowledge of all technical aspects of websites;
    • Constant training on the latest technical trends applied to Drupal Projects;
    • Acknowledge gaps in knowledge and subcontracting accordingly.
  • Business proficiency entails "vertical" knowledge of the business in which the website under audit is deployed.

Am I free to audit this?

  • To avoid conflicts of interest:
    • Never provide maintenance or other implementation services directly after you have performed a website audit;
    • Never audit code by a company with which you have a personal or commercial tie.
  • Avoid selective blindness by never auditing code you have previously delivered.

With that said, let's dive into how constraints can be leveraged as strong tools when building out your solutions architecture.

Diving in: Business Proficiency

First, you must build business proficiency, or rather, "vertical" knowledge about the business operations for which the potential web platform will support. Without first understanding the framework of value—you cannot craft a valuable framework.

Understand the core pillars your solution will stand on:

  • Business model - Remember first and foremost, your solutions have to support this company's ability to turn a profit.

  • Product value proposition (or Service value proposition) - What is the edge your client leverages in the marketplace? What system components will multiply leverage?

  • Customer acquisition channels - Integrated solutions are the name of the game. Content strategy needs to support content discovery, and discovery needs to support conversion.

  • Standard operating procedures - Where are your platform administrators and users coming from? We all assume new features means better usability, but you have to first understand where a person is coming from in order to give them a better map. Adoption is accelerated by familiar traffic signs.

Paving a Path: Features and Friction

Second, you must define what potholes the current business operations fails to avoid. The problem space will directly correspond to both the needs of business operations (features), and the pains of business operations (friction).

In order to best understand the problem space, as a solutions architect you must understand the client's framework of frustrations through:

  • Identifying key stakeholders and key users - Often times people confuse a key stakeholder for a key user. Goals and requirements come from stakeholders, pain points come from users (especially in enterprise!)

  • Elicitation - Conducting workshops and interviews are the most effective methods for proper requirements gathering.

  • Inspection - Nothing is quite as useful as experiencing the previous platform, or rather, recording an experienced user performing their SOPs.

Finally, to craft a truly inspired solutions architecture, you must seek coverage through minimal solutions. Below you can see a chart of a problem space on the left, with the red lines the execution of technical solutions on the right.

Sane Problem Space


This may seem counter-intuitive to some, but for those of you who have been through this before, the benefits are quite clear. As a Drupal Solutions Architect, you want to be looking at a minimum set of modules in order to address the requirements, which helps to support minimizing complexity, maximizing performance, simplify implementation, minimize cost, and maximize return on investment.

But what does this really mean? Let’s break it down.

What happens if you select individual solutions for individual problems? Chaos.

Crazy Problem Space

Choosing a different technical solution for every problem you face, or rather each requirement in your platform, your issues compound. Many developers are familiar with this scenario: you've adopted a website where the previous site maintainer (I dare not say developer) has been just a little too module-happy. A healthy selection of modules are great, but you have to balance selection against the following issues:

  • Compounded technical debt - Many different solutions means many different interfaces. Don't let your solution grow exponentially.

  • Compounded fulfillment debt - User execution of tasks is unnecessarily complex and management tasks are too interspersed. Remember friction?

  • Compounded expertise debt - As your solutions become more diverse, so too must your technical staff to support them. I know we all would like to employ a team of Navy SEAL senior developers to deliver on our cross-functional and multi-disciplinary projects (FUN!) but as an architect you must understand and that your client probably isn't Charlie Wilson with a blank check for webland security.

  • Compounded compatibility debt - Yes, this is really a subset of technical debt, but it’s important to speak about it in plain terms. Not everything works together as easily you’d like it to; the more modules, the more performance and compatibility issues you will have to address. At a certain point, you must balance selection of contrib vs. trailblazing the path you need with custom code. Understanding the difference here when planning platform architecture can save everyone a lot of time and money.

  • Compounded performance optimization debt - The more moving pieces in your system, the more systems you'll have to isolate and optimize as your platform grows.

So, how do you select solutions for this coverage? Well, just as you must assess your ability to audit a system, crafting the solutions architecture requires a certain balance of technical proficiency, "horizontal" cross-cutting experience, and distance:

  • Technical proficiency because solutions, platforms, and frameworks are often defined this way;

  • Horizontal experience because problems are often avoided this way;

  • And distance, because you need to see the forest for the trees and vice versa as an architect in order to properly balance the product requirements against the project requirements in terms of budget, cost, and timeline.

Therefore, just as simplification empowers methods, classes, and functions—so too does simplification streamline architecture, solutions, and systems. In the grand scope of the big, bad web CMS-and-framework-world, Drupal may be only one of many solutions, but it’s a solution with great coverage for many technical needs. Just don’t pop all of the tools out on that swiss-army knife—you won’t be able to use any of them nearly as easily as when you just unfold the one you need.


Level Up! with our White Label Discovery Guide



Jordan RyanJordan Ryan (@jordan_ryan) is President and Solutions Architect-for-hire at Facet Interactive (@FacetLA). When Jordan isn't hustling through his most recent discovery engagement, you can find him enjoying the finer grinds of fresh ground coffee in Santa Monica or fiending for a foodie fix wherever Yelp may take him. Follow him on Instagram if you like to feast with your eyes.