Following our look at what makes Drupal a fit for enterprise, and our overview of Drupal, we can now dig a little deeper....
Drupal is used to power digital experiences. Most typically, these include responsive websites, but also intranets, web applications, and back-end services. It is based around a relatively lightweight and minimal core, through which functionality is added using modules, most of which are created and maintained by its huge community of users. In this way, solutions are largely assembled and configured from exist‐ ing parts. Drupal also provides many extension points for adding or changing existing functionality by the creation of new modules.
We’ve seen that Drupal is hard to describe due its uniqueness which makes it hard to compare against other systems, and even more so due to its flexibility which provides ease of use in many diverse applications.
In many ways, attempting to describe Drupal is much like the well-known story of the blind men and the elephant
- in which a group of blind men are asked to determine what an elephant looks like by feeling different parts of the elephant’s body. By no means comprehensive, the following attempts to give the newcomer a broad overview to understand the shape and contours of the elephant we call Drupal.
We shall look at Drupal in three ways: its characteristics, its features, and finally at some ways in which these have been applied.
Standards-based
Drupal is built on a standard LAMP architecture, the most common platform for modern web applications and sites.
LAMP is an acronym for an archetypal model of web service solution stacks, originally consisting of largely interchangeable components: Linux, the Apache HTTP Server, the MySQL relational database management system, and the PHP programming language. As a solution stack, LAMP is suitable for building dynamic web sites and web applications - Wikipedia
Standardization in general is not only important to the Drupal project as a central cultural value but is also necessary for its distributed model of development. This brings a number of benefits to organizations who adopt it too, for example, much greater vendor transparency and no ‘roadmap prison’.
Open source
Drupal is one of the longest standing open source projects, having been actively developed since 2001.
What difference does open source make? Innovation.
The Drupal project has consistently demonstrated a pace of innovation which is unrivaled and impossible for even the largest organizations to compete with.
This is one of its biggest selling points to enterprises who have seen the largest IT vendors struggle and typically fail to keep up with the pace of innovation on the Internet as the market has come to be dominated by what were until recently startups. It is no surprise then that this is a concern that strikes home to large organizations who have been watching these disruptions regularly unfold, and who have learnt that when it comes to what we are now coming to think of as digital services, the only constant is indeed change.
Some examples of Drupal’s rapid innovation include Facebook and Twitter integration appearing within a few days of those services creating public APIs, and early adoption of emerging standards such as OAuth and semantic markup. By contrast, in a proprietary software project, such features may take months or even years to go via their roadmap to release. Where the cost benefits of any new integration or feature need to be evaluated, this is very often long after the market has already tried it out and made that decision clear. In short, there is a clear distinction here between ability to lead new market trends, or trail behind them - and this has a definite business and planning impact.
It’s worth pointing out that Drupal’s open source nature is only one side of the coin when it comes to community-driven innovation, as we see when commercial entities attempt to harness community efforts by open sourcing a controlled platform and frequently have very few, or low quality, contributions. While open source enables innovation, the other key element is scale, which incentivises it. It’s one thing to be able to integrate a new web service or emerging data standard, but you also have to have a very large and committed community, with members who can see sufficient benefit, in order to realise open source as an engine of contributed functionality. In this way, another key selling point to enterprises is Drupal’s longevity and the size of community it has built up during that time. This creates a form of barrier to competition even from other open source projects.
Transparency of security
If your technology isn’t open source, it is by definition a black box with no ability to inspect or audit code. A very senior industry veteran with decades of experience in financial processing for stock exchanges tells the story of how he learned to only ever consider open source when it comes to security.
And it gets worse! Since our proprietary vendors are playing catch-up on innovation as we’ve seen, their resources are going to be prioritised on their feature roadmap. The hard fact of the matter is that for a proprietary system the commercial incentives will almost always favour adding new features over securing existing ones.
No vendor lock in
Proprietary software is typically characterized by a feature roadmap. (And tellingly this always resembles a single lane road, rather than the kind of roadmap that we would use in real life to get from A to B and which contains many viable routes and options.)
With Drupal, every user is a stakeholder who can either make use of what emerges, add their own features, or, more commonly, join together with others who are looking for some particular functionality.
Contrary to popular myth, most Drupal development is not done by coders as a hobby in their spare time, but rather by people hired to build features that offer real business value to their employers.
A monumental example of this is the Views module, a hugely powerful visual query builder and renderer which was developed to create complex landing pages for hundreds of artists at Sony Music, and which became a defacto addition to almost every Drupal site (and has now been incorporated as a core feature in Drupal 8). Of course that has served Sony very well - as the community continues to contribute functionality, security, and updates to Views, which has evolved as an increasingly detailed and rich subsystem.
So we can see that due to Drupal’s open source license you can own as much of your roadmap as you like (whether by picking and choosing features or developing new ones), and secondly, that if you contribute in a strategic way, it can repay far beyond the initial investment.
Flexible
Drupal’s architecture is unusual in being largely event-based and borrowing from aspect orientation (which Dries Buytaert was studying when he initially designed it). This gives it an unusual degree of flexibility and has arguably been a central part of its success. This means that if a Drupal system needs to be customised beyond assembling and configuring the many available existing components, it is done by extending existing behaviour rather than rewriting whole chunks of the architecture.
Large community
Drupal has the largest open source community in the world, and a number of the Drupal leaders are notable, including members of the PHP-FIG (Larry Garfield), a former lead of the PHP documentation team (Gábor Hojtsy). Dries Buytaert, project lead, has presented many papers at OOPSLA.
Many Features
While Drupal’s core is becoming more fully featured in Drupal 8, there is also a community-contributed set of over 23,000 components to add functionality. The chances are that what you want to do has already been done by somebody else, and as the saying goes: ‘there’s a module for that’.
Full Stack (But Increasingly Decomposable)
Drupal is often described by enterprise architects new to it as a display layer or front-end technology and we often see it placed here in a solution architecture diagram. This is a fundamental (and frequently expensive) misunderstanding. Drupal is by default a full-stack system, covering both the back and front end. In fact, in standard use it represents the entire end-to-end solution architecture.
However, when it comes to enterprise architectures, Drupal is often used either as a back end component or more typically in a hybrid role, serving a site but also integrating with other systems such as mobile apps, or a CRM, via web services.
It’s possible to run Drupal as a back end only system, often referred to as “headless.” While not common, there is an increasing trend to run headless Drupal in response to the growing importance of mobile and proliferation of front-end JavaScript frameworks like Backbone, Angular, and Ember. This growing requirement to decouple what is essentially a monolithic architecture has been a big driver during the Drupal 8 development cycle.
Some notable examples of using Drupal as a backend system in enterprise architectures which Fluxus consultants designed and lead include the use of Drupal Commerce powering the UK’s Royal Mail national postal service and as a backend CMS at Time Warner’s IPC Media providing content and functionality for sites (where the front end was delivered using the PHP Zend Framework).
Wide Adoption
As we have seen, Drupal has grown from the low end to the point today where it is used widely across enterprise in top media and entertainment companies, govern‐ment sites all over the world, universities, notable technology companies, life sciences and pharmaceuticals, and financial services.
Features
So far we have looked at some characteristics of Drupal which describe it at a high and quite abstract level and go part of the way to answering the question: ‘What is it?’. Now let’s dive a little deeper into some of its features and components to better understand what its capabilities are.
Content Management and Placeless Delivery
Drupal uses ‘placeless’ delivery. By this we mean that Drupal looks at content as discrete pieces which are then assembled in various ways, often ultimately rendered within pages as you might expect. But these support content reuse - for example these atoms of content might also be surfaced in blocks, feeds, and web service APIs. This is in contrast to systems which revolve around a page-centred view of the world.
The advantage Drupal brings here has always been content reuse and recombination, and this is only becoming more relevant in the face of personalisation and the need to address multiple channels such as mobile apps.
Users
A common misconception encountered particularly in enterprise is that Drupal is for content only, when from the start it has been a social publishing system combining community and content.
It could be said that Drupal doesn’t make a strong distinction and content is just one type of entity (which we could even go as far to describe as a business object). Indeed, Drupal has a term for pieces of content which is unintuitive and vaguely baffling to newcomers expecting articles and pages but which makes more sense in this context - nodes. Bearing in mind that Drupal was originally developed as a bulletin board system, at the heart of this from the beginning were users. A user is just another kind of entity in Drupal.
This allows Drupal to not only offer authentication, but role-based permissioning, and user profiles.
As a user is just a type of entity, Drupal doesn’t make a distinction between internal admin users and end users, other than via the association of roles to users. This needs to be taken account of in enterprise solutions. In such settings, users are typically mastered in separate systems - LDAP for local users and a CRM for customers wouldn’t be at all unusual. In such a case it is necessary to integrate these systems with Drupal. While Drupal does support multiple external authentication systems, expertise is needed and care is required around synchronisation and performance.
Permissioning is achieved via the association of users to roles, each of which are configured with a set of associated permissions (e.g. ‘editor’). Whilst a user can have multiple roles, it should be noted that roles and permissions are not hierarchical and therefore may require close attention when mapping to an external system which supports hierarchy of permissions such as LDAP.
Another area we often see a lot of difficulty in is the tendency to design the user registration and password systems from first principles, as if designing a piece of bespoke software. A simple rule of thumb here is “don’t”. Drupal is not a low level framework for fully bespoke software. It is rather a minimal product with many extension points designed to be assembled into complex solutions. In this way Drupal more closely resembles a system like Salesforce where value is realised in a combination of assembly, configuration, and targeted extension. The tradeoff here is that in return for getting a user system for free, you shouldn’t expect to try to reinvent it without encountering edge cases and subtle system-wide ripple effects as your system grows. This rule of thumb consistently applies to any core part of Drupal.
Categorization
One of the most frequently used tools in the kit is Drupal’s generic categorisation component: Taxonomy. Taxonomy is another kind of Drupal entity, which isn’t immediately obvious to new users but which contains a huge amount of power. To all intents and purposes, taxonomy refers to tagging (and not just of content...).
Drupal’s approach to tagging is quite comprehensive and allows for any number of vocabularies, each containing any number of tags, and which can either be fixed or dynamically created. Dynamically created tags can be used both internally and for social tagging (or ‘folksonomy’ as it used to be called).
Drupal’s taxonomy system also supports hierarchical arrangements of tags within a vocabulary, although in practise there is generally greater flexibility and simplicity to be had in intersecting multiple flat vocabularies, than by using complex hierarchies in a smaller number of vocabularies. Synonyms and related terms are also supported.
Taxonomy is most often used as the primary categorisation tool, and in combination with Views can power many typical publishing scenarios such as river of news and section listings, dynamic topic hubs, related content and so on.
Unifed entity model
Almost all data in Drupal is an entity - this includes content, users, taxonomy, comments, and even configuration in Drupal 8. Drupal entities have a couple of traits in particular which make them very powerful.
The first is that they are ‘fieldable’. This means that any number of fields can be added to an entity type. So for example, we might well add an image field or a pullquote field to an article entity or we might add a country or date of birth field to a user.
Even better, entities themselves are another kind of field, so we could add a user to an article for example.
Going further, we can add multiple instances of a field - a common use of this is linking related articles where you can add any number of other articles to the one you are creating or editing.
In terms of data modelling, this means you can easily create very complex multidimensional objects rather than simple flat records that correspond to a database row. (In combination with Views, we have seen examples of several hundred line stored procedures which had taken weeks to write being quickly replaced with some relatively simple and editable configuration in a GUI.) This aspect alone is rarely discussed and represents a killer feature, particularly for enterprise applications.
Views
Another killer feature we touched on earlier is Views. Views could be described as a query builder for entities which comes with a GUI but also includes rendering configuration. In reality it goes further than this and a few minutes of ‘click and build’ can often provide reusable configurations which would require days of work each time in a standard MVC web framework.
To give some idea of breadth, Views might be used to output such diverse things as listings, contextual items (e.g. a logged-in user’s top-rated comments on the topic they are viewing), data feeds, admin reports (e.g. most read stories, comments flagged as abusive), and many more.
Context
Drupal allows us to use context as an input and is a powerful tool for personalization and segmentation. Context includes such things as the current user, device type, time of year, geolocation, current weather and so on.
Rules
Another popular contributed module is Rules. This is a full event-condition-action (ECA) rules engine and enables things like the display of content to react to a context as above. More often it used for more backend operations based on event triggers - such as emailing an administrator when an editorial user changes their email, or when a comment has hit a certain threshold of abuse reports. Like many of the most successful Drupal components, this is a highly generic feature which can be applied in many different ways.
Web services
Drupal has a contributed Services module which allows authenticated read/write services access to most core functionality. This is easily extensible to enable services for custom or contributed modules as well and is an incredibly powerful and necessary feature when decomposing a Drupal solution. For example, we have seen this used to provide a back-end commerce system for a very large organisation which is then accessed by their website, CRM and internal apps.
Drupal 8 has now incorporated web services into core, meaning that any entity will now be addressable using a REST interface.
Commerce
Drupal has two ecommerce systems: Commerce and Ubercart. Commerce was the result of a ground-up rewrite by the original Ubercart developers, while Ubercart is now maintained by its community of users. The key difference between them is that Ubercart is more of a ‘shop in a box’ solution, whilst Commerce is more of an ecommerce framework and uses SKUs. Hopefully we won’t offend anybody by saying that Commerce is widely more associated with enterprise.
