When automating a business process, be it figuring out when user meta-data needs to be eliminated or how to set up a certain type of server, there are certain orders of complexity you face:
- Do THAT.
- If THIS then DO THAT.
- If THIS then DO THAT, except WHEN.
- If THIS then DO THAT, except WHEN, but do it anyway IF.
- If THIS then DO THAT, except WHEN, but do it anyway IF so long as THAT isn't true.
- If THIS then DO THAT, except WHEN, but do it anyway IF so long as THAT isn't true or THIS is true.
An example for case 6:
IF a user is terminated, disable all of their accounts immediately and archive their data within 14 days; except if a manager puts a hold on it, but delete it anyway after 31 days, so long as the manager isn't a C-level or doing so would cause political problems at which point just don't bother deleting.
Try automating that.
This is the big problem with automating business processes: us humans glorify in our exception creation and handling processes, and we're damned bad at being consistent about it. The same is true about managing a fleet of servers; if it's fully manual the rules about what goes where are similarly complex. That 87 point checklist is a good sign.
When attempting to push out an Identity Management System project or a Configuration Management project a lot of the hard work goes into simplifying the complexity in the existing rules. This is not a strictly technical problem, it's a people problem.
You have six groups of developers deploying Tomcat apps. Yay standards! But each group has their own requirements for how they want Tomcat and the supporting JVM massaged.
The people problem here is figuring out how many of those differences are just mythology ("this blog on the internet said doing it this way would be bad, and had charts. We don't like bad.") and how many have technical reasons behind them ("we run out of private-bytes if we do it that way"). That's a lot of negotiation, gentle easings into new processes to smooth workflow, and a lot of technical handholding to reassure everyone that this really is a better way. Even after all that work you still may end up with Puppet classes like this:
- tomcat6::tc_repos
- tomcat6::helpdeskportal
- tomcat6::SNARC
- tomcat7::bbc_crawler
- tomcat7::HR_APPS
- tomcat7::buildSystem
Fighting entropy is hard, hard work. Technically hard, and socially hard. In this new devops era of programmable-everything, that entropy has to be encoded, cross-checked, regression tested, and maintained somehow. Entropy will win in the end, but you can at least kick the can down the road enough that it'll have a harder time stealing your weekend.
If you're lucky enough to face a greenfield environment deployment of some kind, maybe you're figuring out how applications and access will happen in a public cloud of some kind, you can at least put in rules and procedures at the start to help constrain the organic growth of exceptions. We... aren't always that lucky, sometimes we have to cram the entropy demon back into jail the hard way.
But if you do have the entropy demon in jail? Yay! But it's going to be a constant fight to keep the business rules encoded in the automation simple. Keep up the fight. You don't want the Eschaton bootstrapping on your watch.