MaTT: The MARS framework for DBA’s
So, as usual, Iâ€™m struggling to sit down and write; I know I should (itâ€™s good for the soul), but frankly, Iâ€™m struggling to put words to web page. As a method of jumpstarting my brain, I thought I would write about something simple and relevant to what Iâ€™m doing these days in my primary capacity: management.
When I took over the reins of a newly formed department of DBAâ€™s, I knew that I needed to do something quick to demonstrate the value of our department to our recently re-organized company. Weâ€™re a small division in our company, but we manage some relatively large databases (17 TB of data, with a relatively high daily change rate; approximately 10 TB of data change daily). My team was comprised of senior DBAâ€™s who were inundated with support requests (from â€śI need to know this informationâ€ť to â€śI need help cleaning up this clientâ€™s dataâ€ť); while they had monitoring structures in place, it wasnâ€™t uncommon for things to go unnoticed (unplanned database growth, poor performing queries, etc.). One of my first acts as a manager was to put in a system of classification I called MARS; all of our work as DBAâ€™s needed to be categorized into one of four broad groups.
Maintenance, Architecture, Research, and Support
The premise is simple; by categorizing efforts, we could measure where the focus of our department was, and begin to allocate resources into the proper arenas. I defined each of the four areas of work as such:
- Maintenance â€“ the efforts needed to keep the system performing well; backups, security, pro-active query tuning, and general monitoring are examples.
- Architecture â€“ work associated with the deployment of new features, functionality, or hardware; data sizing estimates, upgrades to SQL 2012, installation of Analysis services are examples. To be honest, Infrastructure may have been a better term, but MIRS sounded stupid.
- Research â€“ the efforts to understand and improve employee skills; Iâ€™m a former teacher, and I put a pretty high value on lifelong learning. I want my team to be recognized as experts, and the only way that can happen is if the expectation is there for them to learn.
- Support â€“ the 800 lb gorilla in our shop; support efforts focus on incident management (to use ITIL terms) and problem resolution. Support is usually instigated by some other group; for example, sales may request a contact list from our CRM that they canâ€™t get through the interface, or we may get asked to explain why a ticket didnâ€™t get generated for a customer.
After about a year of data gathering, I went back and thought about the categories a bit more, and realized that I could associate some descriptive adjectives with the workload to demonstrate where the heart of our efforts lies. I took my cues from the JoHari window, and came up with the two axes: Actions: Proactive â€“ Reactive, and Results: Delayed-Immediate. I then arranged my four categories along those lines, like so:
In other words, Maintenance was Proactive, but had Delayed results (you need to monitor your system for a while before you grasp the full impact of changes). Research was more Reactive, because we tend to research issues that are spawned by some stimulus (â€śwhatâ€™s the best way to implement Analysis Services in a clustered environment?â€ť came up as a Research topic because we have a pending BI project).
Immediate results came from Architectural changes; adding more spindles to our SAN changed our performance quickly, but there was Proactive planning involved before we made the change. Support is Reactive, but has Immediate results; the expectation is that support issues get prioritized, so we try to resolve those quickly as part of our Operational Level Agreements with other departments.
After a couple of months looking at our work load (using Kanban), I see that we still spend a lot of time in Support, but that effort is trending downward; I continue to push Maintenance, Architecture, and Research over Support, and weâ€™re becoming much more proactive in our approaches. Iâ€™m not sure if this quadrant approach is the best way to represent workload, but it does give me a general rule-of thumb in helping guide our efforts.