The pervasive nature of data continues unabated, leaving organizations more awash in data than ever before. Technology has enabled the access and leveraging of information to heights undreamed of a generation ago. Between corporate dashboards and internet Googling, vast quantities of information are truly at one's finger tips. Data-driven, domain-driven, model-driven ... the data itself is a force to be met and managed. When managed well, users never explicitly think about the databases that persist all that data. The database is an abstract idea, a place where data rests when not in use. Instead of this abstraction, users see application screens performing functions against their data; users see reports or reporting tool interfaces allowing them to play data games. Some users may even be engaged deeply enough with their data to spend time perusing a data dictionary in hopes of it offering new insights. When everything goes well, users have little need for DBAs. Likewise, under happy circumstances, data modelers are only considered when new applications or major enhancements are discussed. However, when things are not going well, unhappiness arises. Users will access screens that do not appear to operate as desired. Or users may execute reports that do not return data, or return data that seems other than what was expected. And when users find themselves in such unhappy positions, then people are called. Users call help desks or IT personnel with their problems. If the applications and reporting tools are functioning well, then calls trickle over to database support staff.
Everyone experiences problems at one time or another. Occasional problems are part of the natural order of things; but a world of difference exists between infrequent issues and a steady stream of issues. A barrage of problems usually indicates something fundamentally wrong in the processes that either develop or manage the databases. If the user community has the DBA's phone number on speed dial, chances are high that there are regular problems involving the databases. These problems might concern a lack of comprehensiveness regarding data structure maintenance. Other problems could involve true database maintenance such as updating indexing, or statistics. There could be more subtle worries over batch processes loading or updating against a database. Even the data structures themselves might be inadequately designed. Shortcomings in the design might cause the DBA to harbor poor thoughts towards the data modeler, and force the DBA to lobby the designer to implement possible changes. Alternatively, if the user community has the data modeler's phone number memorized, the reasons causing that situation are unlikely to be good. Conditions that lead to this cozy user-to-modeler interaction are delicate and worrisome and include such circumstances as important items often missing from a database, or data structures designed so poorly that any querying by the average user is non-intuitive.
Anonymity of the data and database administrative staff is the logical equivalent to awarding them a medal of honor. DA and DBA obscurity should mean that users have no complaints. Such quiet instances are the fertile ground from which clichés like "No news is good news" likely arose. When an organization finds itself experiencing such quiet conditions, it is an indicator that database designs are fit for use, database updating is being scheduled and properly arranged, and database maintenance is keeping things near optimal. Suitably performing all these data and database related tasks is not always simple, and sometimes can be very hard. Data is ubiquitous within today's organizations. Everyone needs and uses data, making everyone a data consumer. The invisibility of the database staff in a virtual sea of data and databases is a testament to that staff's high value within the organization.