 Good morning, everyone. My name is Lindsay Homewood. So I'm the head of development at the Australian Federal Government's Digital Transformation Office. And we have a little bit of a problem in Australia at the moment, which is that there are over 1,500 individual federal government websites that we know about. We think the number may actually be closer to about 2,200 at the moment. And that's a lot of websites. And the problem with the way that the information and services are delivered through those websites is that we expect people have a mental model of how they have to interact with government. We organize the information and those services, and the delivery of that online around the way that the organizations within government are structured. And of course, people don't care about that. People just want to solve a problem. And they have to go to the government to do that sometimes. And so that leads to cases where people who we do research with, they just say, well, I just wing it, to be honest. I really need the big picture. And then building on top of that, when people actually go out to start a business, they actually end up designing that business. They have an entire process that they go through to minimize the level of interaction that they actually have to have with the government, which is sort of mind blowing when you think about it, right? And when we interview people who are doing similar sorts of things, they say, well, the whole experience has been a case of scaling back my expectations about what's actually possible. And then even worse, people end up paying other people to interact with the government on their behalf to sort of act as an intermediary and navigate that maze. And then we've got people who are saying similar things. They're saying that if you've got the experience, then it's just going to distract you from actually doing your own business. It's just better to pay an expert to do this for you. And even worse, the people that are acting as those brokers for the rest of government still have trouble interacting with government, because it's that complicated for them. We've got cases of people that have been on the phone to different government departments for 2 hours and 30 minutes. Absolutely crazy. So we have a bit of a problem, which presents a pretty interesting challenge for us within the Australian government at the moment, which is that we need to try and do the hard work to make delivering services online and using services online simple for users. And to do that effectively, we need to understand the who, the what, the when, the where of people interacting with government, why they're even coming to us in the first place. And to solve that problem, we sort of synthesizing a combination of design, mostly design, and a little bit of technology to deliver those services in a way that is clean, simple, easy to use, or clearer, simpler, and faster public services online. And that's what the Digital Transformation Office was created for in the Australian government to help the Australian government as a whole move forward in being able to deliver services in this way. So how do we actually make this happen? How do we do our work? Well, everything that we do within the DTO is about focusing on what the user need is, actually understanding why people are interacting with government, and then making sure that we're building services that are able to service those needs. And we do that by forming cross-functional teams of people from a bunch of different disciplines, not just technical ones as well. We have our developers. We've got our web operations security, but also people who have got backgrounds in service design, product management, content writing, as well as just plain old sort of product management or delivery management, that sort of thing. And so our philosophy is if we get people from a bunch of different backgrounds, they're going to bring a diversity of opinion together, and we're going to get the best possible outcome for the users. And this sort of harks back to this idea that we have, which is that the unit of delivery is the team. And delivery itself is actually the responsibility of everybody. There's no one person that's just responsible for delivery. It's the responsibility of the entire team. An interesting thing from a tech perspective as well is that we take that to the next level, and we say that the service delivery teams who are delivering that service, they have the responsibility of owning their own availability. They own the service end-to-end from inception to it going live, and once it's live as well. And so we have this whole process of validating early and often to make sure that the thing that we're building is the right thing for the user, doing that hard work to make it easy for the user. So we have a discovery phase, which is really focused on understanding what the journey is that users are going to be taking to be able to interact with government and why they're even coming to us in the first place. So we put these big storyboards together, and we get an understanding about what are the life events that have led up to the person interacting with government. And then from that, we come up with a bunch of hypotheses that we then try and test with a bunch of very minimal wire frames, and we do some prototyping of an app. And then we try and test that with the users to basically validate those hypotheses that we've come up during that discovery phase to make sure that what we're building is actually the right thing before we invest too much effort in building the wrong thing potentially. And then from that, once we work out what we're actually building, we go and actually build the thing. We take those working wire frames that we've got, and we start filling out the code behind the scenes and build sort of a minimum viable product to deliver that service to people. And the key point here is that what we're trying to do as an organization is to innovate on service delivery, not the actual technology itself. And to do that, we say that, well, let's try and standardize a bunch of the technology that we're using to make it easy for people to get on board and actually start delivering services in this way. And the interesting thing there is that we can take that and build a capability across all of government because everybody has got familiarity with the same tools. They all work roughly the same way. And we have a fairly opinionated way about the way that we work and the way that we use the technology. But that leads into a pretty good situation for government where we can actually start to onboard people faster into the project that we're kicking off to be able to deliver those services. And even better, we can actually take those contributions because we have a fairly opinionated technology stack and we can actually, because we're primarily using open source and what we do, we can then take what we're doing and actually contribute it back to the open source community so everybody can benefit from the stuff that we're doing. And again, this is about making the right thing easy for the people who have to work in the teams to do technical delivery. And Cloud Foundry is very much an important part of how we actually make this happen. It's part of that standardization that I was talking about a second ago. So what does delivery actually look like within the Australian government? So it looks at something a little bit like this. It looks like the number of deploys over time increasing. So this is a particular project that we were prototyping, a service that we're prototyping back in October. And you can see there that there's a nice uptick to all the deploys over time. And that actually interestingly maps to the number of contributors that were on the project as well. And so it looks a little bit something like this. We've got a bunch of different people who are working in like a local Git checkout and they're pushing those changes to GitHub. And then GitHub is then kicking off a Jenkins deploy so we have a CD pipeline for all this stuff. And then that's deploying everything to Cloud Foundry and then the user's access in the application that's running on Cloud Foundry. That's it, it's pretty simple. That's our standardized pipeline that we use. Regardless of what language the service is actually being written in. And then of course we make sure that we have very strong feedback loops throughout the whole process as well. So every time somebody makes a deploy, there's stuff that's dumped into Slack. Same with log messages, monitoring, all that sort of thing. There's one channel that the entire team is able to hang out in. They're able to see all the work that's happening across all the different technical streams. And that results in something a bit like this. You know, this is the prototype that we ended up shipping a couple of months ago. And of course true to our open source spirit and nature, we've open sourced all that as well and I invite you to go check that out. But the interesting thing about structuring delivery like this is that releases become a non-event which is a little bit atypical for the way that software releases are typically handled in government. And the other interesting thing here as well is that the process overall actually scale quite nicely as we added contributors. There were very few challenges that we found when we were adding additional people to the team to be able to keep working in this way. We didn't have to retrofit a new process onto the way that we were doing delivery. And the other interesting thing here as well as those contributions as a whole that were coming from the team weren't purely technical. We actually lowered the barrier of entry for other people, non-technical people within the team to be able to contribute to the prototypes that we were building. And so if you look here at the contributions graph over time, you can see the number of contributions going up and all the contributions that were coming through here they were from not just purely technical backgrounds. In fact, cute little thing about this, the top two contributors to this particular project were actually non-technical. They're actually content writers so we made sure that we gave the content writers the right tools to be able to work in Git but not actually know that they are working in Git. And all the changes that they made went through exactly the same pipeline that all of the other technical changes were going through as well. And again, goes to the idea that a unit of delivery is team, not individuals. So what do we think the teams actually need to be able to successfully do this delivery? Well, fundamentally, there's just a couple of very small things that they need. They need a way to get their code running in front of users so that we can get those very quick feedback loops to make sure that the thing that we're building is actually the right thing. They need some sort of insight into how that code is currently working or not, as the case may be, when we're making changes very, very quickly. We want to be able to recover from that and know what was going wrong. And then finally, we need to be able to get some sort of data to hypothesize about user and system behavior, to validate those hypotheses about the overall service design that we're undertaking. And all of those three things add up to basically just mean safety in when you're making the changes, to make sure that it's going to work in a reliable and repeatable way, and confidence that what the team is building is actually the right thing for the user. So the way that we sort of view it is that there's this high-level service and a service is made up of multiple apps. Maybe we're taking sort of like a microservices architecture where there's like a couple of small front-end apps and then a bunch of APIs behind the scenes. And then there's a platform that sits, that all of this stuff sits upon. And so we say, going back to that idea that the service delivery teams own their availability, that the service delivery teams own all of the applications and will provide the infrastructure to make sure that they're able to stay up. And then we provide an underlying platform for them to be able to do that delivery on. And it's not just the Cloud Foundry piece, which we'll talk about in a second. And so the DTO is providing that platform for people within government to be able to do that delivery on. And so we're tentatively calling this cloud.gov.au. And you can obviously see the illusions to what AT&F are doing with cloud.gov. Don't put this into your browser. It doesn't currently resolve. But this is sort of the tentative name that we're giving it for the time being. And so the whole idea with cloud.gov.au is that we're trying to make it easy for teams to be able to run, change, and measure the applications that make a service up as a whole. And so there are basically just three things that we're trying to do there. We're just trying to make the act of deploying and releasing software simple, fast, and painless. We're trying to help the teams by working in the teams and showing them how the tools work, make that journey to go live. And then as part of doing that work in those teams, we're trying to help them understand and impart a whole bunch of operational knowledge that we have a lot of on how to actually build a reliable, scalable digital service that's able to meet user needs but also stay up. And again, the whole idea with cloud.gov.au is to make doing the right thing easy. And we view the platform as something that teams will be able to use all the way from the alpha prototyping that they're doing to the MVP that they're building all the way through to the final live running of that service. So what is cloud.gov.au? Well, it's just these four things really. And Cloud Foundry, you can see there, comes in at the app hosting and the database layer. So it's very fundamental to the way that we're doing all of this delivery. We make sure as well, though, that all changes are going through a continuous deployment pipeline or a continuous delivery pipeline, depending on the risk profile of the agency. And so we can't push changes into production any other way. All changes to production have to go through a CD pipeline. We also provide a very simple logging service to give those teams the insight into what's actually happening across the stack. And we also provide a very simple monitoring service. And that's sort of an interesting point, because our sort of opinion on the way that monitoring should work is that the teams that are closest to delivering the service, the teams that are building the service, have the best insights into what the important things are to actually be monitoring there. So rather than being super prescriptive about the sort of monitoring checks that should be run, we provide a very, very simple platform for them to be able to write their own monitoring checks and actually version those monitoring checks alongside the code that they're writing for the actual application itself. And whenever a continuous deployment pipeline build gets kicked off, we also build a bunch of monitoring checks and we push that into the monitoring platform as well. So again, it's about making doing the right thing easy for those teams. And to do all of this effectively, we have to provide very clear integration points for building, testing, deploying, logging, measuring, and monitoring. And the key point here is that it's about defining very clear interfaces and not dictating an implementation to the teams that are actually building those services. They're closest to it. They have the best context to be able to make the right decisions. We enable them to be able to do that. We don't dictate how they go about delivering that service. So obviously, Cloud Foundry is like a really, really key point in being able to make all of this stuff happen. This is where we're bootstrapping our first foundation. And the interesting thing there is that we're making sure that by sort of enshrining that good operational practice that all delivery teams get zero downtime deploys is just a standard part of using the cloud.gov. That are you platform. And we're also relying really heavily on a lot of the other work that other people in government around the world for using Cloud Foundry have done. So we're taking great advantage of the AWS broker that AT&F have done a whole bunch of work on more recently, which basically allows us to use underlying AWS resources and expose them on Cloud Foundry, which is a great way of sort of speeding up the active delivery. We don't have to deliver all of the different services. We can use a bunch of stuff that's already there and provided by AWS. And so we started out using Jenkins. And more recently, we're moving a little bit towards CircleCI, which is sort of neat. And so an obligatory screenshot, we totally use it. And for this to work effectively, we need to have these clear integration points for building and testing and deploying, right? So the way that we do that is that we say that all teams have got to drop in two files into their repository, cibuild.sh and cideploy.sh. And so that's just the interface. We don't dictate the implementation of that. And we'll sort of stub out the basics of what's actually required to get the app running in the first place. But if teams want to be able to change the way that they do testing or the way that they do deployment, they just edit the files in their repository, and then they commit it, and then they push it. And that's it. They have the power to be able to do whatever they need to do. And so the interesting thing about this, from, say, jumping from Jenkins through to CircleCI, is that we can rely really heavily on environment variables, sort of extract our credentials and that sort of thing into the CI pipeline. But of course, through this approach, it actually becomes very trivial to move between different tools if you define this very simple interface and don't care so much about what the actual implementation is. So on the logging side of things, we use gray log, which is pretty neat. And the whole point about using gray log is that we want this traceability throughout the entire stack. So we want to know all the way from the HTTP request being captured by a low balancer through to the application, through to the underlying platform and the database. And we want all the logs from AWS and whatnot all in one place, so the teams are able to see, from top to bottom, how a request is being dealt with. And this helps, I guess, on two fronts. Firstly, on the debugging and the troubleshooting front. But secondly, around the security incident and event management side of things. So the point that I want to leave with you today is that Platform as a Service is incredibly important to being able to accelerate delivery within your own organizations. But I fundamentally believe that the Platform as a Service is much bigger than just the application runtime, which we end up focusing so much on. So the whole point about having paths in place is that it's a tool to help you make doing the right thing easy for your users. We fundamentally believe at the DTO that the technology is cheap. It's the people that are dear to us, and we want to be able to optimize that. So paths for us eliminates entire classes of problems that we just don't have to think about anymore. Very simple things like, how do I make my application available? Or maybe more complex things like, how do I actually recover from an outage? Because failure is inevitable in these sort of situations. So this is our first outage selfie that we took a couple of weeks into running our Platform. It's like, everyone say downtime. And the interesting thing about this particular incident was that the time to detection when we were running on our Cloud Foundry Platform was about four minutes. The time to recovery was about 12 minutes overall, not too shabby. But the most interesting stat in all of this was that the amount of human intervention that was required to be able to recover from this particular platform outage was zero, the platform itself just self-healed. And by the time we worked out what was going on, it had fixed itself. That's a pretty good position to be in from an operational as part of an ops team. So paths freeze up your teams to be able to focus on the bigger picture and think about the bigger picture about what's happening within your organization as a whole. Which is really important to be able to free up the people with really significant operational experience to help the organization as a whole learn what they know so that the organization as a whole is able to improve. And hopefully, they'll be able to help the organization learn how to deliver clearer, simpler, and faster services. Thank you very much.