Web Inclusion – Tim Brocklehurst – Solutions Architecture Briefing – 2013
—
A recommendation from the solutions architect. This document sets out the thinking behind our proposal to migrate canarywharf.com from its current proprietary CMS to WordPress – and why, in spite of the prevailing professional scepticism around open-source platforms at the corporate level, this is the most architecturally sound, commercially prudent, and strategically future-proof decision we can make today.
—
The Problem With Where We Are
Every significant digital project begins with an honest appraisal of what already exists. In the case of canarywharf.com, what exists is a bespoke proprietary CMS that has served its purpose – but which now presents the organisation with a set of structural constraints that will only become more costly and more limiting over time. The system is opaque. Its architecture is known to a narrow group of people, several of whom are no longer with the project. Extending it requires specialist knowledge that exists nowhere in the general developer market. Licensing and support arrangements sit with a single supplier, which concentrates risk in a way that no commercial organisation of Canary Wharf Group’s scale and profile should be comfortable with. The platform is not wrong because it was a bad decision at the time it was made. It is wrong because the world has changed substantially around it – and the pace of that change is accelerating.
The web in 2013 is not the web of 2008. Mobile traffic has moved from an edge case to a primary consideration: For many sites, smartphone and tablet visits now account for the majority of sessions, and that proportion is only going in one direction. Responsive design – the practice of building a single site that adapts intelligently to any screen size – has shifted from a technical innovation to a professional baseline expectation. Content is updated more frequently and by more people. The relationship between a corporate estate and its digital presence has fundamentally deepened: Visitors expect depth, currency, and immediacy. Search engines reward well-structured, regularly updated content in ways that static or developer-gated CMS platforms simply cannot keep pace with. And the teams responsible for maintaining these platforms – marketing departments, communications functions, editorial teams – have neither the patience nor the mandate to route every content change through a developer.
But there is a further dimension to this project that makes the platform choice particularly consequential. Canary Wharf Group does not operate a single digital audience. It serves two distinct constituencies that have fundamentally different needs, different voices, and different content rhythms: The corporate world – investors, developers, media, prospective tenants – and the living world of the estate itself – the tens of thousands of people who work, eat, shop, and spend their days at Canary Wharf. These audiences require different sites. And those two sites need to be managed from a single, coherent platform by a single content team without duplication of infrastructure, cost, or administrative overhead. That requirement shapes everything that follows.
The Two-Site Challenge
Before addressing platform options, it is worth being precise about what we are actually building. We are not proposing a single website refresh. We are proposing two distinct digital properties that share an underlying infrastructure: A corporate site presenting Canary Wharf Group to the business world – its assets, its investment proposition, its development pipeline, its governance – and a front-facing site presenting the estate as a living destination, rich in the kind of content that matters to the people who spend their days there: What is open, what is on, where to eat, what events are happening, what has changed.
These two sites have almost nothing in common in terms of tone, content type, or editorial workflow. The corporate site is measured, authoritative, and relatively stable. The living site is warm, current, and updated constantly. But they share an estate, a brand family, and a content team. They need to be managed from the same administrative environment, drawing on shared user accounts, shared media libraries where appropriate, and shared technical infrastructure – without one bleeding into the other editorially or visually.
This is not a trivial architectural requirement. It rules out a number of platform options immediately, and it makes the case for WordPress Multisite compellingly.
The Sceptic’s Objection – And Why It Misreads the Landscape
I am well aware of the objection that will be raised, and I want to address it directly. WordPress is a blogging platform. It is what small businesses and individuals use for personal publishing. It is not, the argument goes, a serious enterprise-grade content management system appropriate for a landmark corporate estate and one of the most recognisable business addresses in Europe.
This objection was more defensible in 2009 than it is today. WordPress has spent the past three years establishing itself, beyond any reasonable argument, as a general-purpose content management framework. The introduction of custom post types in version 3.0 – the ability to define entirely bespoke content structures entirely independent of the blog post model – was the architectural turning point. Since then, the platform has matured rapidly. Version 3.6, released earlier this year, introduced improved autosave and post locking for simultaneous editorial workflows, a refined audio and video management interface, and further stabilisation of the Multisite architecture that is central to our proposal. Theme development frameworks have become genuinely sophisticated. The REST API groundwork is being laid in the developer community, anticipating a more open, integrated web. Commercial agencies and enterprise organisations are using WordPress seriously and at scale.
Most pertinently: WordPress Multisite – the capability that allows multiple distinct websites to be run from a single WordPress installation, sharing a single codebase, a single database, and a single administrative environment – is now a stable, mature, well-documented feature of the core platform. It is not a plugin, not a workaround, and not a compromise. It is the right tool for exactly the multi-site, single-infrastructure architecture that this project requires. The BBC, the University of Harvard, and Reuters are among the organisations running WordPress Multisite installations at this point. The “it’s just for bloggers” argument does not survive contact with that list.
The real question – the architecturally honest question – is not “Is WordPress a blogging platform?” but rather: “What are the structural properties of this platform, and do those properties serve Canary Wharf’s needs over the next decade?” When we ask it that way, the answer becomes considerably clearer.
The Competitive Landscape in 2013
Let me be precise about what we are choosing between. The enterprise CMS market in 2013 is dominated by a familiar cast of proprietary systems. Sitecore is the most frequently cited competitor in the corporate space: A mature, capable, and genuinely sophisticated platform. It also carries substantial licence fees, requires dedicated Sitecore-certified developers whose day rates reflect the scarcity of that certification, and creates a supplier relationship that is difficult and expensive to exit. Its multisite capability exists, but it is complex to configure and expensive to licence at scale. Episerver is comparable in both capability and cost. Kentico sits slightly lower in the market but brings its own proprietary model and developer bottleneck.
Drupal deserves particular attention because it is the open-source alternative most frequently cited in enterprise contexts, and Drupal 7 – released in 2011 – is a genuinely mature and capable platform. It is powerful, highly extensible, and scalable to very significant traffic volumes. Its multisite capability is robust. It is also architecturally complex in ways that impose real costs on organisations that have not built internal Drupal expertise. The developer community is smaller than WordPress’s and the skill is less fungible – a Drupal developer is specifically a Drupal developer in a way that a WordPress developer is simply a skilled PHP developer working with a familiar framework. Maintenance overhead is higher. The upgrade path between major versions has historically been disruptive, requiring substantial manual intervention. For an organisation that needs its digital team focused on content and communications rather than platform engineering, this complexity is a genuine liability.
Umbraco, the open-source .NET CMS, has found a comfortable niche in the UK corporate market and its multisite capabilities are solid. But its developer pool is considerably smaller than either WordPress’s or Drupal’s, and its ecosystem of extensions and integrations reflects that. ExpressionEngine carries per-installation licence costs and a community that, while loyal, has not grown proportionately with the web’s expansion. Joomla has never established the clean separation between platform and presentation that makes a CMS genuinely sustainable at enterprise scale.
The bespoke build option – a custom CMS developed specifically for this project – must be addressed because it will inevitably be proposed by someone in this process. A bespoke system offers complete control at the moment of build and a guaranteed absence of unnecessary features. It also guarantees that every future change requires the original development team, that documentation will never be complete enough, that onboarding new developers will always be expensive, and that the organisation will be entirely reliant on a single supplier relationship for the foreseeable future. We have seen this pattern before, with the current platform. We should not repeat it.
The Multisite Architecture Case
The WordPress Multisite case for this specific project deserves its own section, because it is the feature that most directly addresses the brief.
A WordPress Multisite installation allows two – or twenty, or two hundred – distinct websites to operate from a single codebase and a single database. Each site has its own URL, its own theme, its own editorial team and permissions structure, its own content, and its own identity. From the outside, they are entirely independent. From the inside, they are managed from a single administrative environment by a network administrator who can manage users, plugins, and updates across all sites simultaneously.
For Canary Wharf Group, this means: One hosting environment. One set of security updates to apply. One plugin ecosystem to manage. One administrative login for the team overseeing both properties. Shared media where it makes sense – estate photography, logos, brand assets – and entirely separate content where it does not. The corporate site and the living site can look and feel completely different, be written in completely different voices, and serve completely different audiences, while running on infrastructure that is less complex and less expensive than two separately managed platforms would be.
This is not a theoretical benefit. It has direct implications for ongoing cost, for editorial efficiency, and for the organisation’s ability to add future digital properties – a dedicated events site, a retail directory, a development pipeline microsite – without adding infrastructure overhead proportional to each addition.
The Momentum and Developer Pool Arguments
In technology, the size and health of a platform’s community is a more reliable predictor of long-term viability than the sophistication of its current feature set. WordPress’s community in 2013 is the largest of any CMS by a substantial margin, and it is growing in the right direction: Towards professional, commercially serious development. The plugin repository contains tens of thousands of extensions. Theme frameworks have become genuinely sophisticated. Managed WordPress hosting is an established commercial category, with providers including WP Engine and Pagely building infrastructure specifically optimised for WordPress performance and security.
The developer pool argument is particularly important for an organisation of Canary Wharf’s scale and longevity. PHP and MySQL – WordPress’s foundation – are the most widely deployed web stack in the world. When Canary Wharf needs to replace an agency, extend the site, or add a new digital property, they will find no shortage of capable WordPress developers. More importantly, the relative cost of that resource is rational and predictable. This cannot be said of Sitecore, of Episerver, or of a bespoke system whose documentation will always be incomplete.
On security: WordPress sites are targeted by automated attacks at volume, because there are more WordPress sites than any other kind and automated attack tools target the largest available populations. This is not a structural weakness in WordPress itself. A properly configured, kept-current installation running quality plugins from maintained sources is not materially less secure than a comparable enterprise CMS deployment. The difference is visibility: WordPress incidents are reported because WordPress is everywhere; proprietary CMS breaches are less visible in aggregate, but no less damaging when they occur. Security is a function of diligence in configuration and maintenance – and we will be diligent.
The Architectural Case for Future-Proofing
My primary argument for WordPress is architectural. At its core, WordPress enforces a clean separation between three concerns: The database, which stores content; the theme, which controls presentation; and plugins, which extend functionality. This separation means that either of the two sites we are building can be completely redesigned – visually, structurally – without touching the content. Functionality can be extended without rewriting the core. Hosting can be migrated without rebuilding the application. When design conventions shift – and they will shift, more than once, in the next decade – the investment in content architecture is protected.
The Multisite architecture extends this principle across both properties. A security update applied to the core protects both sites simultaneously. A new plugin made available at the network level can serve both sites or either individually. The infrastructure scales beneath both properties together.
I want to be specific about what we are building on this foundation. The corporate site will model Canary Wharf Group’s content – properties, development projects, investment information, governance, news – as custom post types with custom fields, structured to reflect how the organisation actually thinks about its assets and its communications. The living site will model the estate as a destination – venues, retailers, events, transport, food and drink – in a content architecture that supports the frequency and variety of updates that a living, daily-use site requires. Neither of these is a blog. Both of them are bespoke content management systems built on a foundation that thousands of developers understand and that a global community is continuously improving.
The Commercial Case
WordPress is open-source. There are no licence fees, no per-seat costs, no annual support contracts with a vendor whose commercial interests may diverge from ours. The investment in this project is an investment in design, development, and configuration – assets that belong entirely to Canary Wharf Group, and none of which are hostage to a licensing arrangement.
The multisite architecture compounds this advantage. Running two distinct sites on a single WordPress Multisite installation costs only modestly more than running one: One hosting environment, one set of maintenance tasks, one security posture to maintain. The equivalent two-site deployment on Sitecore or Episerver would carry licence costs that would fund several complete WordPress builds over the same period.
Over a five-year horizon, the total cost of ownership comparison is not close. That is not a trivial consideration for any organisation, and it is particularly relevant at a moment when digital investment is expected to demonstrate clear commercial return.
My Recommendation
Build two sites on a single WordPress Multisite installation: A corporate site presenting Canary Wharf Group to the business world, and a living site presenting the estate as a destination to the people who are part of it every day. Commission themes for both that reflect the sophistication and authority of the Canary Wharf brand while serving their very different audiences. Model the content of each carefully, using the custom post type architecture that WordPress has made available and stable. Choose plugins from well-maintained sources. Invest in quality managed hosting built for WordPress at scale. And build this not as a three-year website project but as a durable digital infrastructure that the organisation can grow on.
My belief – and I hold it with the conviction of someone who has examined the alternatives carefully and without sentiment – is that we will still be on this platform in ten years’ time. Not because we will have failed to move, but because we will not need to.
—
Tim Brocklehurst – Solutions Architect – Web Inclusion – In association with Sutton Young – 2013