Automation within enterprise IT is not a new topic. Whether it’s automating the creation of a user desktop or a server, the drive has always been to automate as much as possible to achieve faster time to market and efficiency. What has changed, though, is the number of infrastructure elements one can automate within an IT org. I still remember my first job in college 15 years ago where I used a variety of tools to automatically deploy and configure Windows XP simultaneously across 50 desktop machines for a classroom lab environment. Today not only can we automate desktop computer deployments but also servers, applications, and even networking.
This presents a daunting challenge to most IT organizations since they are faced with the fundamental question of, “How do we begin automating our infrastructure?” Most times this question is answered by picking an automation tool and then driving hard to automate everything over a multi-year project. Unfortunately these projects have a high tendency to fail since they they take too long to realize benefits and requirements change during the course of the project so the end solution while fully automated does not meet the requirements of today.
Instead, the question of “How do we begin automating our infrastructure?” should be replaced with “How do we jump start an open source & agile automation culture with our organization?” The table below provides some key differences on how these cultures differ:
|Siloed – Each team builds their own set of automation to serve their purpose and there is no collaboration or sharing between teams. There is a fear that by leveraging automation from another team, jobs or value will be lost within current team.||Open Source – Organizations encourage collaboration, sharing and contributing automation back which fosters not only speeds up the organization’s deployment of automation but also breaks down silos between different teams|
|Waterfall – Automation is built in a waterfall manner with a defined develop and test phase which makes it difficult to meet requirements in the end. Typically the release cycle for this is much longer as well resulting in a solution that does not meet the organization’s needs.||Agile – Automation is built in an iterative, sprint based approach allowing for more flexibility to meet critical requirements as they come up.|
Now the next question you are probably asking is “How do I go about building this open source & agile automation culture within my enterprise?” Over the years we’ve found these 4 principles have helped companies to get jump started
Standing up an Automation Community of Practice
Red Hat, of course, has been built on the strength of open source communities, so this should not be surprising at all. Beyond the open source project communities that we participate in, we also have created several Communities of Practice, which are open forums for internal teams to collaborate, and share information around various technology and business areas.
To have an active and vibrant Community of Practice around automation, there needs to be:
- Strong community leaders who can not only kick start this community but continue to lead it by organizing cadence calls, keeping the community page up to date, scheduling various events within the community to name a few.
- Incentivize participation by recognizing and rewarding members contributions to the community
Create a common GIT based repository for all automation code
This next principle pretty much goes hand in hand with the first. Creating a common GIT based repository for all automation code allows different teams to use the same code for their purposes, while also allowing more eyes on the code and thereby improving the quality of it. This also provides teams to get off the ground faster as opposed to starting from scratch.
You might be tempted here to use an older source code repository instead of GIT but avoid this temptation. GIT based source code repositories have become the de facto for open source communities.
Infrastructure as Code (IaC)
You can Google Infrastructure as Code (IaC) and find several much more detailed articles and blogs around this topic, but the quick version here is to get your teams and engineers within those teams to treat every single piece of infrastructure as something that can be configured via code instead of manual configuration. This provides a repeatable process for configuring the same piece of infrastructure while removing human error from the process.
Treat automation as a product instead of a project
As mentioned before, there is a tendency to think of automation as a waterfall project and build it in such a way. Beyond the drawbacks previously mentioned, this also causes downstream challenge where team members think that once the project is done, no more automation needs to be built. This couldn’t be further from the truth since your environment will continue to change over time so your automation will need to keep up as well.
By treating automation as a product within your organization, you can instead iteratively build the automation and release it faster which meets the key requirements that are needed right now. This does require embracing agile techniques for delivering work which can be challenging for some teams to wrap their head around if they’ve never worked in it before. If you have a team that’s never developed automation in an agile manner before, I highly recommend engaging an Agile coach to help you through this journey. The last thing you want is people to get frustrated and return back to delivering in a waterfall manner.
Adopting these 4 principles will not happen overnight and will require time and patience since at the core of it we are introducing people to a new way of working and culture. With time though, you will start to see your team(s) appreciate working in this new culture which will also have the great side effect of delivering automation much quicker.
Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Join the Red Hat Learning Community
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn