Chapter Three LLC

Drupal and the Enterprise

Josh Koenig

(Note: this post is part one in a three-part series.)

One of the most interesting sessions at OSCMS 2007 for me was the discussion billed as “Is Drupal an Enterprise Solution?” I attended in part because I’m interested in the technical issues of large-scale projects, and because facilitating the growth of the overall Drupal marketplace — including the growth into the corporate/enterprise environment — has been one of my interests over the past several years.

Expecting a mix of topics, I was a bit surprised that the conversation quickly became focused on questions of organizational culture and communication. In hindsight, this was probably a good thing, as these issues really are the critical roadblocks for most potential large-scale Drupal adoptors.

Technical questions of scale do exist; they require expertise to solve, and it would be nice if this expertise could be more widly held. However, numerous Drupal-based companies and consultants have proven the codebase itself to be eminently enterprise-ready if deployed correctly, and thanks to the efforts of the community (Lullabot trainings, the Drupal Dojo, etc) the pool of talent is growing.

On the other hand, the clash of cultures between most enterprise environments and the Drupal community presents a much more interesting and difficult challenge. There are a number of highly capable individuals working on this from both sides of the issue — Ivan Labra and Boris Mann come to mind, as well as my partner Zack of course — but my sense is that it will take some time and effort before there’s significant movement on this front.

One of the critical problems is that most so-called enterprise environments are actually far less enterprising (in the sense that you’d find “enterprising” defined in a dictionary) than the Drupal project itself. Most are bureaucratic organizations which move very slowly, deliberately, and generally with an eye towards internal political concerns and risk-management above all else. Some complain that Drupal itself is too slow, political and restrictive. My guess is most of these folks have yet to take a tour of duty in Corporate America. :)

The contrast between Drupal and enterprise cultures is perhaps most strongly evidenced in huge gap in styles of communication. Corporations are organized hierarchically, and in knowledge-work this hierarchy is usually built and maintained via the structure and management of information. To an entity that carefully controls its internal flow of data — who reports to whom — and even more carefully restricts what is made available to the Public, the overtly, even aggressively transparent nature of a dynamic open-source project such as Drupal is literally alien. It inspires confusion, if not outright fear or contempt.

In short, Drupal rides the cluetrain, but most of the Global 2000 still do not.

I would argue that our ways are potentially more productive, efficient and honest, and that in the long run top organizations and businesses are going to adopt many of our methods and practices. But this change will be iterative, and the workflows and needs of enterprise customers are going to evolve slowly over several years. As much as antiquated equipment, this is a true “legacy” issue, and one that cannot be ignored.

I think we all recognize the value in reaching out to potential partners, rather than simply remaining aloof and apart. The enterprise environment offers Drupal a chance to engage large-scale applications and drive innovation that would otherwise go by the way-side. They also offer some stability for the marketplace, and have the resources to make strategic investments that may help greatly in taking the platform to the next level.

With that in mind, in the subsequent posts in this series I will explore what I see as some of the next logical steps Drupal can take to be more friendly to the enterprise, as well as what enterprises may have to learn about organization/process from the Drupal project, and vice-versa.

Change

Well, the LAMP change was a combination of two things: the efficiency of using Drupal (and Joomla) instead of building from scratch. The second was a challenge; one of our groups developed a photo-sharing platform we call Spotted. Half the team build in C/Oracle, the other half in MySQL/PHP. The PHP team finished first, so the product shipped on LAMP.

The biggest issue we have (and I stressed this in Sunnyvale) is replication / scalability. We had to train a MySQL admin on-the-fly, and we are still testing things like GFS and proper load-balancing.

Sadly, I’m not a sysadmin, so most of this is over my head. But it is a challenge when your organization is used to serving millions of pages from a single blade server and then you go to a dynamic PHP environment where you might need 3 or 4 boxes to run one site.

I just posted another item about how I’m using Drupal within the enterprise. I won’t link, though; that would be grandstanding :-)

Posted by Ken Rickard (not verified) | Jul. 22nd, 2007 @ 7:53pm | Link to this Comment

People and processes

Josh-

I was on that panel, and would say that cultural values and work habits are the huge obstacle. I took the conversation in that direction because the other “enterprises” on the panel were Drupal-based (Lullabot, NowPublic). I work in Big Media, and we run Oracle with lots of Java and custom C code. It has taken three years to get LAMP into the mainstream of the organization.

And that was only solidified by a RedHat RPM.

Look forward to the rest of the series. Here’s some nostaglia on the same topic: http://ken.therickards.com/2006/02/26/drupal-and-the-enterprise/

Posted by Ken Rickard (not verified) | Jul. 22nd, 2007 @ 4:50pm | Link to this Comment

Indeed

Ken! Thanks for the comment. I’d be interested to hear more about the foundational step of managing to mainstream LAMP in your organization. What were the big challenges there, and how did the RPM help?

Anyway, I really found this part of your post to be resonant:

Commit to Drupal.org. After spending the week in Vancouver, I made the following report to our management team. If we are to go forward using Drupal, we need a dedicated support-and-development team of 3 people. (And my eyeball prediictions of such things are ususally pretty accurate.) The team lead will have, as one of his/her main responsibilities, the task of being our public face within the Drupal community. This includes going to events, encouraging contributions of code, and helping with documentation. This is crucial, because without being a valued member of the community, all you’ll ever really have is your own Drupal fork to support. If your organization goes forward with the idea of contributing patches to core, helping document Drupal, and so forth, then you will have a voice in future Drupal development.

I’ve been thinking about these kinds of things a lot, and it’s sort of a fault of mine that I took four months to make this series. I’ll be addressing the above topic, which I think is hugely important, in the subsequent sections.

Posted by Josh Koenig | Jul. 22nd, 2007 @ 6:13pm | Link to this Comment

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <br> <br/> <br /> <p> <img> <blockquote> <i> <b> <u>
  • Lines and paragraphs break automatically.
  • SmartyPants will translate ASCII punctuation characters into “smart” typographic punctuation HTML entities.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

4 + 3 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.