Enterprise Database Management & Monitoring

Redesigning database administration so that expertise didn’t leave when senior DBAs retired.

Status Shipped · 1 patent awarded
Role Principal DesignerWith ACD, Junior Designer, Visual Designer, Design Technologist · PM from client
Context Enterprise software clientMainframe database administration suite · workforce-succession problem
Scope Interaction redesignWorkspace, investigation tooling, knowledge capture, collaboration
Methods
SME Interviews at NOCs Contextual Inquiry Usability Testing Iterative Prototyping Interaction Design

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.

The Design Problem

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.

The lowest-common-denominator answer
“Modernize everything visually. Replace the green screens. Bring DBA work into the present.”
Why that would have failed
“Senior DBAs are faster than your modern interface. Patronize them and they refuse the product. Drop new admins into the legacy tools and they never become experts. The answer wasn’t a compromise — it was a system flexible enough that both could work the way they needed to.”
What I Designed

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.

TWO USER POPULATIONS · ONE SYSTEM · FOUR PILLARS Senior DBAs command-line speed · expert mental models New Administrators visual entry · guidance · context Mainframe 2.0 one system · two workflows · zero compromise Workspace customizable modular home per functional area Investigator multiple view modes green-screen retained Paths auto-recorded investigation knowledge in the work Collaboration notes · tasks · expert directory team activity, not solitary work
Two populations with fundamentally different needs use the same system. Four pillars, each one flexible enough to serve both, not by averaging their needs but by accommodating each one fully.
What I Deliberately Did Not Build

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.

Replacing the green-screen with a single modernized view
The most obvious “modernization” would have been to retire the green-screen interface entirely. We didn’t. The Investigator retained the classic green-screen as a first-class view mode, not a “legacy” mode or a “compatibility” setting. It was equal in standing to chart, tabular, tree, and visual object-relationship views. Senior DBAs could continue to work in the paradigm they were fastest in, while new admins picked the visual mode that fit their mental model. Both choices were treated as correct.
A lowest-common-denominator interface
The temptation in two-population design is to find the middle: something not too cryptic for new admins, not too patronizing for experienced ones. The middle ends up working for nobody. The design rejected averaging in favor of flexibility. Workspace modules configurable by user, Investigator view modes selectable, Paths optional. Each population worked as it needed to.
A separate documentation effort for knowledge transfer
An obvious solution to “experienced DBAs are retiring with all their knowledge” would have been a wiki, a runbook system, or a structured onboarding curriculum, all separate from the act of doing the work, requiring its own time investment, and certain to fall behind reality as soon as it shipped. Paths captured the investigation as it happened.
Treating database administration as solitary work
The existing tools treated DBA work as a single-user activity, which contextual inquiry showed was wrong. DBAs leaned over each other’s cubicles, called experts on subsystems they didn’t know, and wrote sticky notes for the next shift. We designed collaboration into the data itself. A note on a subsystem that flagged that performance always degraded on Mondays was visible to anyone who encountered that subsystem afterward. The expert directory surfaced those with relevant expertise.
How It Works

Four pillars, one system, two workflows.

The Workspace

Customizable module-based home
Configured per functional area

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.

The Investigator

Focused contextual tool
Drill into problems, multiple view modes

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.

Paths

Auto-recorded · annotated · reusable
Knowledge management built into the work

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.

# A Path: auto-recorded navigation through a problem. # Annotated by the DBA who solved it, then named and shared. path: id: “performance-degradation-monday-mornings” recorded_by: “senior-dba@org” duration: “23 minutes” steps: – action: “viewed alerts dashboard” object: “subsystem-7B” note: “Performance alert at 09:02 — typical Monday pattern”action: “opened performance snapshot” object: “subsystem-7B” timeframe: “last 4 weeks” note: “Same pattern weekly. Investigate weekend processes.”action: “navigated to weekend job log” # … continues attached_to_task: “TASK-1247” shareable: true

Collaboration

Notes · tasks · expert directory
Built into every object, not bolted onto the side

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.

Result

A system both populations would embrace and a knowledge-capture system that addressed the workforce problem the client was trying to solve.

4
Functional-area workspaces
4
Investigator view modes
1
Green-screen retained as first-class option
0
Required documentation effort outside the work

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.
Patent Awarded

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.

Original Documentation

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.