Flattening DC Move projects.

  by Charles Rattray | 24 Oct 2008 | Permalink |

Talking to a configuration manager earlier this week with a looming data center move ahead them, it was interesting to hear about the company’s ‘fact gap’. This company has approximately half a dozen configuration management tools deployed, each implemented with varying degrees of success across the IT estate. As each CM tool has gone through the product deployment process, they have generated more, but incomplete available data. Similarly, as their environment has grown they face an increasing number of decisions each day about the way they manage IT and proportionally, as the volume of data increases, the resources available to complete analysis decreases. Today the configuration manager is only able to guess at the numbers of servers across the estate. The DC move is 6 months away.

Given the variety of CM tools available to this organization, the configuration manager has no single source of truth, and internal customers and consumers of this data wrestle daily with spreadsheets, emails, meetings and word-of-mouth comments in order to collect their facts. This leads to the fact gap. To use Rudolf Melik’s definitions (in “The Rise of the Project Workforce”) data in context provides us with information, while information in context provides us with knowledge. In other words, actionable information comes from knowledge. For a DC move project, the data about the servers, applications, and technologies being moved needs to be accurate, and correct. Knowledge about each component also needs to be presented in the context of all related components which make up each end-to-end business application. Otherwise the required knowledge to make the move a success is incomplete.

When planning a DC move, the end-to-end component relationships need to be known. From this we can deduce which components should move, which should be replicated, which should undergo some form of technology refresh, and which are actually redundant. When move time comes, the relocation team needs to know which physical systems to ‘lift & shift’ and which configuration changes need to be made in the process. The test and application teams on the receiving end need to know how the end-to-end dependencies should now map in order to check that they now do. Meanwhile, the configuration manager is between a rock and a hard place. Firstly, collecting the required data takes hours/days of manual audits. Secondly, what data is available is not in a single source, so when everything is moved, it is unlikely that these disparate sources of data will be correctly updated to reflect the results of moves and changes.

Those managing the moves face triple trouble. Firstly, they make decisions based on incomplete evidence. Then they make resource planning decisions based on assumptions that their data is correct. Then they have to compensate with additional work and correction activity each time an incorrect configuration is encountered. Finally, configuration errors which have the potential to be repeatable are difficult to search and check for because there is no one source of truth to check, even though the potential for the error is known about. Liken this to knowing there is a banana skin ahead of you, and then stepping on it.

Jim Carroll, in his book “What I Learned from Frogs in Texas” suggests that almost a third of a person’s working week is spent helping others to answer questions. Over half of these questions have been asked before, and for our configuration manager, not having a single source of truth means that configuration knowledge can never become institutionalized. Interestingly, in the same study, Carroll noted that 81% of respondents believed that it was important to share knowledge. If we park the consideration that knowledge is power and the political implications that this carries, there is no logical reason to continue provisioning the same knowledge over and over again to the same consumers. Instead, what makes more sense is a focus on automating the data collection process, and allowing others to become self-sufficient in accessing and using that single source of truth. This single source of truth can then act as a common vocabulary which in the case of IT flattens technology silos and brings back context to the available configuration data across the whole of the IT organization.

The net result of having a single source of trusted relationship and attribute data which flattens the technology silos and leads to a greater degree of collaboration amongst the different technology teams is simple. The looming DC move project is far more likely to be successful.