Drupal in Government
I’ve worked in and around the Federal Government web sphere for the last 15 or so years. Starting as a web publisher at DEEWR, upgrading to developer at DRALGAS, contractor for AGIMO, FaHCSIA, DPMC and more.
Now, while most of those acronyms don’t exist anymore, the technology they used, and the lessons I learnt while working on them has stuck around.
When I started at DEEWR, we were using Sharepoint. From what I remember, it was the largest Sharepoint server farm in the southern hemisphere, there was a team of twenty or so developers that supported it, and on my first day at the new job I went to a meeting where the developers were showing off a new feature they were creating that would send emails to content approvers automatically when a content editor marked a page as “Ready for approval”.
Three years later when I left DEEWR, that feature was still yet to be released.
I moved over to DRALGAS (Regional Australia, Local Government, Arts and Sport), which was a new ‘miscellaneous’ Department that was setup after an election, and I joined the web team, bringing the teams total up to three.
Now, we weren’t as big as DEEWR, so we didn’t need a giant server farm, so instead we went with Drupal. The very first version of the website was actually built in Drupal 6.
And thank your chosen deity of choice that we did, because over the next few years the Department was renamed about five times. Each time, the website needed to be re-branded, split, merged and new initiative websites would need to be spun up for short periods of time (I’m sure we all remember the fever pitch about constitutional recognition of local government).
We even had some pretty cool geospatial data being managed and displayed in one of our Drupal websites thanks to an open-source and freely available module we could download, enable and configure easily.
Each time there was a change, Drupal was flexible enough to allow us to achieve our goals.
From the outside the Federal Government probably looks like a giant marble slab. Huge, imposing, solid, immovable.
But the reality of the web sphere for Federal Government, is things are constantly changing. Every budget release leads to new initiatives that need websites created immediately. Every MoG (Machinery of Government, when Department names change) change means websites need to be split, merged, traded between IT teams.
With the use of Drupal, and the increasing use of GovCMS (Drupal, but run by the Department of Finance), we have the flexibility in both the software and the platform to be able to react quickly and release changes in a matter of minutes, not hours. And changes on the scale of switching domain names can be done with two or three staff in an hour, not a floor full of contractors over a weekend.
And on the topic of changes, C.A.B (Change Approval Boards) need to learn to be more flexible. Trying to make a simple change in Drupal while in the rigid structure of CAB systems, which are so often designed for the large “server farm” infrastructure, is so infuriating.
I had been working on a GovCMS site, and I needed to do a simple code release to add some styles to a new page layout. However, this technically classified as a “Code release change into Production” and so it set off alarm bells for the IT team.
I had to wait for the next CAB meeting (a fortnight away) to plead my case to release a few lines of CSS code.
Luckily it was a fortnight away though, because I had so many forms to fill in.
How many servers are affected? Where are they located? Is there on-site support to physically reboot the servers if required?
How long will it take to make the change? (Hours/Days)
How long will it take to revert the change if something goes wrong? (Hours/Days)
How much of the site is affected by the change?
If the entire site is affected, please attached written approval from the Monarch or other Head of State as well as a video of yourself with today’s newspaper stating you take full responsibility for the change
Now, I know where they are coming from. I’ve been on the sidelines and seen lots of code releases go wrong and I understand the need for checks and balances.
But the thing about Drupal and GovCMS is that code changes aren’t big deals. They are one click of a button, and you wait for ten minutes.
Specifically with GovCMS if it has worked in your Pre-Production environments, it will work in Production, because of the Docker system that the hosting provider (Amazee.io) uses, there is zero difference between PreProd and Prod. Same software versions, same ports open or closed, same code, even a cloned database.
Drupal is built to be flexible, resilient, scalable and easy to use. It is built for the modern website age where things need to be able to change quickly and easily.
So let’s see less record-setting server farms, five-day deployments and per-seat licence fees and more Drupal.
Disclaimer:
The content of this opinion piece was authored entirely by a human writer. The ideas, opinions, and expressions contained within are the product of human thought and creativity. The only AI-generated content in this article is this disclaimer stating that no AI-generated content was used, except for this disclaimer.
