Chalk Talk
When I start the process of understanding a system I’m about to automate, I do three things:
- I write documentation.
- I draw diagrams.
- I get other’s feedback.
Not to make this overly simplistic, but that is all that is required to get a detailed understanding of any system you need to automate. The written artifacts become the basis for system understanding. The feedback provides clarity and insight of system idiosyncrasies. Through discussions with team members, owners, and users, I will revise these artifacts many times until I have documents that allow me to fully understand and automate the process.
In a phrase, you have to practice chalk talk. Just as a coach will draw the tactics of a play on a chalkboard, you and your team must sit around the whiteboard and postulate what is possible, what is probable, and what the final product will look like. This usually is not done in a single session, but is a continuous process of research, discovery, and experimentation (even if it is just thought experimentation).
For example, when I took over as the Application DBA for the unit it was apparent that I had no idea what my predecessors did and how they controlled the chaos. We had five environments, not all of which were consistent and may or may not have the latest code base. Each code fragment (SQL object) was migrated separately; it wasn’t always put on the official build list (didn’t make sense to me at all). Each change required another script which in turn caused the same object to be modified in the same build, usually to detrimental effect. I could go on (and on…and on ….and on….).
Our goal was to proceduralize the entire database environment management process, automating as much as we could, and initiate process improvement. When I started initially documenting the loose process they used, I started to formulate the below conceptual automate environments process.
It took multiple iterations and many discussions with my team mates in the Environment Team to reach this point, but it provided a solid picture from which we could plan the automated build framework. We also had detailed discussion with the development groups and management. From there we:
- Investigated corporate and department policy and procedural issues.
- Talked to other groups to see how they manage database environments.
- Researched available tools and started procurement processes when necessary.
- Initiated experiments to see what worked and what didn’t.
After a period of several weeks, a picture emerged that looks like this…
From this picture we targeted three main items that, when done, would significantly reduce the time/resources necessary and lower the incidence of defects.
- Automate SQL Builds
- Automate TCW Script Preparation
- Automate Data Refreshes
Next, we’ll detail each one of these items and discuss how they were automated and review actual results.