Photo taken at the Druplicon with Drupal professional Marcel Ritsema and the team of Dutch Drupal shop Merge.
So what is an all-round Drupal professional like me? That's someone who mainly uses Drupal as a tool to build websites and web apps, knows how to build a module and a theme (sometimes shares them with the community), but does not necessarily understand all the nuts and bolts of core, especially of the Drupal 8 core.
This blog post is about the 5 most valuable talks I’ve...Read more
This year was our first as a silver sponsor with an ERPAL booth at a Drupalcon. As we had lots of BOFs and interesting talks with other Drupal developers and sponsors from various companies, I’d like to share my thoughts and conclusions in this blog post. It became obvious that the community agrees about two very important facts:Fact 1: Drupal is not a CMS
You might exclaim, "But this is written everywhere!" – and you would be entirely right. When companies are looking for a CMS, what do they want? Mostly a ready-to-use system to manage their content. In general, they expect to start adding their content quickly and easily. Responsiveness is required straightaway and no content site works without media management. However, when we install Drupal, we don’t get a CMS that works for end users right out of the box: we get a clean and slim Drupal installation that takes quite a bit of modification before it’ll work for a content site, but it’s much more powerful! Nonetheless, it can also be a little disappointing. With all the contrib modules available, you can build almost any web application you want, but to create a full-featured content site, you need to be an experienced Drupal site builder. You need to know how entities/nodes work, how rules and panels do their job, why and how to use features for deployment and why you won’t find a ready-to-use "image gallery" module – instead, you have to build it yourself. This can be problem when, after installation, Drupal doesn’t live up to these unwarranted expectations. If you need an easy-to-use CMS that works immediately after installation, WordPress may be a better choice, as it does what people expect. Install and use for your content management, done!
Drupal can do content management as well, but it needs to be built manually. In all our conversations we prefer to call Drupal an “application framework”. And many of the people I talked to at Drupalcon seemed to agree with that.
So you can use Drupal to build a full-featured CMS if you’re an experienced site builder and know all the modules and how they interact with each other. Or you can use a ready-built Drupal installation specialized for content management (if there is one). These vertical use cases are called “distributions” and there are already lots of them out there at Drupal.org. A Drupal distribution is a collection of preconfigured modules that provide features for a specific purpose, say, content management. Drupal is a framework, as Linux Magazine wrote in a previous blogpost: Drupal provides the horizontal "infrastructure modules" like fields and entities for building a data model, views for data queries and lists, rules for business logic, feeds and webservice clients for interaction with external systems and their APIs, panels and display suite as well as other formatters for layouting and display control. Everything we need to build powerful web applications is available as a module.
Since many Drupalistas see Drupal in the same way, I want to plead with everybody to allow Drupal to meet the expectations of its users. Let’s show the world the power of Drupal to build web applications, and show it with vertical distributions and use cases that are different from your typical CMS. Give end users a functional and full-featured distribution for content management but don't hide Drupal for other purposes like collaboration platforms, e-commerce systems, CRM systems, business applications, or planning tools. I guess the list is almost endless and content management is just one item: Drupal can be used to build all of them, nearly without coding, but out-of-the-box it is not.Fact 2: Integration really matters
Another important fact I realized at Drupalcon is that many people are looking for examples of integration use cases. Drupal integrates with other systems very well – we’re often asked to integrate it with the “big players” in the software industry. And even better: it can extend the functionality of other system's data to integrate it with new workflows. Sharepoint and SAP integration requests show that Drupal has matured and that it’s now being viewed as an enterprise application framework. It only lacks public success stories that showcase these integrations. When I presented the Drupal cross-enterprise integration on an example of Sharepoint at the Drupalcamp in Frankfurt, I was asked "Why should one even do this?" The question is legitimate, of course. Why indeed should a Drupal developer use Drupal and Sharepoint together? The answer is to be found in the enterprise. Whenever you use Drupal in the enterprise for an intranet, a workflow management system, a CMS or a collaboration platform, the first thing you’re asked is: “Can we integrate with LDAP to avoid duplicate user accounts and permission duplication? Can we have a single sign-on? Can we see documents stored in Sharepoint in our Drupal instance? What about integrating SAP applications and can we reuse data from Drupal in Sharepoint or SAP?” The answer is: yes, yes and yes we can! But only a few will actually believe that, since they won’t find (m)any use cases in Google or Drupal.org.
So what we should foster in the Drupal community is the publication of stories of successful integration scenarios with other enterprise systems. Of course, these use cases won’t be as shiny as beautifully designed content sites, but they will help Drupal grow. Compared with other web applications systems Drupal is one of the most flexible: nobody argues this. It’s flexible and open to "talk" to other systems. In many of my conversations at Drupalcon it became clear that there are many niche use cases in the enterprise that would be expensive to build with other commercial systems, since code changes are always time-consuming and risky. From our daily work with Drupal we know that they’re much easier to build with Drupal, mostly by configuration. But almost none of the decision makers know this, which leads us back to "Fact 1 - Drupal is not a CMS". So whenever you build applications with Drupal that are integrated with other enterprise systems like SAP or Sharepoint, PLEASE publish and promote them! This will help Drupal grow in the enterprise, where we all want to see it settled in the future.Conclusion: Let’s do it together
So if you agree and want to see Drupal as a world-leading application framework someday, share this information and help us with the next steps. If you’re interested in further discussion, use the comment function. If there are enough people interested in this movement, let’s put our heads together and plan how we can better meet the requirements of Drupal users. Perhaps you even have some use cases that represent Drupal as mentioned in Fact 1 and Fact 2? Don't hesitate to go public with them. If you DON'T agree with this opinion and we didn’t meet at Drupalcon, you’re most welcome to share your thoughts here as well.