The Human Resource Information System Canada (HRIS-SIRH) was the federal government’s bilingual hub for human resource policy, documents, news, and events. The deployment ran on Rodonic Advantage, the multi-tenant content management system that my then-partner David McGregor and I had built at Rodonic Corporation to power our federal client work. HRIS-SIRH used a pattern that wouldn’t have a standard name for another decade — pre-render at publish time and keep the database off the public web.
The system
Civil servants across federal departments needed a single trustworthy place to find current HR policy in English and French, and HRIS-SIRH was that place. Our deployment let department staff manage documents, publish news and events, and administer users and editors from a browser, in both official languages.
The build (and the interesting choice)
The platform underneath was Rodonic Advantage, a content management system we’d written in Classic ASP against SQL Server 2000, designed to run multiple client websites from a shared codebase as a multi-tenant CMS for our federal client work. The system-of-record bridge here was the same architectural shape documented in the Authors Guild SiteBuilder work that preceded it — a database the workflow team owned, talking to a publishing layer that had to respect both sides without forcing one to migrate.
The interesting craft choice was the publish step. Most content management systems of the era (ours included, when we started) rendered pages on every request by reading the database, running the template, and returning the HTML. Rodonic Advantage shifted that work to publish time. When an editor pressed Publish, the CMS wrote the actual HTML files out to disk, and the public website served those flat files.
That choice had consequences nobody planned for at the kickoff meeting.
The security envelope shrank. The public web server didn’t need a database connection at render time. The database lived behind the editorial wall, only reachable when a civil servant was logged in to publish. Most of the attack surface that web CMSes were getting attacked through in 2003 simply wasn’t present on the public-facing layer.
The performance was effectively perfect. Every page was a static HTML file. Caching at any layer (browser, ISP cache, government-side edge) was working with content that didn’t need invalidation logic, because it didn’t change between publishes. The pattern is now called static site generation. In 2003 we just called it “the publish button.”
What it taught me
For a couple of years on either side of HRIS-SIRH, Rodonic Corporation ran ASP and PHP development in parallel. The PHP rebuild work on the Authors Guild SiteBuilder used the same publish-to-static pattern as Rodonic Advantage, while ASP deployments like HRIS-SIRH kept shipping for federal clients. It took us about two years to recognise that PHP was the path forward, and a few more years to settle on WordPress as the platform. ASP and SQL Server hadn’t stopped working; they worked fine. PHP and WordPress were where the open-source community was building, and where the clients were starting to ask us to be.
The Rodonic Advantage publish-to-static pattern stayed with me longer than the platform did. Every time a WordPress site I’m working on faces a traffic spike or a security audit, the question I ask first is the same one we’d already answered in 2003: does this content need to be re-rendered on every request, or could the editor press a button and turn it into something the server can hand out without thinking?
