The use of Drupal in enterprise settings tends to be quite different to its standard use. First it helps to understand what is meant by enterprise in this context...
An ‘enterprise’ literally means any organisation and could therefore refer to pretty much any size or type of customer from a small volunteer group to a blue chip. When technical folk and digital agencies talk about enterprise, they usually mean big and expensive.
But we are applying a more specific interpretation in the context of Drupal - and one that fundamentally refers to business processes in large organisations and the architectures that are required to support them.
It needs to be recognised that Drupal, while being one of the most long standing open source projects (over fifteen years), is even still considered relatively novel as a standard solution for large organisations. Whilst some pretty large enterprises have been using Drupal for a long time (for example, MTV), it has only relatively recently entered the vocabulary of consultancies, systems integrators, and business analysts. Meanwhile, Drupal is also noted for its huge and near-religious community of users and contributors, who are mostly working on smaller projects. So Drupal’s growth has been from the bottom up and has started eating into the higher end.
Over many years of working with large enterprises on Drupal adoption, we have noticed a concrete pattern which allows us to differentiate and define precisely what we mean by enterprise or large-scale Drupal.
Put very simply, it is that when Drupal is used in large organisations, it is usually as a component piece in a wider solution architecture. For example, in such a context it is very common that a user interaction will not only touch Drupal, but also a CRM like Salesforce, business processes in SAP, and so on. We will also often find middleware in such architectures which might control queuing and business logic orchestration. Contrast this to a typical Drupal system where at most search might be delegated to Solr and Drupal essentially forms the whole system as a full-stack framework.
In addition to this fundamental architectural difference, we have observed three traits which drive considerations in these large projects:
1. Integration oriented. Apart from the need to integrate within a wider solution, we are also seeing the emergence of API-centric approaches across the industry.
2. High volume transactional capability. This is seen in commerce and the growing demand for more personalised digital experiences.
3. Mission critical. Already a hard problem, but as the number of moving parts in a solution increases the ensuing complexity is multiplied. In contrast to a non- enterprise system (as defined above), apart from things like scaling for peak loads, we also need to give far more consideration for failover of various components, solution- wide monitoring, and disaster recovery against SLA’s.
So from a certain perspective, this is a story of two very different uses of Drupal. This large-scale enterprise use of Drupal is fundamentally different and by definition the large majority of capable and otherwise experienced Drupal implementers cannot be experienced in these areas.
And likewise, very few suppliers with experience in these kinds of complex larger projects will have sufficient expertise in Drupal to apply effectively in these kinds of use cases. Consulting the crowd and searching online for answers can give very much the wrong answers here.
This is, in a nutshell, by far the predominant cause of Drupal project failures and we believe it is entirely avoidable (as evidenced by the many successful implementations at all levels of scale).
Looking at these different kinds of usage, the good news is that we are starting to see a merging of wider industry trends and capabilities that make large complex systems both possible and maintainable.
A clear example of this is the trend for ‘headless’ Drupal in order to take advantage of the new generation of javascript based presentation frameworks. For many years prior to this, Drupal implementations for large organisations were grappling with decoupling Drupal to integrate within solution architectures. With Drupal 8, we can see these related use cases coming together with the adoption of web services into Drupal core.
Another example of a wider trend meeting enterprise needs is Drupal 8’s compatibility with other PHP frameworks via adoption of PSR. This not only allows Drupal to use components from elsewhere but also allows Drupal components to be used outside of Drupal. This kind of reusability and future-proofing is of course massively important to organisations who might need to be thinking in terms of decades on their large IT programs.
