Enterprise Database Management & Monitoring
Redesigning database administration so that expertise didn’t leave when senior DBAs retired.
The client had a problem that went beyond software. Mainframe database administration, which is the work of keeping the systems that run banks, airlines, and governments healthy, was facing a workforce crisis. The soon-retiring experts were the only people who knew the languages and command lines the product required, and the software itself was part of why the field couldn’t attract younger IT talent. The tools looked and behaved like they were built in the 1980s, because many of them were. The directive was to modernize the software so it wouldn’t be a barrier to entry for new people, while simultaneously not disrupting the workflows of DBAs who had been doing this for decades.
Two user populations with fundamentally different needs working the same systems.
Senior DBAs could diagnose problems faster on a command line than most people can with a mouse. They had every keyboard shortcut memorized. They had built careers on a paradigm that worked. Any design that slowed them down or patronized their expertise would be rejected immediately — and they had the seniority to make that rejection stick.
New administrators needed something different. Guidance. Context. A visual foothold into systems they were still learning. The cryptic objects and metrics that senior DBAs read at a glance were, for new entrants, an unfamiliar dialect. A design that dropped them into that sea would fail them, too — and the workforce crisis would deepen.
To get this right, I conducted many SME interviews at NOCs and contextual inquiries with DBAs across experience levels — observing how they actually worked: the sticky notes on monitors, the knowledge passed between cubicles, the multiple applications toggled between during a single investigation. Multiple rounds of usability testing with prototypes followed. The design that emerged was one both populations could accept, which in a domain this specialized was genuinely difficult to achieve.
Four core concepts that work together as a system: Workspace, Investigator, Paths, Collaboration.
This project took what had been a fragmented landscape of command-line tools and siloed applications and unified them into a single, visual, collaborative workspace. The four pillars structured that unification.
Each pillar served both populations, but in different ways. The Workspace allows senior DBAs to configure the modules they need while enabling new admins to start from a suggested set. The Investigator gave new admins multiple visual modes to understand the system state and gave senior DBAs the green-screen view as a first-class option. Paths recorded an expert’s investigation as they worked, allowing teammates to follow it step by step. Collaboration (notes on objects, expert directories, assigned tasks) turned the implicit knowledge transfer in the cubicle hallway into something the system itself could carry out.
The most innovative element was Paths. The system automatically recorded a user’s navigation through a problem, tracked every page visited and every action taken, and let that sequence be annotated, named, and saved as a reusable guide. A senior DBA could solve a complex issue once and turn the investigation into a step-by-step path any teammate could follow. Knowledge management is built directly into the act of doing the work, not as a separate documentation effort that would fall behind and decay.
The “modernization” ideas that would have alienated the experts and failed the new entrants.
Each rejection below is a place where the conventional answer to “modernize this old tool” would have either patronized senior DBAs or abandoned new administrators. The design avoided this by treating flexibility as the load-bearing requirement.
Four pillars, one system, two workflows.
DBAs created multiple named workspaces organized by functional area: database, systems, application development and security. Within each workspace, users added, arranged, and configured modules in either a grid layout or freeform mode, choosing from a library of widgets for alerts, tasks, monitoring, bookmarks, search, and more. The workspace accommodated individual work styles rather than imposing a single prescribed view.
When a DBA received an alert or picked up a task, they could drag it into the Investigator, which surfaced expanded context: suggested workflows, performance snapshots, links to related objects, and the names of team members with relevant expertise. The Investigator provided four view modes: chart, tabular, tree, and a visual object-relationship browser. Critically, it also maintained the classic green-screen view as a first-class option, respecting the mental models of experienced users rather than forcing them into an unfamiliar paradigm.
The system automatically recorded a user’s navigation as they worked through a problem. It captured every page visited, every action taken. That sequence could be annotated with explanatory notes, named, and saved as a reusable path. Paths could be attached to tasks, stored in personal collections, or shared to a common repository. A senior DBA could solve a complex issue once and turn the investigation into a step-by-step guide any teammate could follow.
Notes could be attached to any object or chart. A DBA could flag that performance on a particular subsystem always degraded on Mondays, and that note would be visible to anyone who encountered that subsystem afterward. Tasks could be created, assigned, and tracked with priority levels and attachments. An expert directory surfaced people with relevant knowledge. The design assumed database administration was inherently a team activity, even though the existing tools treated it as solitary work.
A system both populations would embrace and a knowledge-capture system that addressed the workforce problem the client was trying to solve.
Preserved
- Senior DBA command-line speed and keyboard expertise. The green-screen view was first-class, not relegated to legacy.
- Expert mental models. Modernization didn’t override how senior DBAs already understood their systems.
- The cubicle-hallway flow of expertise: notes, tasks, and the expert directory turned implicit knowledge transfer into something the system could carry.
- Team-level investigation patterns that the old siloed tools didn’t model.
Now possible
- A visual foothold for new administrators learning systems they’d otherwise need months to navigate.
- Knowledge transmission built directly into the act of working. A senior DBA solves a problem once, and the path can be followed by anyone.
- Cross-team awareness on every object. A note attached to a subsystem persists for the next person who encounters it.
- Expert discovery through the directory, surfacing the people who know the things that aren’t documented yet.
- The pattern ports to any expert tool with a succession-planning problem, such as legal research software, medical informatics, scientific computing platforms, regulated industrial control systems, or any specialized professional software where experienced practitioners are leaving.
The Paths concept produced a patentable invention.
The Paths, auto-recording an expert’s navigation through a problem and turning that sequence into a reusable, annotatable guide, was a patented interaction.
The artifacts that documented the system.
The work was documented across multiple deliverables: early conceptual sketches, complete interaction design documentation, a working prototype, and the underlying research from SME interviews and contextual inquiries. The case study above is a synthesis. These documents contain the details that made the system buildable.
Misty Cripps · Vaquita Design