Balancing Development & Delivery for Successful Digital Transformation

Government Case Study: How to Evolve, Scale and Mature Your DevOps Program

Paul Templeman

Director, Digital Sector,

Australian Sports Commission

Taking sport to the next digital age

To stay relevant, every industry and organisation has moved or is moving into the digital realm. This is as true for the sports sector as it is for any other. Paul Templeman , the Director of the Digital Sector team at the Australian Sports Commission (ASC) in Canberra, says that the ASC is the “peak government body for investing and supporting sport,” and includes under its umbrella Sport Australia and the Australian Institute of Sport. They also “support over 94 sports around the country.” To continue to do this successfully, “the small, multi-disciplinary digital sector team was established in May 2018.” The team is partly responsible for delivering on the commitment “to ‘prioritise opportunities to support and lead the transition to a digitally connected Australian sports sector’ [1] , according to the Sport 2030 National Sport Plan.” The “key product” to make this a reality is SportAUS Connect, “a digital identity, data and integration sharing platform for the entire Australian sporting industry.”

SportAUS Connect essentially has two main features. The first is a digital identity, which is a “federated identity,” meaning that a person’s digital identity can be stored across multiple management systems. So “identity brokering and consent management are really important,” along with “SaaS – software-as-a-service – and SSO – single sign-on – integrations.” Many of these are “off-the-shelf applications, and that’s what we use.” The second feature is specifically around “data integration and sharing from federated data,” which maps data from multiple systems into a single database. This allows it to be accessed from anywhere, much “like a master data registry. It is designed to bring together different systems and data sets across the multiple platforms.”

To achieve the stated aims of SportAUS Connect, working in the cloud and using DevOps was deemed to be necessary, especially because DevOps is ultimately about the agile relationship between Development and IT Operations. For the ASC this meant “going on a bit of a journey.” Ultimately SportAUS Connect is a platform for people to use, but so that it can be used across the sector and across the country, it took the digital sector team multiple iterations to get to their current state. The three iterations are referred to internally as “Alpha, Beta 1 and Beta 2.” For all three, “we started on Microsoft’s Azure DevOps platform” as the main source control. From there, all three iterations changed. In the Alpha version, the database was Azure Cosmos DB, a multi-model database service, which had “an emphasis on PaaS – platform-as-a-service,” meaning it was a third-party provider, and “the newer of the PaaS database services at the time.” The container – or packaged software platform – was “Azure App Services, which is Microsoft’s low end container service.”

For the Beta 1 iteration, “we made a number of changes.” Whereas previously the pipelines – or automated tasks – were done using Azure off the shelf products, now “we decided to move to Red Hat’s OpenShift pipelines, with Jenkins automation tooling behind that.” Security was a big part of the second iteration, so “as part of that, we changed our databases as well to PostgreSQL.” Before there was no security automation, “but now we introduced SonarQube to do our continuous security inspection scanning of the code.”

The difference between the Beta 1 and Beta 2 iterations was a greater move to “the OpenShift environment.” For instance, the Jenkins automation was upgraded to Tekton, which was not only “newer”, but designed to create “a cloud-native foundation.” Moreover, they moved the SonarQube security automation “to SonarCloud,” which is an upgraded version and also “the PaaS service of SonarQube.” And finally, “we introduced an enhancement to our database layer, adding Redgate Flyway, which is really a database schema management migration tool for version control.”

Lessons and next steps

Following their three iterations, the digital sector team “identified eight learnings:”

• Start with mind-set shits – To get the most of the rollout, “your team must be focussed on this.” Ideally it should be a whole-of-organisation mind-set to ensure success, “but at least start with your own team.” In fact, to ensure that they had the right team, the ASC “used an external coach” and that “brought the team up to speed.”
• Begin with PaaS and minimal tooling – There were three iterations partly because of various required upgrades, but also because “we didn’t try to do everything at once. We started with the basics, in our case Azure DevOps but it could have been another tool.” This way “you can learn as you go.”
• Containerisation is just as important as DevOps Tooling – In this kind of process, “too often we focus just on the tooling, but what sort of assurance we have around containerisation is just as important.”
• Roll out your own tooling for learning – Starting with free versions of complicated applications is a good way to start, both for cost savings and learning purposes. “We started with the open source version of SonarQube at low cost. But it is important to move to PaaS over time for sustainability.”
• Architect for scalability and cost – “Cosmos DB is a fantastic database, but for the size and stage of our project, it just wasn’t something that we needed to invest in long-term.” Scalability is also important, and “we try to replace different components over time, either as we find there are better options out there, or for cost or sustainability reasons. Tekton was a prime example.”

• Don’t forget your database layer – With databases, there are “always going to be schema problems and version control migration issues.” So that means thinking about which database is appropriate and how it can assist. “We often see a whole lot of DevOps work done but the database tooling is really forgotten about.”
• Look to emerging hybrid / multi-cloud standards – “It doesn’t really matter what cloud you use.” There are many options and many standards and opportunities that should be considered.
• Look for opportunities to automate assurance – “The cost of ongoing assurance continues to rise,” so automating it will bring the costs down. “The lower the costs of assurances are, the more we can start to focus on improving our assurance processes.”