Deakin University has spent the past 18 months modernising its approach to software delivery, adopting standard CI/CD tooling and removing manual effort in order to get code into production faster.
In this week’s CXO Challenge on the iTnews podcast, director of software engineering Aaron Whitehand shares the university’s modernisation story so far, covering its adoption of DevOps practices, automation and standard tooling.
Software engineering as a named function is “relatively new” and sits in the university’s central IT division, which is known as eSolutions.
“The team is composed of about 45 people, which span the remit of application architecture, software development, testing, software operations, and DevOps practices,” Whitehand said.
“Even though they report into eSolutions, they’re typically dispersed out into a dozen or more different delivery teams.
“We work in a matrix organisational structure here at Deakin and so the majority of the staff in the team could be working with any or all of the business at any point in time in cross-functional delivery teams.”
Whitehand said that the “last few years” had seen a greater focus on software engineering as an internal discipline.
“Deakin has been embarking on a relatively aggressive modernisation of practices,” Whitehand said.
“We’ve been looking to modernise how we approach things there, and a key piece of that is automation, which is obviously part of any DevOps transformation and focuses on taking all the manual steps out of the process.”
Software development practices within the university were already reasonably “contemporary”; Whitehand noted that iterative development and agile methodologies started replacing waterfall-style delivery in some (but not all) projects about seven years ago.
The adoption of DevOps practices and tooling was more recent, and came about when the university engaged a partner on an unrelated IT project that used DevOps, exposing the internal software engineering teams to this way of working.
“We were working with a partner on an implementation, and through that we were exposed to some newer ways of working that really resonated with some people, including myself, in the organisation,” Whitehand said.
“It was after that engagement that we started to think about DevOps more seriously.
“We started to draft a strategy around how we would transform or start to adopt DevOps practices, and it grew from there.”
DevOps – and the possibility to move faster – was attractive to Whitehand personally as he reviewed his own work practices.
“I was actioning tasks on a daily basis that were manual, and they were very time-consuming,” he said.
“These were things like code reviews, working with peers, hand-offs to either security or handoffs to testers for other manual effort to take place, and obviously these workflows are a codebase by codebase consideration.
“So for me, the biggest eye opener was the fact that I could start to automate some of these low value-add activities, and start to deliver more value quicker to our customers.”
While the university had some IT process automation tools, these tended to have been purchased by small teams or for specific projects.
“We’ve had duplication of tools and varying levels of maturity over time,” Whitehand said.
“Some teams are not even using any forms of IT process automation, and that manual effort was quite large in those teams.
“With the duplication of tools, and a need to couple less mature tools with other open source or commercial offerings to provide certain features, we were either duplicating spend or having to educate a large number of people on a large number of platforms.”
That duplication of licensing and effort became unpalatable over the past year in particular as budgets tightened.
“Certainly during the current environment, we need to be conscious of our spending,” Whitehand said.
“Rationalisation came to the forefront and we started to look at how we could rationalise tools, but in line with that, how we can provide consistency and enablement of teams at scale.
“So we started to not only promote a consistent tool for use but we also created a platform engineering team – a central team that could actually enable other teams with a standard consistent approach.”
The consistent tool that was ultimately selected was GitLab, following proof-of-concepts with three potential options.
The university “started off with a very small 100-seat license” for GitLab, which Whitehand said was a deliberate decision for a “proof-of-adoption phase”.
“While we looked to uplift capability, we wanted to ensure success through a gradual, phased approach,” he said.
“And while we were modernising our practices behind the scenes as well, there was a lot to consider in how we would implement a tool like this in that gradual approach to ensure that our developers understood the concepts and not just the technology.
“Where we’ve moved to now is an uplift of our license to what’s called the Unite license, which effectively gives us unlimited users, and we can use this now to accelerate the adoption of the platform.”
That accelerated adoption is likely to mean GitLab is used outside of software engineering – by the university’s research operations but also potentially in student curricula.
“From an education and research point of view, we’re working with those areas of the business to understand how they can leverage the tool and how it would benefit them,” Whitehand said.
“There’s no question that DevOps is a standard practice in the industry at the moment, and I’m a strong believer that organisations that don’t embrace it won’t achieve the same level of success as their peers.
“This kind of exposure and success is true also in the new generation of learners that we have coming through Deakin, and providing that industry best-practice tooling and experience improves their level of employability.
“So as a part of our plan now, we have started to engage with some key stakeholders across those areas on those possibilities of integrating the services into different learning outcomes and research outcomes.
“We [software engineering] also can use these best practice offerings to give student interns hands-on experience in the tools from an enterprise context as well.”