A Drupal architect is accountable for the handful of decisions that are expensive to reverse: one site or many, coupled or decoupled, what is configuration and what is content, and where caching lives. Everything else on a Drupal project can be changed in a sprint. These cannot, which is why they are worth arguing about before anyone writes code.
The decisions that actually deserve an architect
Most technical decisions on a Drupal project are reversible and should be made by whoever is closest to the work. A short list is not, and those are the ones an architect owns.
One multisite, several installs, or several codebases
Drupal supports running many sites from one codebase: sites/sites.php maps hostnames to site directories, each with its own database and its own configuration. The trade is real in both directions. One codebase means one update to apply and one place to fix a bug; it also means every site takes the same core release on the same day, and one broken contributed module can affect all of them.
Separate installs invert that. Independent release schedules, independent risk, and a multiplied maintenance bill. The question that settles it is rarely technical: it is whether the sites share an owner who can accept a shared release calendar.
Coupled or decoupled
Drupal ships jsonapi and rest in core, so serving a JavaScript front end is a supported configuration rather than a hack. The cost is that you leave behind a large amount of work core does for you — render caching, BigPipe streaming, the theme layer, and a great deal of SEO and accessibility behaviour that then has to be rebuilt in the front-end framework. Decoupling because a front-end team prefers it is a legitimate organisational reason and should be written down as one, not disguised as a performance argument.
What is configuration and what is content
This is the boundary that surprises teams late. Content types, fields, views and permissions are configuration and travel between environments as YAML. Nodes, media, taxonomy terms and blocks placed as content are content, and do not. A page built and approved on staging that does not appear in production is almost always this boundary, discovered on launch day.
Where caching lives
Core ships three layers before you buy anything: page_cache for anonymous responses, dynamic_page_cache for everyone, authenticated visitors included, and big_pipe to stream the personalised parts after the shell. A reverse proxy or CDN sits outside all three. Architecting cache means deciding what each layer is responsible for and making sure render arrays declare their cache tags and contexts honestly — edge caching is only safe when invalidation is precise.
Upgradeability is an architectural property, not a maintenance task
The most common cause of a stalled Drupal upgrade is not core. It is a contributed or custom module that never declared support for the version you are moving to. That fact is readable in advance: every module and theme states a core_version_requirement in its .info.yml, and an inventory of those strings is the honest first page of any upgrade plan.
It is worth doing on your own code too. Reading the eleven Vanilla Views modules maintained alongside this site, each declares ^11.3 || ^12 and the ten display modules each depend on a shared vvj_core — which means the upgrade unit is the set, not the individual module. Dependency shape like that is invisible until you read the files, and it is exactly what determines whether an upgrade is one afternoon or one quarter.
Two core-level changes are worth checking custom code against now. Neither fails silently and neither fails suddenly: core logs a deprecation for each before removing anything, so the warning is already in your log. Hook implementations can be classes carrying the #[Hook('...')] attribute from core/lib/Drupal/Core/Hook/Attribute/Hook.php. And plugin discovery has moved to PHP attributes: in core/lib/Drupal/Core/Plugin/DefaultPluginManager.php, the fifth constructor argument is the Attribute class and the sixth is the legacy annotation name, with core checking which one it was handed. A plugin manager still passing only an annotation is technical debt with a known due date.
If an upgrade assessment is the immediate problem rather than a greenfield design, that is a defined piece of work — the Drupal development services page describes how a code review of custom modules is scoped.
Two consolidations, and what they actually cost
The résumé and portfolio on this site set out the architecture work behind that advice. The two most relevant:
- Nine sites into one repository. Re-architecting nine separate sites to run from a single Drupal multisite repository, with a configuration split strategy across environments and a custom parent theme with a sub-theme per site. The saving is not in the build; it is that nine security updates became one.
- Consolidating several ed.gov sites into one platform as Architect Tech Lead, including the hosting design for the traffic a government education portal takes, and a single main theme covering every content type.
Both projects had the same shape: the technical work was ordinary, and the difficulty was agreeing what would be shared. That is usually the truth about consolidation.
The failure modes an architect exists to prevent
- Over-design. Microservices, a decoupled front end and a bespoke component library on a site with forty pages and two editors. Complexity has a running cost paid by people who did not choose it.
- Designing past the team. An architecture that only works if everyone knows Kubernetes, on a team that does not, is a plan to be rescued later.
- Unowned integrations. Every connection to a system you do not control needs a defined behaviour for when it is down. "It will be fine" is a design decision made by default.
- No written rationale. An architecture nobody can explain in two years gets replaced rather than extended, and the replacement repeats the same mistakes.
- Content model decided by the first deadline. Everything downstream — views, search, migration, translation — inherits the shape of the content model, and it is the hardest thing on this list to change later.
How to tell an architect from a senior developer in an interview
Both will answer technical questions well. The distinguishing question is about trade-offs, not knowledge:
- "When is decoupled Drupal the wrong choice?" Anyone who cannot argue the case against their preferred pattern has not used it at scale.
- "Describe an architecture of yours that had to be changed. What did you miss?" Specific, unflattering answers are the good ones.
- "How would you sequence a Drupal 7 to Drupal 11 migration for a site that cannot stop publishing?" Listen for content freezes, incremental migration and rollback, not for a tool name.
Common questions
Do we need an architect for a single Drupal site?
Usually not as a separate role. You need the architectural decisions made deliberately by someone, and on a single site an experienced Drupal developer normally makes them well. The role separates when there are several sites, several teams, or an integration landscape.
Is Drupal multisite still recommended?
It is supported and it is used at serious scale, and it is the right answer when sites share an owner, a release calendar and most of their code. It is the wrong answer when they share only a brand, because you have coupled release schedules that have no reason to be coupled.
How far ahead should an architecture plan?
Far enough that the next known requirement does not require a rewrite, and no further. Extension points cost nothing when designed and a great deal when built in advance for a requirement that never arrives.
What should an architecture deliverable actually contain?
A content model, a diagram of what talks to what, the caching and invalidation strategy, the environment and deployment flow, and — the part most often missing — the options that were rejected and why. The rejected options are what stop the same debate reopening every year.
Next steps
If you are about to start a large Drupal build or consolidation, the cheapest useful artefact is a one-page inventory: every site, its core version, its custom modules, and the core_version_requirement of everything contributed. It usually reveals the real sequence of work before any design begins.
For an architectural review or a consolidation plan, request a quote describing the estate as it stands, or get in touch to talk it through first. The broader engagement types are on the Drupal services page, and the front-end half of these decisions is covered under Drupal themer.
