By Josh Koenig February 28, 2023 Twitter LinkedIn Facebook
When I talk to digital leaders about what makes an effective web strategy, the answer often comes down to hitting the right balance with governance. They want to be “the department of yes” and offer their stakeholders freedom and agency, but within the right framework to manage risk and cost. This is unfortunately much easier said than done.
We all know what happens when too many restrictions kill an initiative’s velocity: progress stalls, talented people quit (or check out), and ultimately the project falls off track. Goals are missed and then the blame game starts. Accountability gets really messy when internal restrictions turn into blockers.
But, on the other hand, too few guardrails and you may discover you’ve got a mess on your hands before long. Whether that’s brand violations, toxic data collection, security holes, an accessibility lawsuit or all of the above, it’s a five-alarm website fire with significant blowback. Nobody set out to be a bottleneck, but most organizations are “once bitten twice shy” when it comes to this kind of pain.
Too Many Eggs in One Basket
One reason it’s so difficult to strike the right balance with the web is resource scarcity. The traditional enterprise software delivery model forces everyone to work not just off the same CMS, but off the same instance. Everyone shares one piece of software and has to go through the same IT group when that software won’t let them self-serve.
It’s a recipe for frustration at scale, especially if that enterprise monolith has a high amount of complexity and isn’t something that regular marketing organization members can use directly. This is how, as our research has shown, 80% of teams find themselves unable to get changes to their website out in less than a week.
At the same time, the teams tasked with trying to manage all these stakeholder requests are just not in a position to move very fast. They don't want to be a bottleneck, but they're managing a really complex piece of software, usually without any kind of DevOps pipeline, test automation or other modern software workflows. Changes are risky, so they happen slowly.
Cloud Isn't a Cure-All
A lot of people probably thought the cloud would fix this, but for many IT organizations the first wave of “moving to the cloud” was primarily about deprecating equipment. That meant keeping things simple and using a lift-and-shift model, replacing existing physical infrastructure with virtual servers. That’s not a bad way to get started, but it’s not going to unlock any new value from a workflow or deployment perspective.
On top of that, most established enterprise web software isn’t cloud-native. The DXPs certainly aren’t. Even if you have a vendor-managed "cloud" solution, they’re likely deploying the old on-prem model, but using EC2 instances and an elastic load balancer. You’re still stuck with the same monolithic release process that forces a direct tradeoff between stability and velocity for your stakeholders.
The result is that glacial grind of feature/function updates, where every release is a white-knuckle event. It’s a recipe for team burnout, and in the meantime you’re struggling to respond to changing market or business conditions on behalf of your clients. You’ve got a one-size-fits-all solution and it’s getting pulled in six different directions, going nowhere fast.
Many Sites, Managed
But there’s another way. The real value of cloud — on-demand availability of software, not infrastructure — offers the potential to run hundreds or even thousands of independent website instances at low risk and competitive costs. This opens up fresh approaches to governance and with them an opportunity to reevaluate the possible, striking a new balance of freedom within a framework.
Imagine you could roll out a curated modern CMS distribution to all your stakeholders. Tools that meant non-technical people can self-serve for most common tasks. This application is centrally managed but deployed in a federated model so each website instance is actually independent, supported with its own WebOps pipeline, and running on isolated resources.
Your central team retains ownership over this distribution, allowing you to propagate feature development, security updates and other global capabilities to all the stakeholder instances. At the individual site level, stakeholders can make their own customizations while your team maintains oversight and governance.
This means any site in your portfolio can be safely tweaked and modified at the “last mile” – when warranted – by a local team that only has access to that specific project. That gives business leads full ownership over their web presence and lets them sign up to be fully accountable for the results. This is how you enable your whole organization to move at the speed of the market.
But it also means you can manage your own portfolio-wide updates without those high-stress “big bang” releases. You can still move fast if there’s a hotfix, but when you’re delivering new capabilities or performing a systems upgrade you can follow best practices in modern software management, e.g. using canary sites to de-risk a release, letting high-value stakeholders do their own acceptance testing if warranted, holding off on sensitive properties if they’re in mission-critical phase.
This flexibility around how you manage your web platform, combined with the flexibility you can deliver to stakeholders with modern CMS – one which they can ultimately own and control – is nothing short of magic.
Front-line teams can publish content and build out new experiences in real time with a low-code/no-code solution that’s tailored to their needs.
Business leads can truly own their customers' experience, including using their own resources or digital agency to evolve the design or augment the Martech stack.
Centralized governance is not only maintained but actually enhanced — breaking the monolith eliminates single points of failure, enabling a faster pace of releases.
Historically most organizations have had to pick one or two benefits, but now you can get all three. And you should accept nothing less.
You might also like:
- Website Governance Strategies for the Real World
- How Launching Fast With WebOps Adds 5+ Years of Life to Your Site
- Seven Steps to Escape the Website Relaunch
Topics: WebOps, Website Launch