Why automate?

This topic introduces you to the rationale behind using BMC Server Automationto automate managing your IT infrastructure. The topic contains the following sections:


"Why automate?" may seem like an obvious question to anyone involved in the business of automation. Certainly it does to us, the Cloud and Automation team here at BMC. Most people wouldn't argue with the abstract benefits of automation: improved time to market, better consistency of environments, reduced operational risk and downtime. But when we've been talking to our customers, we've heard time and time again that they're looking for ways to understand why and how they should be Automating, with a capital "A". After all, isn't automation just throwing together some Puppet modules to set up a machine?  Or if you use passwordless SSH and run a command on 150 servers at once, isn't that automation?

Ah, no. We think that automation is more than just having some scripts, or implementing Agile and referring to it as DevOps, or buying a vendor point solution that allows a user to make a change by pointing and clicking in a GUI. Automation is a discipline - a set of practices and good governance coupled with technology that allows you to manage your entire IT infrastructure as a well-oiled (and automated) machine. We at BMC want to help you get to that point.

A little background

Years ago, forward-thinking systems administrators got tired of repeatedly running the same tasks by hand. Instead they started using scripts to execute those tasks. In extremely large environments, one or two sysadmins in a group might combine their efforts and publish libraries of code to do common tasks: the first attempts to bring structure and flow to the work of administering IT. At the time, though, it was largely an ad-hoc activity: see a problem, write a script, document it, and move on.

The most common language in which to write automation scripts was shell, and then later Perl and Python. There were ongoing challenges with maintaining these scripts: quality could vary wildly; different versions of OSes and commands behaved differently, and as new people joined the organization, dissecting and reverse engineering what previous admins had done became increasingly more challenging. Eventually, commercial products entered the market to start providing a professional level of polish and structure on the same goals that had launched automation: driving consistency and speed throughout the IT infrastructure.

In today's world, things have changed somewhat.  No one doubts the benefits of scripting out common operational tasks, but the world has expanded considerably.

  • Configuration management is a discipline unto itself, where people use tools to reach a desired end state on a machine.  
  • Application packaging provides a method for bundling code, content, and configuration into an atomic, reusable entity that can be deployed onto machines.
  • Server Compliance can mean many things, but in many organizations there are mandatory security policies, either defined internally or imposed by external regulatory bodies, such as PCI, HIPAA, DISA, etc.

Surrounding these general types of activities are the governance that goes around managing infrastructure. Disciplines and methodologies like ITIL, Lean, and Agile provide a process model to help keep teams aligned as they build automation logic, along with the audit trails, output logging, and analytics that are part and parcel of today's regulated enterprise.  

With all of these competing technologies and processes, there's still the need for people to get things done, to create actionable technology and policy that enables infrastructure and IT to be managed easily and effectively. At BMC, we call these people Automation Engineers.

Automation Engineers have:

  • A broad understanding of data centers and projects - the era of specialization is over, and people need to have skills and understanding not just in servers, but networks, storage, and databases.
  • A desire to do things the right way, even when that might require a little more upfront effort than doing something once.
  • A readiness to collaborate and share with their peers - the days of a lone engineer scripting in a corner are long gone.  Today, sharing, aggregation, and documentation are key.
  • A will to lead - to set a good example on how IT needs to be managed.

Let's get started!

At BMC, we want to drive education and innovation around these areas. "DevOps" may be getting all the press these days, but we think that DevOps is a subset of the larger discipline of Automation Engineering, which encompasses not just the intriguing and high-potential world of Agile IT but also addresses the realities of businesses that have complex processes with many stakeholders.

Beyond the process angle, we recognize that perhaps we're not doing as much as we could to help our customers understand the best ways to use our software and get the most benefits from them. So, we put together what we've been calling the Automation Academy - a series of walkthroughs, labs, and best practice guides to help our customers get the most out of automation and be the most productive automation engineers they can be. We'll be releasing the content in stages, the first stage focusing on simple use cases and the basics of using the product, with subsequent stages becoming more complex over time.  

Each page is designed as a self-contained discussion on a particular topic. These pages typically are not meant to be comprehensive or reference documentation, but rather quick guides to show how to use a particular feature of the software.  There's a section at the bottom of each page with links to additional resources, typically the reference documentation on that subject, or a page on our community site for discussions of that topic.

If you're not already a member of our BMC Community website, please visit: 


And register - there you'll find great discussions on these topics and many others. 

Where to go from here

How does BSA work?

Was this page helpful? Yes No Submitting... Thank you