Following up on Human is not database, database is not human...

Regarding the horrible non-intersection of databases and people at work, there are two main examples that I see every day: (1) requirements database; (2) status data.

As a systems engineer, I manage our "what is this machine supposed to do anyway" specifications in a requirements database. Back in the day, this would have strictly been a document, with topics organized by numbered headers (referred to as paragraph numbers). Over time these paragraphs were atomized into sentences and pushed into a database, each sentence getting a requirementID number. You can roughly guess someone's age at work based on how much they insist on referring to paragraph numbers.
There's a part of me that used to think of this an anachronism—get with the program, old guys—because I was brought up in the industry strictly using the requirements database.

I don't think like that anymore. Something was lost in the conversion—not necessarily information about the system itself (we can build the same thing in either format), but an understanding of how the various parts cohered into a whole. Systems engineers get caught up in requirementIDs and verificationIDs and it doesn't mean much to the people who do the work. The design engineers humor us because they have to—it's the systems engineering accounting of doneness that the customer uses to determine whether the design is done. (For good or ill.) But ask the systems engineer what the requirements mean, or how they interact, or any of the technical details how how to prove that the design does what the requirements want, and too often you receive a stare that looks like one of those deep sea fish roused from its habitat by nosy human in a submarine.

Anyway: there is a better way to bridge that gap, to transform the light-reading descriptive information to the technical model information to the design status information. There are different views of the same data, if you want there to be. To do so requires more interpersonal work than technical work, really. But it's so much easier to disregard the people and give them simply what your database architecture was designed to hold. That's wrongheaded and I'm going to fix it.

Regarding status data... put briefly, there has to be a better, more humane way to communicate to management about the status of [insert here] that is neither too rigid for the status giver (no more forms, no more spreadsheets, no more databases, PLEASE), nor too loose for the status maintainer (the poor person who has to design the system for keeping the information) nor too incomprehensible for the status user (who will torment us all with eroding definitions of what they want when they don't understand what they've got). It all gets held in a database (an Excel spreadsheet mostly), but never gets translated well from that format. It feels—and is— rigid. Yet the definitions and implementations are sloppy, which is ironic, something rigid should be easy to define because by definition it's not very malleable.