Automatic DBA

I really appreciate, in general, maturity models. They provide a frame work from which organizations can contemplative and improve, and in doing so provide a healthier environment to work in while becoming more efficient and profitable. Probably the most well-known is the Capability Maturity Model which evolved directly out of the software development process. There are some concerns with models like CMM in certain circles. But if you disregard the ideological hype and consultant-generating/copyrighted/patented materials, you can create a very cohesive structure that can effectively meet the necessary business objectives for a lower cost in a shorter timeframe.

Maturity models outline a framework that provides:

• A starting point for process improvement.
• A shared lexicon from which information can be exchanged.
• A way to define and document processes.
• A structure for prioritizing actions.
• A way to measure improvement.

I’m not married to a particular maturity model and the belief that goes with it. Rather I prefer to follow a common sense approach that can fit the organization’s idiosyncrasies. Additionally, following an unofficial model allows an individual to institute changes from the bottom-up rather than the top-down.

When it comes right down to it, process improvement is having a process that can be documented, executed, measured, and then evaluated for improvement. The best way to accomplish this is to automate all the repeatable steps in the process.

When I look toward process improvement, I take the following path:

1. I take an inventory of all known processes and assess the complexity of possible automation (the Risk) and the resources I could save (the Reward).
2. I prioritize the inventory list based on the Risk/Reward factor and available/desired tools and resources.
3. Using the prioritize list as a backlog of projects:
   1. Document and verify the process steps.
   2. Investigate and evaluate possible forms of automation, identifying which parts can be and can’t be automated.
   3. Generate the appropriate design documentation (blueprint) required to automate the process
   4. Develop the automation and supporting process measurements
   5. Test and validate the automation
   6. Integrate the automation into the existing process, updating the process documentation.
4. Once the process(es) are automated, reports can be generated to evaluate the process, find trouble areas and provide feedback back into the backlog.

We’ll look at more details as we progress…The next entry will discuss the Process Inventory.

This entry was posted on Thursday, June 28th, 2012 at 8:46 am and is filed under Automation, Documentation, Environment. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.