Everybody knows this question to confuse a kid (or even an adult ;-)): “Which comes first, the chicken or the egg?”. I would compare this to someone ask me: “what should we implement first, automation of provisioning or automation of compliance and configuration checking?”
I don’t know the answer to the first question, but what I know that without chickens you can’t get eggs and without eggs you can’t get chickens. So the bottom line is that you need both, and who really cares what comes first when it’s time to get food in the plate. It’s exactly the same thing with Data Center Automation (DCA), you need both: automated provisioning and automated compliance checking – and both need to be integrated.
If you try to automate provisioning without automated configuration checking, and if you don’t want to have a lot of failures, you’ll need to manually check that targeted environments meet prerequisites, which means you won’t get as much value as expected. I remember some years ago a customer who wanted to test BladeLogic for Server for provisioning, in particular for full stack provisioning and independent deployment of technical agents, middle-ware, application upgrade. Their needs were to reduce cost of provisioning and time from request to delivery. When I started to explain to them that to meet their goals, they also need to automate configuration checks, their answer was that they know their environment very well, that they have a strong build and change management process that guarantees control and knowledge of configuration. I then told them that I didn’t understand why we were here if provisioning was already fully automated. When I learned that a strong provisioning process didn’t mean fully automated, I proposed them to use our solution to audit 10 rules of their configuration policy on 100 servers to test how well they followed their own process. Guess what: 50% of their servers were not fully compliant, with some severe security issues and configuration drift.
If you automate compliance without the automation of provisioning, you get a clear status of your compliance level regarding your policy, but no mechanism to efficiently remediate the drift and to avoid spending most of your operational resources to just remediate compliance drift. I remember the case of a bank who bought a dedicated tool to check compliance and this tool was doing his job very well, so that management could get clear status of compliance levels. However, there were thousands of configuration issues regarding the policies and week after week they couldn’t see much improvement. Operations were not able to remediate enough efficiently. It became clear to them that automation of compliance check and provisioning automation needed to be integrated.
Behind this there is a basic reality: to automate operations you need to normalize, but normalization changes over time because of technology evolution and business requirements. Enforcing normalization means you need to be able to check and remediate drift in an efficient way. So, like for the chicken and egg, if you want to achieve DCA and get value from it, no matter from where you start first: compliance automation or provisioning automation ; you need to have both integrated.