Separating Configuration and Behavior in Automation

A workflow is a “behavior”.  It’s how a thing is done.  What makes a behavior useful is configuration.  What constitutes a “release”, what database to restart, what customers the “end of day” process runs for.  These are examples of “configuration”.

When automating, it’s important to separate configuration from behavior.  Here are a few reasons why:

Reliability

By separating configuration from behavior, you allow the “behavior” to move through your environment (dev, to Q/A to production) along with your software. As this happens, you’re testing your automation.  So by the time you reach production, you have tested your ability to deploy as well as the support processes around it.  As you do this over and over, maturity is achieved.  The reliability of your system sky rockets and risk sheds away.

Time to Market

The benefits of greasing the path to production are obvious, but there are some other considerations, too.  What if you have an opportunity to open a new office in another location or to go after a new market?  How fast can you build out infrastructure and be up and running?  If you have done things correctly, it’s just a matter of configuration because your “behavior” is already mature.

What if, you hire a new developer or two or three?  How much time is wasted as they figure out how to start an instance of whatever they are working on?  If done correctly, provision some equipment, tweak some configuration and have them push a button.

Being agile does no good if you can’t get new features deployed.  If you need a three day weekend to roll out new features, maybe your process is not as mature as you think. 

Cost of Delivery

As your infrastructure doubles in size, you cannot afford to double your staff and your risk.  Automation and separation solves this.  With a well thought out strategy, a very small team can manage huge environments.

Conclusion

In the next post, I'll talk about several ways this can be achieved.