In this interview, our National Director of Network and Cloud Security Jason Rader sat down with Jeff Bozic, principal architect, and Jonathan Parnell, senior consultant at Insight Cloud + Data Center Transformation (CDCT), to talk automation strategy. Here’s what they revealed about challenges, pitfalls — and how to orient your thinking for success.
Jason: Let’s start from the beginning. When organizations want to automate, should they start with the business aspects or jump straight to the mechanics?
Jeff: There’s a tendency to jump straight to the mechanics — the outputs. But automation is a broad term. You need to define your outcomes, your “why,” before even thinking about the “how.” If you’re only approaching automation at the technological level, sooner or later, you're going to run into a business problem.
Jason: Absolutely. A lot of people start with coding immediately and release that stuff out. How do you lay the right groundwork?
Jeff: Ask yourself, “What outcomes are we trying to achieve by automating? Why do we have those goals? Where does it make the most sense based on our current processes?” Think of automation as your “run” phase. You need to figure out your crawl and walk stages first.
Jonathan: I fully agree. I also think it’s easy to confuse automation with orchestration. Automation is very much about a set of repetitive tasks. Orchestration is about a lot of tasks working together to have an outcome. Automation should be thought of in terms of that broader ecosystem. Unfortunately, there's often not enough conversation that happens across silos to set teams up for lasting success.
Jason: I’m glad you mentioned silos. There’s a big culture shift that has to happen for automation and lasting transformation to work. What can organizations do to combat that?
Jonathan: We do a lot of automation workshopping with clients. At the end of the day, it's a relationship conversation. What things do I need from this teammate, in what amount of time, in order to do my job? What things does someone else need from me, and when, in order to their job? If you start with being clear about those boundaries, you can get really focused: "Okay, for this sprint or this month, there's two policies that I have to address to automate for." And you just cherry-pick them.
Jeff: For the technical person, that can be challenging because you're just so used to getting requirements and getting your work done. Very infrequently is there the time or opportunity to really understand the upstream and downstream effects and context of your work. Culture is deliberate, and you have to start doing things like creating social contracts and introducing cross-functional skill sets in the planning and designing phases.
Jonathan: Yes, start creating a culture of visibility. Getting mindful risk acceptance is really important. People need to feel responsible for security. I was a software engineer, and I saw security in the sprints.
Jason: Ok, so the groundwork involves leading with business outcomes and committing to a culture shift. Now what? How should organizations approach selecting tools for their automation initiatives?
Jeff: It’s a common misconception that tools are the solution. They’re not, per se. They're the enablers to the people and processes. Find the tools that can easily enable your team to do what they want to do in an easier and more efficient manner. And these tools and vetting process may already be in use by other groups like AppDev or DevOps teams if they have automated deployment pipelines — so look there first. See how their tools help them and if they make sense for you.
But outside of that, if your organization already has gotten on the path of investing in tools first, it can be counterproductive to wedge them in and then build your process/operating model around the tools. The trap is you will likely get some immediate benefit by doing that, but if the tool choice ends up not being the right one, you will quickly run into barriers, workarounds, and costs that are counter to the efficiency and outcomes you're trying to achieve.
Jonathan: A tool scales a solution — it doesn’t solve your problem. You should pick a tool when you're at the point of optimization that you can no longer scale that solution. Then you pick it. I would also add that it’s more important to actually put the right process in place to rationalize a tool versus picking the specific tool, because the tools are going to keep proliferating. You can't stop every quarter and have this long, loaded discussion on every tool. So that's a big kind of CI thing that you can put in place. How can we rationalize tools? You need observability. You have to be able to prove that that tool is not going to impact too many things.
Jeff: Don't be beholden to the tools that you have. Use them until they cannot be used anymore, whether it's because they can't scale anymore, or because they can't provide the feature set anymore. Maybe they're creating too much overhead, or they don't bridge the gap between teams. Whatever the reason, let the tool simply support and enable what you're trying to do.
Automate with purpose.
Automation initiatives can be a daunting undertaking. Get in touch with experts like Jeff and Jonathan to learn how we can help you create a thoughtful automation strategy that breaks down silos, boosts user adoption, and drives measurable outcomes across your business.
To watch the full interview, check out the LinkedIn Live on demand.