Part 3, ASRs and Riding the Wave of Change

Posted on by JVS

Change Management – Riding The Wave

Riding the wave of change in an open source world was the introduction to this post. That is the subject of the first set of ASRs I want to discuss. That first set has to do with the understandability, maintainability and manageability of the base platform. It has to do with the time, energy and financial resources required to implement, operate and maintain the technology for the CoP. And it has to do with my ability to do the launch and initial growth stages within my resource constraints.

  • How steep is the learning curve?
  • How is change introduced and managed?
  • What is the maintenance cost?
  • How easy is it to introduce and maintain new or augmented functions?

We’ll start getting into those subjects here and then we’ll continue in the next one or two posts. We’ll also discuss some related ASRs as we go.

Learning Curve

Before you can even get started being effective on either system you need to get past the learning curve. Unless you are doing something very simple, or having someone else do the entire system development and management job for you, you need to get to a point where you have some fundamental comprehension of the gestalt of the system. You need an understanding of the essence or shape of the system’s complete form (what it does, how it does it, and perhaps why it is structured that way) so you can appreciate how to best use it to approach your problem.

WordPress has a very straight-forward, and reasonably mild, learning curve. Drupal does not. Drupal‘s learning curve is steep, and winding; some might even describe it as a maze. There is a pattern to understanding Drupal, but probably not one that most people are familiar with. This has a major effect on getting started, and becoming effective and productive. It has an effect on getting things done, and it will have an effect on maintenance costs.

In my posts, and on the web, you may hear references to “WordPress is simple, Drupal is complex.” Or you might hear “WordPress is light, Drupal is heavy.” Do not be misled into thinking that these comments mean that WordPress is a light-weight toy for amateurs and that Drupal is the industrial-strength solution for real businesses. That’s not the case.

WordPress is designed in a very direct way to do a specific function that is easily aligned with a specific set of end-user functionality. It largely takes requests for content elements that are organized in one specific database table and it retrieves, formats and delivers sets of those elements back to the requester. It is easy to understand how the tool and the business function align. And it is easy to understand how to be creative in that space. There are lots of details, but there is simplicity to the central thrust of the product function. To make it easier, it is delivered in a manner that makes it functional to do this task right out of the box. WordPress delivers a blogging and web page management system in a box. And its companion product BuddyPress delivers “social networking in a box.” Plug them in, turn them on, and away you go.

Drupal is almost the opposite. It is the proverbial “Jack of all trades” or “Swiss Army  knife.” To make it more difficult, the system, by itself, does practically nothing right out of the box. In fact, it barely comes assembled. It’s a framework, a skeleton. Drupal is closer to being delivered as a gift card and a URL for a parts catalog. If WordPress were a computer, Drupal would be a computer kit with circuit boards, power supplies, fans, disk drives, robot arms, wiring harnesses, camera interfaces, and assorted other parts. Build whatever you want, the parts have all been designed to be plug compatible. There is a lot more flexibility and adaptability in that approach, but it takes more understanding about how it all works before you can be effective. With Drupal you really need to start with planning and requirements. What do you want to do? How do you want to approach it? Start with some general statements of functionality and some concepts about how a user will interact with the site. Then download and install the framework. Then choose the modules you need as the construction kit for what you want to do. Install the modules. Experiment. Change to different modules. Configure them. Make sure all the modules “play well” together. Adjust the type and form of how you want the features and data to be presented for viewing. Adjust your theme components. Test. Tune, Swap some parts. Re-test. Then go.

In the learning curve department, WordPress is definitely the far easier system to learn and that should have payback in terms of start-up costs, time-to-market, training costs and related expenses.

Customer Orientation

WordPress, in my opinion, is more focused on its users; and Drupal is more focused on its technology. These are not absolute statements. WordPress does care about technology, scaling and efficiency; and Drupal does care about usability. But the priorities are different. Paraphrasing a comment made on Jennifer Lampton’s post WordPress vs Drupal Saga Continues “Drupal is for developers, WordPress is for users… WordPress focuses on usability and productivity, while Drupal is heavy artillery.” “The ethos of the two projects seem very different. WordPress developers seem to me more user-centred, Drupal seems more developer-centred.”

The WordPress organization seems more customer focused. It seems driven toward delivering the easiest to use, easiest to manage and support, practical products in a focused space. That space is expanding over time with a growing family of integrated products  delivered by Automattic. Within that product suite, the one thing that seems central is customer focus. And customers aren’t just the people who develop with WordPress, it’s the end-users who use WordPress powered sites to interact and communicate. As a WordPress developer it is much easier to take a hand-off from WordPress and deliver a customer friendly web site.

Drupal has a different primary motivation. Drupal is about code first and primary. Drupal‘s Mission and Values statement is:

To develop a leading edge open-source content management system that implements the latest thinking and best practices in community publishing, knowledge management, and software design.

We value:

  • Flexibility, simplicity, and utility in our product;
  • Teamwork, innovation, and openness in our community;
  • Modularity, extensibility and maintainability in our code.

With Drupal the developer is responsible for end-user usability. The tools are there. I’ve seen a large number of Drupal sites that are easy to understand and easy to use. But I’ve also seen fancy and overloaded sites that may do wonderful things but they are unintelligible. This is not Drupal‘s fault. It was the developer. But it reflects badly on the product.

I don’t think this difference in focus weighs heavily in my AFCoP decision. The WordPress “warm fuzzy” approach would be well appreciated and the prepackaged functionality would make my job that much easier delivering a user-friendly site. On the other hand, I have some special technical requirements revolving around my EATS™ technology and other things I’d like to do with my site. For those tasks Drupal seems much better suited.

Functional Focus

What should have come across in the ‘Learning Curve’ section is that WordPress and Drupal do not have the same functional focus. This is a point that often gets lost in the religious warfare you can find on the internet in commentaries of one product versus the other. What gets lost in the shouting is the idea that boats don’t make good cars, and cars don’t make very good boats (“ducks” excepted). Neither make great airplanes. What’s the best vehicle? It depends on what you want to do, where you want to go and how you want to get there.

Listening to the hype or looking at a database diagram for either product it is easy to miss the difference in focus. But once I saw it (the difference), it makes a lot of other things clearer. It opens up your mind (at least it did for me) and gives you a different perspective in how to compare other aspects of the two systems. It also helps break through the learning curve impasse. My own “Aha!” moment came in a second reading of a Drupal vs. WordPress web posting by Jennifer Hodgdon. In her article she talks about the “WordPress model.” Under the heading “URL Handling” Ms. Hodgdon talks about how URLs are processed by WordPress and Drupal. She describes the WordPress method as the WordPress model.

If you look at a database diagram for either product you will see a “nodes” table. If you read some of the documentation, you’ll find out that a “node” is the fundamental structural unit that is used to describe and warehouse standardized content in the system. Either system. Both systems.

Both systems can accurately claim to be “content management systems.” But each system has a different perspective on what that means. Drupal has built some very advanced technology around nodes. But they didn’t make it the driving mechanism for the system. Your Drupal-based system doesn’t have to use nodes. It could be based on some other content facility. That’s part of the magic and the benefit of the Drupal Swiss Army knife. In WordPress nodes is the driver. You can write custom code to get around this. And that may even make sense. But if you don’t need to or want to get around it,  if it fits with the processing model for your web site, life gets a lot easier leveraging what WordPress gives you as a starting place for building your site.

When you visit a web site with a URL the site needs to decide how to handle your request. There is a strategy model that is used by the software. Both WordPress and Drupal are executing PHP scripts typically running under Apache. So the Apache and PHP parts of this equation are identical. The issue is the WordPress versus Drupal model within PHP. As described, I believe accurately, by Ms. Hodgdon, WordPress strongly wants the URL to resolve to a collection of one or more nodes from the node table. These can be pages, posts or some form of custom content; but, ideally it will be a collection of nodes. Drupal on the other hand, is agnostic. It doesn’t really care. It wants the URL to resolve to a module that registered to handle the URL. What processing logic that module might use to access data from where ever is something that the framework doesn’t really care about. These are fundamentally different processing philosophies, and they work with different degrees of efficiency and simplicity depending on how well an application fits the model.

For architectedfutures.net this is where some of that EATS™ functionality comes into play. With WordPress my EATS™ content repository doesn’t really fit into the nodes framework. There are some things that I could do to make it fit, but the main body of EATS™ is a different animal. It doesn’t fit naturally under the WordPress scheme for nodes. But with Drupal, (specifically Drupal 7) I actually have more options and more tools to work with. That’s appealing. (Your mileage may vary.)

To be continued …

More on my next post.

References

Architecturally Significant Requirements

Learning Drupal

Pages: 1 2

1 thought on “Part 3, ASRs and Riding the Wave of Change”

Record a reflection ...

This site uses Akismet to reduce spam. Learn how your comment data is processed.