Some ways you could start using Drupal in your organisation

Looking at my blog posts, you would be forgiven for thinking that I work with Drupal all day but actually I don't. I've used it for odd private and business projects over the years, built a startup (1) with it and run my sailing club's website on it.

Actually, my working day is spent on a mix of legacy and new Symfony 2 applications. In years gone past that included applications written in frameworks such Zend framework, SugarCRM and plenty of home grown ones from early PHP days.

Sure there are things I don’t like about Drupal 7 such as configuration management, deployment, really basic media handling, lack of modern OOP and practices and the fairly blunt caching mechanism but I think it is because of having seen so much legacy code and so much internally written software that I still like Drupal.

Starting from the assumption that you aren’t going to touch your main application which could be running on another framework or technology, I’m going to write about using Drupal in your organization in ways that you might not have considered.

We’re just not going to switch to Drupal!

I think the reality regards PHP applications is that most companies use their own legacy frameworks and/or something like Zend Framework or Symfony, or they are using a totally different stack and they certainly aren’t about to switch any time soon to something else. Which is fair enough.

However there are ways to get value from Drupal with low effort and risk alongside - and in some cases replacing - existing applications and other technologies.

1. Drupal for building intranet tools

In my current company we have a myriad of intranet tools built on different technologies, mostly home grown legacy PHP apps, but also ones built on other frameworks and some in .NET. Nothing is standard, every one is special and each demands developer ramp up time. One is even stuck on a dead framework on an early PHP version.

Each generation of developers had seemed to want to try out a new framework, different stack or just write something new. I think that is fairly common in old internet companies.

Drupal can be pretty good for building intranet tools. It has some nice APIs, you certainly aren’t limited to the Drupal data model, you get a lot for free (no custom coding needed) plus there are many good modules out there that expose APIs as well. It is a bit of a revelation to define your own DB table structures and then manipulate or expose them using standard Drupal modules like Views.

Also, if you have good developers to set things up correctly initially, management of the application can then be moved to non-technical staff. For example, it won’t then take a developer to alter a permission, set up a new data view, trigger an alert, turn off a functionality, set up a new workflow or add a new language and so on.

This is one of the things I really like about Drupal in that if done properly, it pushes more control to non-technical staff. Developers are expensive. And just using Drupal on an intranet simplifies things a lot in the sense of deployment, maintenance and possible custom coding / themeing.

I think this “myriad of unique applications” scenario should just end. It’s too expensive, complicated and risky and companies should choose standard solutions and stick with them. A number of open source PHP projects are now very established, not going away and 100% enterprise ready. In the PHP world Symfony 2 with its connected eco system is one, Drupal is another.

Take a look at intranet distributions like Open Atrium for intranets and also other disributions on the Acquia downloads page.

2. Drupal as a data source for other applications

In 2010, in one company we had a large Zend Framework application, a java powered auction system in the back end and we wanted to add multilingual news and help sections. I chose Drupal as the CMS as it had great multilingual functionality, rock solid content management and the possibility to build nice workflows for editors and managers.

There was however just no way that we were going to build a new Drupal application for news and faqs, theme it, deploy it and manage it in production alongside the existing frontend. Too much effort.

The solution for this was simple, use Drupal as an intranet CMS only and just pull the data where needed. I set up a multilingual content management application in Drupal to enable staff to add news and help pages, and we just pulled that data into the front facing Zend Framework application through the caching layer via some simple database views.

Note: this was how it looked in 2010, nowadays you would most likely use the services module to surface the data.

The Drupal application used only out of the box modules, needed no theming and had no special deployment , it was simple and with short development time. Everyone was happy.

I’ve seen plenty of home built CRUD applications for all sorts of things like FAQs, news and help pages, community announcements, landing pages, email templates, translation strings, configuration management. Why write and maintain that stuff yourself? Just use a CMS like Drupal.

Just on translation strings, it would be very easy to build a Drupal application to manage translation strings consumed by other applications. Just build the translations app in Drupal and then write a script to export them to a format that the external application needs, e.g. see here for Symfony translations.

And regards exposing Drupal data, Drupal does have an XML-RPC API and RSS but check out services. See the links below.

3. Drupal as a frontend for manipulating data on other applications

Let’s say you have a public site where users can add content. Rather than add more code to your public facing application, you could make a management frontend for that data in Drupal. Drupal has nice APIs for forms and data access, but you could even hook that data into Drupal APIs more fully, allowing you to use native drupal modules to manipulate the data.

4. Drupal for microsites

Drupal can be perfect for microsites such as News and FAQ sections or forums that work alongside your main application(s). Theming isn’t that difficult and if you don’t need to authenticate users, this is a very easy option.

5. Drupal for your corporate website

The corporate website is usually separate from the main application(s) and a good use case for Drupal. A corp site is usually content heavy, needs frequent updates and might need publishing workflow.

6. Drupal for rapid prototyping

Rocket Internet, the giant European incubator gets new minimum marketable websites out in under 100 days. I think this is a very good plan and Drupal is good for the rapid prototyping of ideas even if the data comes from other sources like search services.

Caveat

If you are having to make long term decisions now, then with Drupal 8 just around the corner whether you choose Drupal 7 or 8 needs careful research.