I have focused on DevOps work since late 2012 and found it a relief when it became known as automation engineering. This down-to-earth term distanced my actual work from the moot, semantic debate over the definition of DevOps. The description of the work captured by this new term was always self-evident, and it suffices to say, the field emerged as a result of increasingly complex architectures, and new platforms and delivery models. Now that the industry has started to gravitate towards the term automation engineering, we must also start to talk about Automations, which are outputs created by automation engineering. We already talk about them in terms of requirements, but that contributes virtually nothing to standardization. A description of standard outputs of automation engineering is not at all self-evident.
An Automation is a finished product represented in a set of output artifacts and meets the universal “definition of done,” which says, it doesn’t have to be done again for the same overarching use cases. It doesn’t necessarily seek to preempt every future use case either, but it is finished by virtue of being extensible with localized functionality. It’s operable, which means it has documentation and leverages common tools, frameworks, formats, and languages. It’s portable, which means it has self-contained sources, decoupled components, but a cohesive overall architecture. And it’s shippable, which means you can get it up and running from sources again because it lacks insidious dependencies on intermediate artifacts, long-forgotten config tweaks, unique platform features, and generally a dependency on being up and running already.
It’s also critical to discuss what Automations are not. The automation engineering field emerged organically and produced many failed attempts, some of which don’t even fit the definition of an Automation.
An Automation should not be treated the same as a typical software product. When engineers treat it as such, the output is usually a custom-built Platform as a Service, and their focus is now on shipping their own generic tool over providing a specific one that adapts quickly. This is fundamentally the wrong state of mind, and operable over maintainable should be the focus instead.
An Automation is not a unit defined by size or single format. For instance, its solution scope might encompass a great deal of tooling servers, or it may not encompass even a single one. So, an Automation has fluid scope with constituent parts simply called components, and in that respect, it is like a typical software product.
In later insight articles, I’ll be discussing what design principles and techniques form the foundational design of a good Automation. For now, the definition of a minimally viable one should be clear.