How to make the case for automation architecture: 5 ways to win investment

Most engineers have an automation strategy at the level of personal productivity. It comes in many forms: from a simple scripts to configuration management to fully switching from clicks to API calls. The move makes sense: Engineers build tools that make their daily lives easier.

Enterprise Architects, whether aspiring or established, have a great opportunity to help others understand automation. At some point, automation goes from a science project by a handful of engineers to business-critical practices depended on by the organization to deliver software. At this point, Enterprise Architects–or should we say Automation Architects–can move to formalize these practices. The value comes from a shift in focus from optimizing individual productivity to optimizing the system itself.

So you commit to the change. You want your system to be as automated as your personal projects. But that commitment is not enough on its own.

No idea in an enterprise architecture survives without support from influential colleagues. However, getting buy-in from your peers or management to adopt automation solutions can be challenging. The psychology of change all but guarantees some pushback from others—what is different will be questioned at length. But that's normal: those who earn the reputation and status that goes along with an Architect role will not be deterred.

With this goal in mind, here are some considerations to help you be better prepared to embrace change and new work methods to fight back against the "we've always done it this way" response to adopting automation.

Start with a pitch

Change implies a need, and Automation Architects must think like business owners in those moments. That process begins with a pitch that is compelling enough to warrant change. Automation usually implies less manual work, so phrasing that pitch as a function of time can be quite effective.

One example for IT leaders frames it well: "It's taking us six weeks to deliver an offer, and now we're going to be able to do it in six minutes."

Getting to a crisp, time-based pitch that aligns to business outcomes will get their attention from the minute you start discussing the idea. Pitch development also helps validate whether you have something worth presenting in the first place. You know you're ready to further socialize the idea when it can be summed up in a sentence.

What problem are you trying to solve?

Next, it's time to tighten up the technical details. IT Architects of all types know that any new technology comes with tradeoffs. As the aspiring Automation Architect, your next step is to make sure you solve an existing problem and not just create a new one. To do so, share your vision with people from different backgrounds to get early feedback, learn about their pain-points, and put yourself in their shoes. If your experience is primarily in network automation, pull in the Cloud Architect and Security Architect. Seek out different perspectives and use this knowledge to improve the proposal.

While socializing your idea, take note of the difficult questions.

Can you describe the business benefits your solution will bring to the organization? Here is where operational experience is king. Knowing how information is currently processed, how different teams interact, and the existing tool ecosystem will leave an Automation Architect better positioned to gain mindshare. Any new solution will need a path toward seamless integration with current practices, people, and policies.

Will automation, in this case, help generate new revenue streams? Maybe increase speed by reducing the number of manual steps? What about cost savings through resource optimization? Or reducing the number of incidents or the Mean Time To Repair (MTTR), especially if it impacts your services/revenue? Keep in mind the multiplier effect if you can make something work across currently-siloed domains as well.

If these questions look daunting, start small. Look for low-risk, high-reward tasks, such as automatically creating documentation, updating incident case information, making small configuration changes across non-production environments, running compliance checks, etc. This is especially valuable if these are daily repetitive and time-intensive tasks. Getting a small win can build momentum for larger projects to follow. And set the expectations right from the get-go; you need to hit milestones to create momentum. Automation is more of a practice than a one-time solution.

The user comes first

If you want to drive adoption, make sure your solution is easy to use and accessible to the user. Before anything else, that means defining your user (or users). Is this automation for a specific team, or a type of developer, or part of operations? Which parts?

Think about how users will learn about it and use it. Where does it run from? Does it run on a local machine, through a ticketing system, or is it SaaS? How are permissions granted for the service? 

What is the user interface? Is it a CLI, API, or GUI? Or maybe all of them? Will users have to read an installation guide to get started, and where will this documentation be available? Documentation is essential, but examples are even more immersive!

You need to account for failure as well. For example, if things don't go as expected, how would the user rollback any changes? Are logging messages clear enough? Can Key Performance Indicators be sent to existing monitoring systems? How do we facilitate troubleshooting?

A project that takes these questions into account is fundamentally more usable.

Being clear with who this is intended to help and how they will use it is paramount to the success of the automation project. While new technology is exciting, it won't resonate with users right away, so you need to be crystal clear on how this will help them with their day-to-day jobs.

Security should not be overlooked

To truly lead as an Automation Architect, business value and business risk must both be taken into account as you consider technology decisions.

All automation requires controls. How will you restrict access to it? Your users will have different degrees of expertise, and you also want to prevent malicious actors from interacting with your solution. This can be particularly true when automation requires elevated privileges to accomplish administrative tasks.

How would you enforce corporate policies? Can you describe the traffic flows or interactions between IT assets? (Think about the impact on firewall policies.) Are you creating a trusted execution environment? The last thing you want is your solution with privileged access to systems and credentials being hacked.

Here is where multidisciplinary partnerships shine. Security Architects can help solidify a proposal, or they can get it shut down before it even starts. Be sure to collaborate internally and find the security expertise needed to bring your architecture to life.

Maintenance and scaling

Demos are often impressive and easy. The term "Day-2 operations" exists because the rest of a project's life is never easy.

There are telling questions hidden in Day-2 operations.

How would you iterate over your solution to course-correct once it is in production? What would be the process to update it after implementation? Would maintaining it be more time-consuming than the problem it solves? Who owns and operates the solution? Do you have any governance framework and operating model in mind?

While imagining the automation architecture, think about the flexibility available to you. There are different technology options, but don't get stuck looking for perfection. Know the landscape, the pros and cons of the alternatives you have, and DIY tradeoffs vs. leveraging existing solutions.

A strategic automation framework will help different building blocks work together to generate a business outcome at scale. So you have to ask yourself: If it works for one, will it do the same for ten? How will this solution integrate with the next one or existing ones?

Speaking of the business, what about business continuity? Do you need to account for High Availability (HA) and Disaster Recovery (DR)?

Once you make it through the big picture of Day-2 and beyond, your pitch is ready for more eyes.

Conclusion

Deciding to lead an automation effort is a great challenge for the company and for yourself. While the Engineer in every Automation Architect wants to optimize performance on day one, that time is more wisely applied to document the business case. Remember, shifting into an Architect role means a new responsibility to understand the business value, not turn the knobs on the new toys.

Having answers to this range of topics and questions will help you be better equipped to embrace automation in your organization. If you can build a coalition of other Architects, explore these questions, and pitch to the right executive sponsor, you are well on your way to being the Automation Architect the team needs.