Is your automation stuck or siloed? Our upcoming webinar aims to get you automating like a pro, demonstrating the importance of simplicity, and delivering hands-on guidance. Join us on Wednesday, February 3rd at 11am EST / 4pm GMT for a live discussion and practical advice on where to start. The session will also showcase Cutover’s Automation Runbooks, our solution for fully automating processes in a way that extends the value of your existing toolset. Register now
This is part 3 of a series of installments of our white paper: How to create an Automate-first culture without losing control. Missed part 1 and 2? You can read part 1: the problem with automation here and part 2: the different ‘flavors’ of automation here. We will be releasing the entire paper in installments on the blog - but if you want to read the full piece - you can download it here
Part 3: Bringing automation into the light
This is Marcus’ outline of the four common threads to automation that inform Cutover’s product strategy:
- Automation isn’t new, but it is often buried. As automation is by nature highly technical, it is often hidden in technical corners of the business. To be successful, automation has to be teased out of those pockets and made more visible and consumable by the business. Our learning: Automation needs a business-friendly UI that is comprehensible, accessible, and can surface business and technical workflows.
- ‘Clutch control’ is needed to manage different speeds. It is very common for applications, tooling, and processes to operate at multiple speeds, and aligning timelines can cause issues. For example, in the DevOps space, CICD tools can completely automate your entire dev testing QAT cycle - but there is actually a huge number of scenarios where this process doesn’t cut it when going to production. What about when you have to train support teams (2 weeks before), inform Marketing (4 weeks before), or notify Sales (a week before)? Our learning: You don’t want to stop the rapid pace, but you need to operate at the correct speed and reach out to other key areas of the business at the correct time, so that they can keep pace.
- Find your ‘brittle’ spots. When the process you’re dealing with is inherently brittle, or when key dependencies are hosted in an entirely different space, e.g. mobile app release and approval, you need to figure out how to interact and engage with this process. Our learning: Some systems will be out of your control, so there needs to be provisions for dealing with these scenarios.
- Transparency and control. There are automation scenarios where the end-to-end process needs to be the same, or at least have the same ‘spine’, even if the granular elements are different or the same. This could be the case if you’re trying to join up 400 releases a day and need high-level consistency, with the ability to detail out the differences in each release activity. This is also often true when dealing with different cloud providers: the fundamental processes are the same, but underneath ‘the hood’ there are differences. Our learning: Customisation and templatizing enables standardization, with the ability to make subtle changes as needed.
Automation has to come from within the team it impacts
A big culture question that people often ask is: ‘Who should actually build the automation?’, with the next question being, ‘Who should drive it forward?’ As Jim stated in the session, he is a firm believer that the program team that ‘automates unto others’ is destined to fail. Why? Because the ‘receiving teams’ are resistant to this change and intervention. Automation has to be embedded into the people who are doing the jobs, in order to be effective - it can’t be enforced. After all, they’re going to be doing it, they have the tribal knowledge. This is where the advances in automation come into play - some toolkits are built like lego bricks - enabling teams to plug in the automation pieces without significant technical involvement or coding required.
Automation should change governance, not the other way around
Within your internal existing legacy, it’s highly likely that you’ll have lots of governance processes that were created when the processes were manual. This next piece of advice is very important and something that organizations often get wrong: your automation should change the governance, your existing governance should not change how you automate.
For a moment, think about change management as a process. It’s very collective and encompassing, with everybody coming together to poke and prod. But, when you think about the digital economy and its demand for new features - compounded with the pressure to keep up - you simply don’t want to have to wait two to three days to push something through Change Advisory Boards (CAB). You need to move faster than that.
But how? Find out in the next blog installment - or download the full white paper here.