Drupal as a Prototyping Tool

There is a vast matrix that exists in my mind (there are also other, emptier spaces of such magnitude that we dare not approach). The matrix maps functional requirements, content structures, and media assets against out-of-the-box Drupal functionality, popular and flexible modules, and theming methodologies.

This matrix exists in a Platonic form where all of the requirements and conditions map neatly to available functionality and structures. It’s only when I populate it with the real-world facts of a project that gaps emerge. Those gaps identify the responsibilities and data structures that we’ll need to delegate to our own modules. Once we group these by logical or functional affinity, we have our module strategy.

For instance, while scoping a recent project it became clear that the client was asking for functionality resembling part of an e-commerce application.  Part, but not all: the client wouldn’t specify the order, but would rather be supplied with a template of an order, and given the option to alter details of the order before submitting.  And instead of processing payment, our application would submit to the client’s fulfillment department, who would then issue an invoice and process the order through existing systems.

We could have scoped this by documenting order flow, architecting the process, and writing a technical brief that would summarize business requirements and accompanying functional requirements.  Instead, we built a Drupal prototype to explore how far existing modules would get us.

You can see a very basic iteration of this prototype here:

http://d1.helen-marie.com/

Barebones indeed.  But that’s the point: this took fifteen minutes, and supplied us with much more accurate information regarding how we could work around the assumptions of the UberCart module.  Those assumptions form the core of our module strategy.  On top of that, we build in time and budget to cover theme development, and we have our basic scope and requirements.  We also know a lot more about our upgrade path than we would from an abstract scoping document, because we can cite UberCart’s support and upgrade history (as well as Drupal’s, of course).

And on top of that, we could show the client a working example of a portion of the proposed functionality.  That’s exciting for everyone involved, and comes at a very small internal cost.

The customization strategy becomes clear:

• A user of type A (or, in Drupal “role A”) can create an order for a user of type B.
• Type B user receives email notification and link when order is created.
• Order is considered “paid” by UberCart when submitted.
• Type A user receives email notification with order details when it is submitted.

That wasn’t so hard, was it?

One of the reservations underlying this approach is this: “What if I pick the wrong modules the first time around?  What if my scope is affected because I change my mind about my module strategy after the client accepts the budget?”

This is a risk you run whenever you pair a scope and a budget.  It doesn’t matter what platform you use, or how specifically you set your scope.  This is a problem you solve by setting a budget that allows for a certain degree of agility (i.e., making useful mistakes, learning from them, and correcting) during development.