Drupal and TeamSite: A Look at Open-Source and Enterprise Content Management
Overview Over the last twelve years of my experience in IT, I have focused ten of them in the segment […]
25th Aug 2009
Drupal and TeamSite: A Look at Open-Source and Enterprise Content Management
Over the last twelve years of my experience in IT, I have focused ten of them in the segment of Content Management, and have seen as many changes and dynamics as the internet itself. For purposes of this writing, I’d like to focus on some key differentiators of open-source solutions and enterprise systems, as there is a fair amount of gaps and overlap between what they provide, who they serve, and their roadmap in the future of the content management paradigm…assuming we all know what a content management system should provide. Another key factor is the size of the organization. Larger organizations may have hundreds of users, making the administration tasks a difficult comparison to a small organization, where users can be setup and administered relatively quickly, regardless of the application. Granted that most of my time has been involved with implementing and improving on applications provided by a vendor (Interwoven), I was pleasantly surprised to see how quick and easy it was to rollout an open-source product (Drupal) with minimal know-how of the underlying technologies to make it work.
Installation, Configuration, and what comes OOTB (Out of the Box)
Perhaps I’m putting it too simple, but differences in installing and configuring almost came down to following a 10-page INSTALL.txt vs. a 100-page Installation_Guide.pdf. However, this may not be a fair comparison, since most large organizations will have a separate system administration/information security group within IT to perform installation tasks. Both have prerequisites before proceeding with the installation itself. If the tasks comprising the installation are distributed, they will collectively be more difficult than that of a smaller open-source installation. Installing an open-source application such as Drupal would more likely be done by the one-man system administration group, who has all the access and change controls needed to perform the install.
Once the application is installed, there’s the arduous task of setting up all the users. As stated earlier, the mere size of an organization can determine whether it’s really arduous or not, however, the task alone has had customers asking if they could use generic accounts…typically known as a bad practice from an information security perspective. Content management systems vary by supporting authentication models, but a larger organization implementing an enterprise solution will likely have the user administration delegated to other groups. Adding users in both TeamSite and Drupal is a snap, since the latest release of TeamSite supports non-OS users. Both are also very granular with what a configured user can see or do.
Drupal has an impressive set of modules that make up its core, such as configurable menus, themes, blogs, search, tracking, books, user-generated comments, and a forum. Based on these modules alone, one can gather that the nature of sites intended to be managed by the Drupal framework are geared more towards blogging sites and forums, or any other types accepting user-generated content. Interwoven’s products, on the other hand, have many features and some examples available, but with the exception of workflows, there are few templates or content types (forms) that are available with a fresh installation. Development would be required to create content types, as well as updates to those forms. Creating new content types in Drupal is also very straightforward, assuming you’ve added and enabled the CCK (Content Construction Kit) fields module. Updating (such as reordering or grouping fields) is also very simple in Drupal, and requires little or no development.
Drupal does offer many modules from their site to download and install to your system, which makes it very modular. There are some gotchas here, however, since you may find the module you’re looking for only to find out that it’s an alpha or beta version, or worse yet, not compatible with the Drupal version you’re running! Interwoven is compatible with most of its components, even forward compatible with its deployment mechanism. However, I have been made aware of its PERL versions not necessarily compatible with more recent versions. Because their direction over the last several years has been to move away from PERL and more towards a web services application, this becomes a moot point.
Both applications have a pretty good handle on administering users. Adding users from an LDAP source and then to a configured role is very straightforward in TeamSite. Drupal is also very straightforward, and stores user information in the Drupal database. From a system administration perspective, however, I see a short-coming in the way that Drupal has its super-user setup. There is only one true admin on the system, where in TeamSite, you can have multiple “master” roles, which I see as being more practical since you don’t want to have the one admin tied to one user. You can, however, delegate administrative capabilities to other users, essentially making *almost* admin users. Once users and roles are setup, it’s easy on both systems to delegate responsibilities, which is something that ought to be part of any content management system that may have many users.
A nice feature of Drupal is the management of themes…a theme can be configured to run for certain roles, and additional themes can be downloaded from the drupal web site. TeamSite requires that the UI be rebuilt if you want to make any menu changes or update the look and feel of the application itself. However, Drupal is a different beast in that it doesn’t have the notion of managing content and then deploying it to a test or production site. It makes little distinction between the site and the CMS itself, so it was written in such a way to make the skinning of the application more flexible. TeamSite does provide a Content Services SDK with a rich set of web services, so with development effort you could potentially build your own interface on top of the TeamSite backend.
File types and versioning
TeamSite and its distribution mechanism (OpenDeploy) do a fantastic job of allowing users to upload (manual or in batch) any file type, whether it’s for web sites or any other channel. The connector to its industrial-strength digital asset management tool (MediaBin) is also noteworthy, giving the user the ability to dynamically create web-ready assets from a different repository. With its virtual file system, it’s also very simple to work in a typical hierarchical view, either in the user interface or in a mapping to the file system itself (via Windows Explorer.) In Drupal, additional modules have to be installed and enabled to do file uploads, and size restrictions are present based on PHP settings.
Both systems support versioning, but there are a few gotchas to the way Drupal handles versions. Most information is stored in a database, and if you have access to the database, there’s nothing to prevent you from changing the content of a previous (or current) version of a content node. Some may see this as an advantage, but in general I would consider this a “hole” since you may not be guaranteed that reverting to a previous version is the one you really want. In TeamSite, edits cannot be made directly to previous versions. A user has to first revert to previous version and then that becomes the new version, which can then be edited. Also, TeamSite tracks deltas on files, so only deltas are stored, which can save a considerable amount of volume in the repository. TeamSite also has the ability to rollback entire sites or parts of a site. From what I have seen in Drupal, versions can only be reverted back on a node-by-node basis, unless a restoration is done from a snapshot backup of the entire database, which may have other implications.
So now that you have either system up and running…now what? Any organization will have the need to load the CMS with some initial content, either automatically or manually, and rarely will it be able to proceed from scratch. More likely, there will be a fair amount of content that will need to be migrated into the system, with several iterations ensuring it’s correct. With Drupal, this poses a challenge since the database schema is not widely published. A developer/DBA will need to be involved with this task, since they will have to become educated on the relationships within the database, but once that has been done the content appears nicely on the site, based on my experience.
Since TeamSite allows for any file type, migration is relatively more straightforward for non-native formats. Creating content records need to be created in a certain file structure, following a data-type definition based on the template, and an extra step of setting attributes on files that are to be typical forms. Although this may sound like a lot of work, it’s really not and can be easily scripted using a number of command-line tools that are available with TeamSite.
I have been through a number of upgrades of TeamSite…I recall a version 4.5 in 2000 that had gone through about 5 upgrades by the time I left the organization that had implemented it. With the exception of one backend upgrade, most went relatively well if there weren’t many customizations. Other scripts, templates, and forms were also largely backward-compatible. Interwoven has also done a great job with implementing upgrade features that customers request, by reaching out to them directly and validating their features, as well as conducting summits and focus groups to gather feedback.
I have only upgraded to a minor release of Drupal, which has also run smoothly…but a major upgrade may be a different story. Because the non-core modules are from a developer community and open-source, you are at their mercy to upgrade the modules along with the version of Drupal to which they work. Therefore, careful considerations need to be taken when planning and executing a major upgrade version of Drupal.
Having spent some time in both systems, I’ve come to the conclusion that they both shine in most areas, and there’s no reason an organization shouldn’t be compelled to use either system, considering the cost of infrastructure, support, and upgrade paths. Drupal is well-suited for a small to mid-size organization that is looking to get a site up and running with a great set of features quickly and low-cost, but heed the upgrade. Drupal is also currently being used to manage high-profile sites for larger organizations, such as Lifetime, The Onion, and Nasa. Interwoven’s products are truly industrial-strength, and scale well with volume of content, users, and requirements. Interwoven has also recently integrated products with parent-company Autonomy, putting them in a position to deliver high-quality, marketing-rich sites to organizations that have a high stake in their eCommerce offerings.