I was recently asked to write an article for the reboot of Drupal Watchdog Magazine. In the piece, I ask the question of whether most agencies are fully equipped to deliver enterprise-level software by leveraging Drupal. Some of you might have seen it at DrupalCon, but posting it here.
We are at a crossroads as to what is expected from the full-service agency* traditionally looked upon by Enterprise firms. Today’s digital transformation of the Enterprise, with its complexity of web properties, requires a new kind of agency partner that has the capabilities of a creative firm and software company. This is particularly true with firms that choose to deliver the solutions with the power and flexibility of Drupal.
Dollars and sense (and pie)
As we informally polled some of our agency peers and partners, we uncovered that about 70-80% of the time, the agency is looked to by the client in making the CMS recommendation. At the Enterprise-level, Drupal has become an option of choice because of its ability to deliver functionality equal to or better than many of the proprietary systems. However, there is a business side to recommending open source (free) Drupal vs. license fee-based software. From the agency perspective, there is a bigger piece of the “contract pie” if they are doing design, web development, AND the CMS development. In the other scenario, part of the revenue for the project is going towards CMS software company X. In the end, it just makes good business sense to get the CMS piece of the pie, if you have things in place to meet expectations for the short and long-term.
Drupal is not a product . . . until it is a product
A few years back, I wrote a blog piece titled, “Drupal is Not a Product,” where I articulated the challenge of selling an open source Drupal solution against established proprietary CMS solutions. I discuss the uphill battle of “demo-ing” Drupal features and functionality relevant to the end-user. Obviously, with Drupal, this presentation requires a bit more vision, since Drupal is more of development platform than a finished CMS. It’s not really a CMS (product) until it’s developed it into one. This is in contrast to a proprietary CMS solution which is presented as software; with benefits and functionality to which a non-developer can relate.
The reality, based on many conversations Isovera has had with folks in the Drupal development trenches in these larger agencies, is that most of the firms are still not quite structured to deliver best-practices Drupal software design, development, and support in a way that would be expected with a proprietary CMS. With that, proposals and estimates for Drupal-based web/digital projects often gloss over the execution of many of these components. These components include:
Discovery that combines the design with the build
Developing a site for the day-to-day user of the Drupal CMS
Preparing manuals and documentation
Providing software user training (for the Drupal CMS)
Performing software QA
Offering software maintenance plans
The question is, “What is expected?” as customers/clients compare their experience with web projects implementing Drupal vs. proprietary software. And, with that, “What is possible?” from the agency perspective, keeping in mind the reality of the typical agency's resources and infrastructure may not always deliver to match those expectations.
Setting things up for success
If there is one thing we’ve learned about web projects over the years it’s that nothing is ever as simple as it seems, and the sheer number of ‘unknown unknowns’ at the start of any project make estimation of requirements and cost virtually impossible. That is, unless you do your homework. And by homework, we mean Discovery. Too many firms still have not embraced more thorough preliminary research before committing to price, features and deadlines. Much like with the software and intranet consulting firms, this work can often be treated as a separate initial project with the findings and roadmap being the key deliverables. Client and agency alike get a trial run at the relationship in a fair exchange of a smaller initial cost that pays huge dividends over the course of the resulting project.
One of the most noticeable aspects of any web project to the end user is how long it takes to show up on their screen. In truth, it’s likely one of the most critical aspects of design with regard to user engagement and conversion. Mobile usage in North America has finally joined the rest of the world in passing the 50% mark just this year in terms of overall web usage. Coupled with data that shows 75% user abandonment if a page doesn’t load within 5 seconds on a mobile device—that makes performance a powerful design consideration indeed.
A Performance Budget, set at the very beginning of the project, sets target goals for how fast the page begins to appear, how much data is downloaded, and how long it takes to fully render. By comparing the existing site with several competitors, a set of goals can be set targeting at least a 20% improvement over the best of the bunch. That’s enough to be perceptibly faster to the typical user, and becomes the benchmark by which design decisions can be made (images versus more fonts, for example) and success can be measured. Well-known designer Dan Mall wrote about how to create one, and includes a sample template to use (http://bit.ly/isoperfbudget).
While this is a relatively new concept in the industry, the tasks involved make it a critical component in both understanding and execution of a web project. Drupal is a perfect complement in how content types are structured and interrelated. Here again, planning is everything. Firms that work in a traditional waterfall fashion will likely go straight into making a site map, starting design, and then handing those designs off to developer to implement. Only then does the client end up seeing the resulting site—more often than not immediately finding that significant parts of the content are missing, or not structured in a way that will allow for best governance or responsiveness. The system is then immediately compromised, requiring remedial work or convoluted workarounds.
By embracing the idea of working through the kinds of content required at the very beginning, teams can document the fields and relationships required in a format digestible by client, designer, and developer alike. This gets everyone (literally) on the same page and allows for rapid prototyping in Drupal of all the required content types so the client can start entering some real content early on, identifying missing fields or relationships before it results in wasted effort. (Palantir wrote a great article and provided a sample spreadsheet here: http://bit.ly/isobuildspec)
This isn’t all there is to Content Strategy, but even embracing this aspect alone will save countless hours and endless frustration, to say nothing of the budget dollars themselves.
Likely one of the most challenging aspects both technically and conceptually in web projects based in a CMS is caching. The whole reason the client wants a CMS is to be able to publish content whenever they want, immediately seeing that change reflected in the live website. But they also want the site to be lightening-fast, and querying a database multiple times for every page can be slow. So content caching, or storing ‘pre-rendered’ page content for a length of time is often put in place to ensure speedy response from the server. This push and pull between immediacy and performance is both hard to manage and hard to explain. It’s a common practice in large-scale applications to heavily cache data in order to provide faster response to the user it’s much harder to explain conceptually to the client why when they hit publish, it may take minutes or hours for that change to show up on the public side of the site.
Drupal 8, with its ‘cache tag’ infrastructure, makes handling of caching content while still clearing selective cached parts of the pages automatically when new content is published. But unless that is tied into external caching and content distribution systems (like Varnish or CloudFlare), clients may still be frustrated by slow-to-be-seen changes in their content. Without identifying those needs early, client relationships and the success of the project can quickly become compromised. Breaking-news headlines and auction prices are two easy examples, but in truth this can become an issue for almost any site.
The often forgotten user
“Content editing is a very important part of why we originally selected Drupal. The ability to get into the site and make a change on our own terms is crucial.”
As we converge on the different elements of web design and Drupal development, there is often a stakeholder that is somewhat ignored in the planning, estimation, and execution of most projects. This would be the folks that use the CMS everyday to add content to their web properties.
In the software world, we would call them the “user” and significant time during development would be making sure these user’s need are met with regards to both functionality and user-experience.
The fact is, the “day-to-day” user of the Drupal CMS is often times resigned to a less than optimal experience, since in the land of budgets and deliverables, most of the focus is on the UX for the website audience rather than the CMS. Now, this is significantly improved with core features in Drupal 8, and the “user” group priority was acknowledged in a recent survey of the community - pointing to 49% of folks surveyed think that with future enhancements the #1 priority should focus on the user or content administrator. But, compared to proprietary software who can invest significant time and money on the “software user-experience” - those of us building Drupal sites have somewhat of ways to go.
The beauty of Drupal is that it is flexible and powerful enough to develop an optimal user experience given the proper time and resources. That said, most agencies are still not quite structured to be able to add the “software user-experience” to its portfolio of services. The additional shift will involve client buy-in in recognizing that part of building a site/CMS with Drupal geared for long-term success is investing time for it to be a good experience for the folks using it everyday. Again, contrast that with what is “expected” when an organization chooses to pay the freight for an Enterprise-level proprietary system. In all cases, displeasure from these users will eventually filter up the decision-makers when making decisions the next time around for the next big web project.
Where’s the manual?
If you are buying into the hypothesis that Drupal’s long-term success is tied to positive experiences by those using the software, than it would make sense to also prioritize putting together a “user manual” upon delivery. However, of our current clients for which Isovera did not originally develop the site, less than 10% were provided any type of documentation. Again, while this may not be a sole factor in measuring a successful Drupal project, we can surmise that 100% of customers purchasing a proprietary system are provided with some form of end-user manual or documentation.
What we know is that it is somewhat rare for an agency to have a technical writer on staff to write Drupal CMS user manuals. We also know from experience that most decision-makers approving budgets make documentation preparation one of the first cuts, if it is articulated as an added service in a line item. Again, a shift in approach and results is needed to counter this reality.
The concept of user training is nothing new in the software world, but another often missed deliverable in Drupal CMS launch and implementation. In most cases, we see somewhat of a “train-the-trainer” situation, but more times than not, a large percentage of day-to-day Drupal CMS users were never trained on the software that manages their website. Part of this is due to the somewhat lack of scalability in putting forth this type of user training - since, because of Drupal’s great flexibility, most of the content admin user experiences are pretty different from one Drupal CMS to another. And, whenever a custom solution is needed, time and cost go along with that — and another budget decision to be made with the agency and client.
Best practices development & QA
Isovera has taken on a decent amount of rescue Drupal projects. As we hear client stories, everything seemed ok when it was first launched and then problems started. From there, the agency of record may have done some troubleshooting, but have been stymied due to limited expertise, other client priorities, or the “fixed cost” nature of the contract.
Again, no software development project is 100% perfect out of the gate. Tweaks, fixes, bugs are all part of the mix. But, as Drupal has emerged to do great things with big projects - how embedded in a typical web project are things like automated regression testing or developer-quality version control practices?
At Isovera, we implement tools like Behat for automated regression testing to foster consistent and repeated functionality to help head off current and future problems you may not have even anticipated. Although this is just one example, it points to tools and processes that should be in place with any Enterprise-level Drupal CMS build to help ensure success with ongoing and future development.
Safety and soundness
From the agency perspective, having to put in place some kind of plan to deal with ongoing Drupal maintenance for a client website is oftentimes somewhat of an afterthought. Most have eventually passed along the the arrangement to firms like Isovera or hopefully, have a plan in place with a company like Acquia. It is often surprising to see, for many large firms that come to us with existing Drupal sites, how many do not have an arrangement in place and, in turn, have sites that are particularly vulnerable to security hacks.
Again, and a common theme, the agency’s inherent structure does not accommodate a Drupal support and maintenance team. It may have been written into a proposal based on an RFP with somewhat of a “we’ll figure it out when we get there.” plan. In some cases, agency’s have come to us to support one of their clients simply because the one person they had in place is no longer with the firm.
As we look at proprietary software, having that type of infrastructure in place goes with territory of running a software company. And, why many decision-makers (possibly not well-versed in open source software) are alarmed when they find out they may have inherited a Drupal site that has no maintenance contract — or even that they need to update the “software”. Since, the elephant in the room, to some extent, is even whether they have an understanding that they have software along with their website.
The good news is that there are more and more firms offering both low cost service and full-service Drupal maintenance programs. The key is making sure there is the understanding of the options as the agency and client are starting the project planning. It is also important to make sure this should not be a “nice to have”, but part of the cost of going with a Drupal CMS.
At Isovera, we have been building award-winning Drupal sites for almost a decade. We have also had our share of “less-than-award-winning” projects, as we have learned and evolved like our peers in the industry. Our solid reputation with Drupal has often resulted in being called upon midway into a project or after launch to help troubleshoot, fix, or even blow-up and start from scratch. Thus, we have seen and heard a lot of cautionary tales on approaches that jeopardize Drupal’s reputation for being a sustainable solution for the Enterprise.
The word “sustainable” is key here as we look to create long-term success with Drupal. Isovera works with many great agency partners who are always looking to deliver successful results to clients. That said, the challenge is moving all of the components identified in this article from “nice-to-have” to “required”. This does not mean that the agency has to perform all of these functions internally. However, it should be recognized that to deliver an Enterprise-quality website on the Drupal platform, you have to include all of the aspects that are generally included with its’ proprietary CMS counterpart and look to execute at a high-level. By doing this, long-term Drupal adoption will thrive long past the website launch date and the day-to-day user won’t feel “stuck” with a solution that does not fit their needs