Planning for your IT Automation Team

Tracey Flanders Published Aug 19, 2014 at 1:34 AM MST by Tracey Flanders Tags Cloud, DevOps, Automation  (1) comment

With constant infrastructure growth and the obsession to squeeze the most you can out of your hardware, automation should be on the top of your list. For those looking to save on operational costs, automating an entire platform build would save you a sizeable amount of time and resources.

If you're lucky, you have an endless supply of IT superstars. They can design, build, automate and secure an entire platform by themselves. Most of us don't have that, not because they don't exist, but because the enterprise is bigger than any one single person. You can't be everywhere; it only makes sense to split the responsibilities up into teams. That's what traditionally happens in many large organizations today.

In the past few years, I've seen a theme of building IT teams around the Design, Build, Run (DBR) model. Typically consisting of 3 separate teams. The Design team consists of architects that plan, champion strategy, define standards and have a good idea of what the big picture looks like. The Build team tends to create solutions around those defined standards in order to build out entire platforms. The Run team is typically concerned about the care and feeding of those platforms. Making minor tweaks here and there, capacity planning, etc. Not to say these roles aren't different in other organizations, but that's the general idea.

Now envision an end-to-end IT conveyor belt. Parts are Designed, solutions are Built based on those designed parts, the final product is placed into production to be Run. Hopefully all of these teams work in lock step; otherwise your conveyor belt may not always be producing results. You'll need strong collaborative team leaders to ensure it runs smooth.

So where does automation fit into the model? Frankly…everywhere. Could the Design team decide not to automate? But then the Build team uses automation to make their life easier. Now the Run team supports a black box they can't manually touch? Nor could they go back to the design team with feedback. It’s probably not the best approach.

 

 

 

The Strategy

 

Build a dedicated team that straddles the entire DBR model. The Design team should be your strongest advocates. Why? They probably introduce most of the technology into your organization today, along with instructing how it's to be used. They can ensure new technology fits within your automation design. Since they know the big picture, they would understand the challenges that both the Build and Run teams face.

The Build team should be able to use the automation designs to make their builds faster and more consistent. They would need to understand how to put all the pieces together to make a viable solution. What they shouldn’t do is have people on the team reinvent how they deploy a platform every time one comes along.

The Run team should have a clear understanding of how things work, think logic diagrams. Sure, they will need to make minor tweaks for additions and upgrades, etc. But they won't need to reinvent the workflow each time the system changes. Automation provides consistency, which promotes standards.

 

 

Hopefully over time each team adopts this mentality and decides to make it apart of their skill set. If your IT teams haven't done this yet, they probably never will. Dedicate a team and the resources to automate and educate.

 

 

Team Skillset

 

Depending on each team within the DBR model the skillsets will vary. Starting with the Design team, you'll want individuals who understand most, if not all, of the layers and challenges pertaining to infrastructure and application development. Their background should include architecture/design, building large platforms and creating documentation artifacts for other teams to consume. All candidates should be influencers. Not everyone with likely give up his or her tried and true manual methods. Demonstrating and proving how to automate those tasks will increase adoption. No one likes to be told they have been doing it the hard way. As I mentioned earlier, the knowledge depth will vary amongst teams.

For the Build and Run teams, you'll likely want someone who has specific experience in one or more IT domains. The team will be cross-functional across your IT organization, so collaboration will also play a factor. As far as specific technical skills, they need some programming/scripting experience along with familiarity of cloud solutions. Amazon AWS and Microsoft Azure are some of the more popular ones.

 

 

Benefits

 

Scalability, bring up identical resources to increase your applications horsepower. 

Consistency, build the same platform and use it for Dev or QA. Build environments as needed and tear them down when you’re done. 

Automation serves as your documentation. What better way to document than the actual steps that occur when a system is built.


If you ever desired to leave your cloud provider for another, wouldn't it be nice to conduct a cutover rather than a migration? Build your new apps in a new provider, sync the data and cutover databases, DNS, etc. Building manually in the cloud is a complete waste for large organizations that already have a substantial investment in infrastructure. 


Your security team will be pleased to know your systems follow standards and unauthorized changes can be automatically reverted back. Security breach? No problem. Automatically make a platform-wide security tweak and place your application back into production.

Imagine automating your entire Disaster Recovery process and actual test it, apples for apples.

 

Fears of automation

 

I won't have a job?
Advice: The reality there is yes; there will be less need for manual skills. But who wants to do all that grunt work forever? Embrace automation, ask your manager about training. Pick up a book and see what it's all about and increase your career marketability.

What programming or scripting languages should I use? What tools work best? There are too many choices.
Advice: Use what you're comfortable with. If you have little experience with automation, start small. Choose the tools you can afford. If you do it right, you'll outgrow that tool and need something more robust. There are plenty of open source tools that work well for many small to medium size companies. 

Someone just handed me a newly built black box that is easy as pressing a button to deploy. What happens if it breaks or needs to be adjusted? Do you call the single person, who built it, no, she left 6 months ago?
Advice: Involve all aspects of your IT teams. In a much smaller IT shop, you may have one person and a backup in case of a fire. In larger organizations, a dedicated team would be the best option, a central point of truth. This team would advocate and educated the other teams around automation tools and solutions.

I can't see what the automation script is doing. I don't understand the language it's written in.
Advice: Insist on building decision trees, to show the logic of the script. Actually, this should be the first step before you even write a single script. Make sure there are comments inside the scripts explaining the logic. Believe me, after 1000 lines of code and a week later, you won't understand your own script.

Automating things is hard? I need to understand my application, infrastructure and the business workflow.
Advice: Exactly. Doing all the heavy lifting up front requires a competent effort. But that second application won't. You'll use the framework you already have and add parts as needed.

 

 

Conclusion

 

Automation is truly to next step in the evolution of how technologies will be deployed. It's not a new concept, but with the adoption of Cloud, Software Defined Networking (SDN) and many others services, you'd be wise to adopt automation techniques. For those companies who want to lead in their industries, automating IT is an enabler.





Comments: (1)

Leave comment

We welcome your participation on our website. Please keep your comments civil and on point. Your email address may be used to notify you of comment replies.
By submitting a comment, you agree to these Terms of Use.


Login to comment on this article.