The secrets of successful publishing architecture
How would you describe your website? An intuitive CMS filled with actionable insight? Or a scene of chaos featuring random directories, obscure frameworks and multiple languages? Plus a few things running that no one knows what they do, but they’re scared to turn them off. Just in case.
Never fear. You are far from alone. Both publishing and technology have evolved at lightning speed. The tools you work with and the way publishers earn a dollar have completely changed. And things will continue to change in the future.
“Our existing solutions were as convoluted as the requirements and the technology once available, full of loops and hacks and about a zillion more queries and requests”
Why do publishing websites get so complicated?
Publishers are now under increasing pressure to know more about their audiences, do more with the data they have and collect more data. It sometimes feels like a race to get new products to market. And the development teams that power these publications are also being stretched. This sometimes means having to go down unfamiliar paths where the results are uncertain. Over time, there’s the risk that without knowing it, you could end up replacing older systems with new ones that suffer the same problem.
This is a situation we witness time and time again. No one ever sets out to overcomplicate things. However, over time, a series of technical decisions leads to an over-engineered, nonstandard system that complicates everyone’s life. Sometimes these problems are the result of legacy technical decisions not aging well. That is OK; this often happens in the technology space but you should look to actively identify and address issues. They could well be costing your business!
When introducing a new technology, it’s crucial that your team understand all the implications.
The last thing your publishing business needs is the introduction of tech debt, which will be obsolete or come and bite you in a few years time
Common examples of over-engineering in publishing
1. Building bespoke functionality for problems that have already been solved
Why reinvent the wheel? If you know where to look, there are some high quality WordPress plugins out there. You’re throwing away a huge advantage if you don’t leverage them.
One example of this is the WordPress SEO plugin (Yoast). By using this plugin correctly, your site will be following industry SEO practices. This keeps (fickle) Google happy. And if you keep the plugin up-to-date, when Google updates its standards /requirements, you’ll also get that for free. Not to mention you avoid the upfront cost of building all of this functionality.
2. Unnecessary use of microservices
Microservices are the concept of building a series of small standalone micro applications that all talk to each other and end up being your application.
Micro services are a great way to break down and decouple complex functionality on a highly dynamic site. However, there are some drawbacks, most of which are unapparent until further down the line. With microservices you are committing to an additional tech stack that needs to be managed and maintained. Rather than one strategy and one application to manage, you now have a bunch of different ones. If your team is small, this can get risky.
If you have noticed these occurrences in your own business, it’s time to take a step back and reassess your publishing architecture.
How to build sensible publishing architecture
The Code Company has helped many online publishers transform their business results. And it always starts with sensible architecture. Here are a few fundamentals to our approach:
WordPress must always be your source of truth
At its core, WordPress is a great CMS. It scales really well and has a strong set of tools for flexible work and content customisation.There’s a reason why WordPress powers over thirty percent of websites globally. What WordPress doesn’t do well are things like wp-cron and wp-mail, but there’s even a solution to that.
Anything else you build should ultimately be secondary to your CMS. The most important situation to avoid is a master/slave setup where WordPress doesn’t know what’s going on.
Focus on what really matters to your publishing business
It’s too easy to turn every request into a 3-month project that needs 300-hours of development. Our ethos at The Code Company is to find the smartest, simplest and most efficient way to solve your most important business challenge. This means ignoring the distractions and unnecessary gadgets, and having a laser focus on the true problems at hand.
Is it time to rethink my publishing architecture?
Having read all of this, you might be wondering if you’ve outgrown your current system. Here are some signs that may indicate your website is in need of an overhaul:
- Are you spending huge sums on development to achieve what appears to be a fairly straightforward issue?
- Has your development team told you that something is not possible because of the “way it is built”?
- Are you spending half your budget just keeping the lights on for your WordPress stack?
- Is your AWS bill out of control?
Modernising your publishing website sounds daunting but with the right technology partner, it can yield results – almost overnight. Read how Private Media increased front and back end performance of their publication Crikey by 200%.
Want to learn more about sensible publishing architecture?
At WordCamp, Columbus 2019, The Code Company’s Ben May demonstrates how online publishers can build advanced functionality without over-engineering.
In this video you’ll see real-life examples of how publishers used WordPress to send bulk personalised emails, meet viewability targets and create ‘smart’ infinite scroll.
