The end of the site as we know it by Kevin Oleary

The corner of the web I work on is Drupal, the open-source CMS that powers 2% of the entire web measured by sites (much much more if you measure by page-views). Recently we launched Drupal 8, a huge milestone for us. It brought fully responsive design, object oriented code, built in REST, configuration management and a host of other improvements. At the same time it opened up so many doors to functionality that had formerly been hard to come by. The explosion of new options is now starting to challenge our fundamental assumptions about how Drupal could or should be used. The time is right to begin to re-think some of these ideas, and as we do I think we might uncover ideas that could be adopted across the web.

It’s not about the language

The world has changed since the beginning of Drupal when PHP was the upstart. Javascript is the new king of the hill, REST APIs are now the primary protocol of data exchange, developers are moving from monoliths to microservices, and everyone is focussing more on the end-user experience.

Businesses don’t adopt new technologies because they are “cool”, they adopt them because they address immediate, painful problems. Yes, we need to take a hard look at the limitations of PHP and the benefits of client-side frameworks as Dries (founder and project lead of Drupal) has suggested. But we also need to take a deeper look at what these technologies are for and perhaps challenge some of our fundamental assumptions.Identifying the problems

Over the years we’ve dealt with many big customer issues at Acquia. I've taken a swag at boiling these down to the biggest problems customers deal with most often.

  1. Retooling cost:
    I can’t change the design of a site for > six figures.

  2. High skill bar:
    My designers can’t make updates without a developer

  3. Poor usability:
    My authors refuse to write in the CMS so I have to copy paste then fix or rewrite the markup

  4. Single points of failure:
    If my 400 page site goes down I’m #&%$ed

  5. Deep tech debt / shallow talent pool:
    I have 200 Drupal codebases and 20 Drupal developers

Most of the pain points above can be laid at the feet of overloaded monolithic sites. Retooling, eg, updating the CMS or the site design, for example, often involves mostly theming work because themes in Drupal are global and, through the evolution of Drupal 7, became increasingly complex and bloated. Staying with themes for a second, there's no easy way for designers to create Drupal themes without a developer, and again this is related to their size and complexity. If themes were more granular and tied to, say, components, it would be far easier to make individual presentation elements configurable. Looking at usability, again we run up against the sheer scope of UX issues open across a large and complex CMS, many of which involve site management and not the content authoring issues that impact a far larger number of users. 

As far as a single point of failure is concerned, we already see many Enterprises using multi-sites like Acquia's Site Factory and other federated solutions to mitigate risk and speed up development, but nobody has yet developed a good solution for sharing configuration or brand styles. The last point, technical debt and shallow talent pool, can't be entirely laid at the feet of monolithic sites, but it would certainly be mitigated systems that more broadly share content, configuration and presentation. 

I'm not the first to point the problems of monolithic sites but the bulk of the solutions I hear today—like stripped down, lightweight content APIs or flat-file CMSs—focus on the "monolithic" part not the "site" part. Systems like Drupal have grown more complex to handle more complex needs and stripping away that complexity is not the answer. In my view the problem is the site. If you think for a second it’s hard to even remember the original business case around having “sites” in the first place, apart from their origin in structuring sites as files in a single document root directory. It's time we consider abandoning them.

Keep it lean

If I were to re-invent the CMS today this would be my lean hypothesis:

The biggest obstacle to delivering maintainable content rapidly, with low overhead, and creative freedom, is the outmoded concept of the “site”. By moving content management out of individual sites and up to the level of the entire organization, we liberate content creators and enable them to meet those goals while at the same time introducing massive economies of scale.

The age of the page

So if it’s not sites then what? The next step down from the site is the page. Mobile-first, responsive design has already made pages more lean and focussed and we are unlikely to see a return to complicated layouts with many panes and facets. We are already seeing the rise of “Landing Page Builder” apps and services. This focus on the page makes sense. It’s the standard serving size of content on the web, and it can live at a single URL. Of course there are already single page apps, but my focus, and Drupal’s sweet spot is delivering content, not tools.

If we do re-focus on the "content" part of content management, perhaps the next generation is content modeling tool and API plus a render pipeline that can serve atomic “chunks” of content to any number of different sites. Front-end developers might question the need for any render at all, but remember “Having the freedom to code my front-end in my framework of choice” is not one of our top five problems. If marketers can simply feed rendered HTML including their global brand classes to any site in their organization without having to involve a developer, that’s a huge win.

Once we abandon the site and all the baggage that goes with it and let each page be it's own independent "node" managing content and presentation becomes much simpler and a lot of the duplication that currently exists falls away. But of course this raises many questions about how you would manage things like a global information architecture or content model, or how you would handle global authentication or error codes or any number of other site-specific functions that would need to become organization-wide services, but the point of this post is to open up that discussion, not to answer all the questions. Will CMSs be the systems that tie all the micro-services together? Maybe, maybe not. I'm inclined to think that another system, more closely tied to platform architecture would do the job better, and that over time all that organizing and routing of pages becomes "plumbing" enabling content creators to simply create and publish pages to wherever they want.