Every developer and user will perform some subset of today’s specialized DBA activities

Yuval Lirov and April Langer

Most recent DBPD feature: “Database Support: Can It Be Measured?” July 1995

Database technology is evolving toward reduced support costs and improved performance. Users and application developers will be the ultimate beneficiaries of the new technology, which will achieve levels of standardization and personalization that empower Internet users to create and maintain their own shared database resources for home or office.

According to Moore’s Law, the capacity of a computer chip doubles every 18 months. Assuming this law holds for the next 10 years (as it has for the previous 20), database searches or indexing that take 12 hours today will take less than four minutes in 2007. Cheap holographic memory will hold terabytes of data in less than a cubic centimeter of space. And as Bill Gates predicts, a single wire will deliver mountains of digital data to every home.

Such progress will profoundly change database technology in terms of data content, database administration, and the DBA profession. Data content will evolve from records of text and numbers to temporal sequences of images, voice, and text (movies, that is). Data access methods will also evolve beyond traditional tables of data toward concepts such as the Informix DataBlades, enabling direct manipulation of complex data objects. Finally, many traditional DBA tasks requiring skill and experience today-such as replication and data integrity verification-will be automated.

Database administration is a relatively new concept. In the late ’70s, client/server technology introduced the idea of the systems administrator, which combines the knowledge of systems internals with the access permissions of the systems operator. The DBA concept originated with that of the shared database in the ’80s; it combines knowledge about application requirements with the ability to arrange the data so as to optimize response time.

Because database availability and many performance issues are independent of the logical schema and can be treated in a general way, the complexity of the client/server environment split DBA responsibilities into logical and physical components based on the principle of proximity to application code. While the “logical DBA” continues to model data and understands the application code, the “physical DBA” spends most of the time improving database availability and response time regardless of the logical database schema. (Hence the natural affinity between systems administrators and physical DBAs.)

To satisfy growing demand for shared computing resources, improved applications availability, and support scalability, DBAs will use a two-pronged approach: distribution and centralization. First, distributed data exchange mechanisms will replicate databases in the client cache, eliminating query network traffic and parallelizing queries. Next, centralized navigation tools will direct applications to the primary servers, expediting emergency failovers without application code changes. Integration will be the tactic for implementing this strategy; DBAs will use a combination of technologies from different vendors. To survive in this new environment, vendors will have to demonstrate specialization as well as interoperability in their products.

The DBA profession will become more general to facilitate teamwork with systems administrators and developers. At the same time, it will become more specialized to meet the growing needs of increasingly sophisticated database technology (OLTP, OLAP, data mining, and warehousing). In a way, every developer and user will perform some basic subset of today’s specialized DBA activities. Consider the example of telephony: In the beginning of the century, the demand for phone operators grew at a rate that would have required every American to be working as an operator by 1950. Instead, the invention of automatic switching alleviated the pressure while transferring some of the operator duties to users. A similar process will occur for DBAs.

However, internal systems support continues to suffer from a resource schism: Its benefit is transparent to the users while being a necessary evil. Because such support is not a core business for the enterprise, users always perceive its costs as exorbitant for the value of delivered systems. Continual budget cuts coupled with growth in systems-service demand result in insufficient support-resource allocation, which reduces systems-service quality and client satisfaction.

As this demand for support services grows, the enterprise will lose the ability to keep pace with the need for in-house support services. Rigorous support-quality and productivity metrics will receive widespread acceptance. The support profession will evolve from art into engineering discipline-becoming more competitive, gaining professional prestige, and earning better compensation. (Salaries for support professionals are already growing faster than in any other computing services area.) Furthermore, the increased need for specialized services and for growing quantities of data will result in even more sophisticated and complex databases. In fact, products are already so complicated that vendors need to secure appropriate knowledge base in the market prior to sales.

Some vendors have opted for internal professional service units to meet the systems-integration demand. However, such services suffer from the same schism as the internal support services: Because client support and systems integration are not the core vendor business, resource allocation seems too high for the product developers and yet too low for the service providers. Such services can be effective and efficient only with adequate cross-platform and cross-vendor tools, with integration with other support disciplines such as systems administration, and after spending significant amounts of time at user premises.

In contrast, economies of scale for database integration are possible through a three-pronged strategy: consolidation of user basis, specialization of products to meet special market needs, and integration of products to work with multiple vendors. Spin-off of existing professional services divisions seems to be the most likely option.

In summary, database technology will continue to evolve in the context of sweeping changes in the information industry and support culture. First, the invention of new and improved products will foster specialization and competition. Next, the growing complexity of disparate platforms and vendors will fuel the development of effective and efficient integration methodologies. Finally, efficient systems support will enable specialization and increased competitiveness, reinforcing the synergy among computing industry, support culture, and database technology.