Solution Architecture

There are 10 ways to do anything in Drupal

Solution Architecture

This is a common epithet within the Drupal community. Drupal is extremely versatile, and with that versatility comes a multitude of methods to approach the various issues that come with building Drupal systems. The lesser-known, second part of the above epithet is "...and eight of them will cause you problems in the future". With experience, Drupal developers learn which approaches are best in order to cover the primary requirements of a system: high performance, ease of use, ease of maintenance, high-level security, a smooth upgrade path, and the ability to scale.

Morpht Knows Drupal

At Morpht, we know Drupal. We take pride in having multiple developers with over 10 years of experience using Drupal. This solid knowledge in our leadership, combined with the extensive experience in our development team, means that we have worked on an extremely wide variety of Drupal sites, for clients in a wide-range of sectors. We use this experience to consult with our clients and architect solutions that meet their business needs in an effective, affordable, and efficient manner. We have the background and experience not only to know which eight of the ten ways of doing something in Drupal should be avoided, but also what factors to look at to determine which of the two remaining solutions is a better fit.

Translating problems into solutions

We take a multifaceted approach to designing solutions. The start of each project is generally marked by a discovery phase where we become acquainted with the goals of the project and what constitutes success. We gather an understanding of the challenges and the shortcomings of the current system. We will generally undertake user research which will inform the designs and solutions.

From the discovery process we will develop

  • information architecture
  • content strategy
  • functional requirements

These three aspects with then inform the solutions architecture which is developed. This is where all of the requirements come together to be expressed as a solution inside Drupal.

The solution architect will then produce a specification which will focus on the following areas:

  • user roles and permissions
  • content workflow and moderation states
  • content types and relationships
  • taxonomy and classification
  • search and filtering
  • lists and reports
  • components for building pages
  • components for branding and styling needs
  • platform requirements to handle traffic and load.

These aspects are combined into a Specification document. It represents the nexus between requirements and implementation. The specifications can then be reviewed by the client and used by developers during the build process specifications.

Designing for the future

The process above is waterfall in the sense that requirements are gathered up front and are crystallised into a specification which then forms part of the roadmap. Morpht is able to remain agile with the process because we take a component-based approach and have an eye to the future with the solutions we suggest.