Technical Architecture
The architecture that we propose for web systems is designed to deliver the following:
Near-term flexibility: your team should be able to rapidly respond to changing internal needs or external circumstances on a quarterly, monthly, or weekly basis. This is largely about making the site easy to edit and update. New page creation should take no more than a day.
Long-term flexibility: When done right, you will have invested a lot of time and effort into the quality of your content. This is work you should never have to do again. The primary use-case here is a corporate rebrand down the road. In that situation, the creation of an entirely new look and feel for the site should be a much smaller process than the initial web system setup. It should largely be a reskinning.
There are four things we look at when determining what technology to employ to meet these goals:
Simplicity
Use the simplest tool for the job, and be realistic about the job to be accomplished. Simplicity makes it easier for your marketing and content teams to be nimble. Simplicity makes it easier for your development team to make improvements. Simplicity is cheaper, quicker to market, and has less things to go wrong.
Debt is real and technical debt is real. You always pay for it sooner or later — with interest.
Stability
Remember that your customers don’t know or care whether you are using the shiniest new technology under the hood, and it’s silly to make architecture decisions based on trends or fads. Look for a platform that has been around long enough to be proven, that has a good track-record of uptime and support, and that doesn’t change too quickly.
It’s tempting to choose a tool around the current knowledge on your team, but if that knowledge isn’t applicable in 6 months, you’ve lost long-term flexibility in the name of a perceived, immediate boost.
Security
If your company performs security audits or pen testing, or if you’ve filled out a single security questionnaire, you know that a system with a high-level of security is worth its weight in saved time and pain. For everyone else, be wary of any tool that needs constant, timely, and often hairy security updates. (Looking at you, Wordpress)
Speed
Speed is important on several fronts — speed for customers, speed for editors, speed for developers, and speed for deployments. Any piece missing those aspects will negatively affect your flexibility or achieving your business goals. Speed translates directly to effectiveness and conversions.
The architecture for a web system contains a few standard pieces and, typically, a couple pieces tailored specifically to your business objectives.
Headless CMS
A headless CMS — we use, and love, Contentful — is essential to the setup. That said, any headless CMS should do. The most important thing is that your content be separated from the design / code used to display that content. This enables you to completely change the look and feel of your site without needing to edit any of the content, which would cut the time required for a full site overhaul in half.
If you don’t use Contentful, any headless CMS should do, as long as you keep the 4 points above in mind. These points are why we don’t use Wordpress, by the way, as we bumped into some problems in all four areas.
Remember, you want something that any non-technical person on your team can happily update without feeling overwhelmed or intimidated. It is for this point, more than any technical reason, that we’ve found Contentful so reliable. When we hand off a site to a client, they rarely have trouble making updates and send only a few questions our way. This was not the case with other CMS’s we’ve used in the past.
Site Engine
A site engine is the underlying tool that actually generates the html page(s) that are viewed in a web browser by your customers. In conjunction with the headless CMS, this is the core of your tech stack.
The biggest rule we’ve discovered when considering a site engine is that a web application is a very different thing than a web system, and trying to approach them in the same way will lead to compromises, many of which only become apparent late in a project.
We prefer static site generators and have leaned on 11ty extensively in recent years. Some people find this surprising, but we find the advantages in each area — simplicity, stability, security, and speed — to be compelling. Delivering a simple, static html file in the browser allows us to more easily meet performance, seo, and accessibility goals while keeping an eye on future compatibility.
The benefits of a dynamic system, such as Next.js — which we’ve had lots of luck with on web applications — are rarely useful enough on a web system to overcome the additional technical debt and complexity. While a phenomenal tool, it just isn’t the right tool for the job (typically, though we’ve seen combination web app / web system sites where that rule of thumb doesn’t apply).
Web Host
The host is the area that tends to be the least contentious. We’ve had very good experiences with both AWS (s3 + CloudFront) and Netlify. If you do not have an internal technical team, the support provided by a company like Netlify is usually all you would need to keep a web system up and running. The few times we’ve encountered problems, it’s because AWS is down in an entire region — meaning large portions of the internet are also down.
Continuous Deployment
A tool that manages site builds and deployments is essential to an efficient system. Typically, a change to either our site content or code triggers the CI/CD tool, which then updates the site. GitHub Actions is what we reach for most often, but CircleCI isn’t far behind.
These automated workflows are also an excellent time to run code and accessibility tests on the site to make sure everything remains secure, functioning as expected, and fully compliant.
The Other Usual Suspects
The rest of the site architecture will be a mix of tools that fill smaller roles. Here are a few of the normal categories:
Lead Capture — This is the “form” tool used on the site to “sign up for the newsletter”, “get more information”, or sometimes “contact us”. Hubspot, Marketo, Pardot are among the players we see most frequently.
Analytics — We’ve already talked about metrics and the importance of metrics extensively, but you need a tool to capture that data. Google Analytics is, by far, the most common solution we see, but there are compelling offerings from companies like Heap and Fathom (amongst a host of others). The important thing is to implement it for the metrics you need and then use it.
Search — While not always essential, site search comes up more often than not. We like Algolia and have been pleasantly surprised by Pagefind on static sites.
Compliance — We aren’t lawyers and we don’t offer legal advice, but tools to help meet GDPR, CCPA, etc. laws are essential for most companies. Analytics packages are one of the primary places to pay attention to when determining if this is needed or not. Cookiebot, onetrust, and Osano are utilized by our clients the most.
Recruiting — While definitely not needed by everyone, on-site job boards that match the style of the web system are quite common (and becoming more common). We’ve had good luck implementing Greenhouse.