enterprise

(Note: this post is part two of a three-part series: part one is here)

It can be argued that Drupal’s current rate of enterprise adoption is ok. Much of the growth within the marketplace continues to be lateral, with more and more small to mid-size organizations, projects and businesses turning on to the platform’s many advantages. This is good because it creates a diverse ecosystem of customers and enthusiasts, and a rich environment to support people who want to “turn pro” and start Drupalling for a living.

However, enterprise partners offer a chance to engage large-scale applications and drive innovation that would otherwise go by the way-side. They also offers a different kind of stability for the Drupal marketplace, and can make the kind of strategic investments that can be critical in taking the platform to the next level. In this post, I will outline what I see as the two major things the community can do to increase the rate and value of enterprise partnerships.

Marketing Marketing Marketing
One of the primary handicaps of moving Drupal into enterprise environments is a critical lack of marketing. While individual consultancies inevitably engage in some amount of evangelism, their primary focus is understandably going to be their own name and brand, as well as what it takes to close an individual deal. Any promotion of Drupal in general will be a secondary effect. While the cumulative impact of all these secondary effects is growing, it’s still no substitute for a compelling and direct pitch for the platform itself.

Drupal has benefitted from some excellent technical marketing in the form of IBM whitepapers and serious developer books from major publishers, but decision makers within large institutions are usually not engineers. Their vocabularies are peppered with acronyms like ROI, TCO and SLA, and their outlook is oriented around management concerns: streamlining processes, minimizing uncertainty, and making sure that all their decisions have “buy in” from as many of their colleagues as possible.

To someone with such a mindset, their first reaction to Drupal is likely to be confusion, if even that. The cultural disconnect between enterprise management and open-source entrepreneurialism is large, and much of the time these two worlds are barely aware of one another. That said, a strong case for Drupal can and should be made which addresses the concerns of the enterprise in their native language. This case needs to be made for more than just the value of the codebase, but rather for enterprise engagement with the community itself.

While Drupal.org is not overflowing with marketing gurus, there is probably sufficient experience to create a good set of basic talking points and other marketing source materials. People may scoff that this is just fluff, and in a way that’s true, but the fluff is important. Improving Drupal’s enterprise marketing would be a worthwhile project, and probably pretty easy to get off the ground.

Scaling Up Service (in addition to pageviews)
Beyond spreading the word in enterprise terminology, another major challenge for Drupal is the development of a sizable enough pool of experts and practitioners to make large institutions comfortable with the long-run picture. More and bigger drupal-oriented firms will need to emerge. This is partly about having larger teams of engineers to take on large (think global-scale) projects, but also about having enough of an established base and track record to make people comfortable, and about being willing/able to take on liability.

While many enterprise-scale entities have large internal IT teams, they still want and need external expertise, especially around new projects or technologies like Drupal. They will often want a contract which guarantees uptime, responsiveness, etc, and they want to engage and entity that’s willing to be legally accountable for providing that kind of service not just for initial development, but for ongoing maintenance and support over the long haul.

This is currently beyond most Drupal-oriented businesses, but it is something that more of us should aspire to provide. The alternative is writing off the high-end of the market, and/or waiting for other entities which do offer scale and liability to pick up Drupal as a line of business, which would not be likely to offer too much in the way of community dividends.

As with marketing, a lot of this can be viewed as bluster and hand-waving. Many of us know that within the world enterprise IT there are numerous stories of a good salesman selling an inferior product through a firm that looked a lot bigger and more established than it actually was. These things can and do happen. Still, we must recognize that until the Drupal community and the consultancies around it project an image that enterprise customers are comfortable with, the rate of adoption will remain slow.

That said, it would be a tragedy if our own organizational methods, communications channels, and working habits were compromised in an effort to be more enterprise-friendly. Indeed, it would probably be good if we were able to infect the Enterprise with some of the dynamism, passion and liveliness of our open-source organizational methods.

(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.