Drupal doesn’t “get” enterprise

If http://www.databasepublish.com/blog/presentation-scaling-drupal-enterprise represents Drupal’s enterprise thinking, Drupal doesn’t “get” enterprise.

Drupal apparently thinks enterprise is just performance. That misses other important factors where Drupal falls on its face. For example:

  • It’s security model is stuck in a departmental model. At my work, we looked into an enterprise Drupal calendar, but we passed because it requires fantastic workarounds just to roughly approximate enterprise security.
  • Manageability is improving with the Aegir hosting system, but this just simplifies base management tasks. Enterprise Drupal is still a collection of discrete, departmental-class web systems, each of which has substantially independent configuration.

Drupal has its place in the enterprise for certain departmental solutions. But it’s a huge stretch to intimate that Drupal is “enterprise software.”

3 thoughts on “Drupal doesn’t “get” enterprise”

  1. Hi Aaron,

    It’s interesting to hear your thoughts on this. I’d love to get more feedback about the departmental model of security and what was wrong with the calendar (do you mean calendar.module or the release calendar that the security team follows (every Wednesday when there’s something to release). Are you referring to the security team’s efforts or just to the lack of fine grained permissions for your use case?

    Thanks!

    Reply

    1. No problem with calendar.module. That’s just presentation layer.

      I work at a university. We need a single calendar product that will manage multiple department-level security setups but work as a cohesive system:

      • Need separate calendars for each department or organizational unit, each with two levels of access specific to that calendar. For example, the engineering school’s calendar may have a few of its staff as authors and others as approvers.
      • All calendars use a single content type for all events.
      • Someone from department A cannot modify department B’s events.
      • Each separate calendar rolls up into a master calendar.

      Working internally and with a good local consultancy, we couldn’t fathom a security model without unacceptable costs. No model got us out of one of more of:

      • Extensive customization. This is a non-starter because it could require significant customization reimplementations even on minor upgrades. I don’t want to be customization-adverse, but I don’t want to implement something that gunks up upgrades.
      • Byzantine complexity. If we avoided customization, we’re looking at a bizarre combination of modules, many of which we’re using not because of its core reason but because of incidental featrues. Organic groups came up a few times for this.
      • Open, wiki-like security model. I like open security for other purposes, but we aren’t comfortable for it on content with first-order marketing needs.
      Reply

      1. That definitely helps. I’m somewhat relieved to hear that your concerns are around functionality and workflow rather than about the security team or the security of the code itself.

        Sadly, I don’t have any silver-bullet solutions for your workflow. I can imagine solutions, but they rely on my limited knowledge of the requirements. I have a feeling that if I knew all the requirements I would find out that my ideas are insufficient.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *