![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Read this article in our interactive digital edition format!
Subscribe to IBM Data Management magazine
There was a time, not so many years ago, when the worlds of the DB2 DBA and the developer of DB2-accessing applications were fairly distinct. DBAs, true to their acronym, really were database administrators. They created objects (tables, indexes, views, table spaces, and so forth), backed up and (when necessary) recovered data, monitored the organization of tables and indexes (and reorganized these as needed), managed the use of disk resources, and generally looked after the database in a “system” kind of way.
Developers, meanwhile, translated business functionality requirements into application logic, designed user interfaces, and determined—among other things—what data elements had to be stored in DB2 tables to support application functionality. Developers and DBAs came together to create logical database designs and periodically to isolate and resolve data-access-related application performance problems; otherwise, these role-differentiated IT professionals generally tended to their respective responsibilities without a whole lot of intergroup interaction.
For quite a while, this mode of operation made sense and worked well. DB2 databases (as was true of databases implemented via competing database management systems [DBMSs]) needed a good bit of attention, and this required DBAs to exercise some pretty highly specialized skills that had little to do with programming (aside from coding SQL queries to get information from the DB2 catalog). Developers did their thing with C or COBOL or Java or whatever, and they knew enough about SQL to get the job done.
Then, some things started happening that ended up increasing—often substantially—the overlap between the DBA and developer worlds. One of these change factors was the drive by IBM to build so-called autonomic capabilities into DB2. That term refers to functionality that enables DB2 to manage itself to a greater and greater extent. Autonomic features introduced on the mainframe platform included DB2-managed data sets, type 2 indexes (do any of you old-timers remember grappling with index page locking?), utility TEMPLATEs and LISTDEFs, and sliding-scale secondary space allocation. For DB2 for Linux®, UNIX®, and Windows® (LUW) DBAs, the goodies included automated RUNSTATS, automatic-growth databases, and self-tuning memory management. All of these combined to free up DBAs’ time to do things other than administer databases.
There were DB2 people (I’ll admit: I was one) who actually fretted about the elimination of formerly time-consuming database management activities, worrying that their employers would have less need for them. Other more forward-thinking DBAs moved their focus to where the value was. That is to say, they looked to see how they could use their newly available bandwidth to their organizations’ maximum benefit, and when they did this, these DBAs often reached similar conclusions: accelerating application development is where it’s at. After all, hardware and middleware (like DB2) don’t, by themselves, make any money for a business. Applications move products, take care of customers, manage inventory, and uncover new opportunities. Get those apps into production faster, and you are impacting the bottom line in a positive way.
Not just the time to help—the tools, too
Another factor in the increased engagement of DB2 DBAs in application development was the ongoing delivery by IBM of DB2 features that reduced the coding burden on application developers. Just a few examples:
- Triggers: A flexible and powerful mechanism for pushing logic into the database level of an application, in the form of user-defined actions that DB2 will take automatically when a program changes data in a table
- Stored procedures and user-defined functions: Convenient, scalable, and secure means of packaging data-access functionality in a very open, reusable form
- pureXML: A breakthrough technology that allows DB2 to recognize the hierarchical structure of XML documents stored in a database and to efficiently navigate that structure for data retrieval and update purposes
- Temporal data support (delivered initially with DB2 10 for z/OS): Another technological leap forward that greatly facilitates data-row versioning (“system time”) and future point-in-time database updates (“business time”)
So, just when DB2 DBAs (thanks to autonomic features) have more time to work with application developers, they are able to bring more value to the table by helping developers to understand and effectively leverage DB2’s programming productivity-boosting capabilities. Not only that, but DBAs are actually getting more into application coding themselves, thanks to DB2’s SQL Procedural Language (SQL PL), which can be used to implement sophisticated logic for stored procedures, user-defined functions (scalar and table), and triggers.
I mentioned previously the forward-thinking DBAs who positioned themselves to deliver more value to their employers by teaming with developers to speed up the creation and deployment of business-impacting applications. Some management types recognized this shift and moved to support it in an organizational sense. One such supporting action was the introduction of new job roles for application-oriented DB2 DBAs.
At one company for which I did some work a few years ago during my independent consulting days, the new job got the title “procedural DBA.” For that organization, the role was largely focused on the development and implementation of DB2 stored procedures. Other organizations go with a term such as “development DBA.” Whatever the appellation, these roles often draw major interest from established DBAs, who see an opportunity to take their careers forward in new and interesting ways.
For their part, development teams are typically more than just a little pleased to have their efforts augmented by those of a DBA who’s well versed in the application-enabling features of DB2. I’ve already mentioned the potential for development speed-up that can be realized via the coding by DBAs of data-access functionality in SQL PL, but helping to meet or beat delivery dates is just part of the story. There’s more.
Ensuring scalability. The developer-DBA can help to architect an application
for maximum scalability on the database side by exploiting such things as static
SQL, multi-row (also known as block) FETCH and INSERT, and DB2’s built-in WebSphere® MQ interface
(sometimes asynchronous processing is a key part of success in meeting the demands
of a high-volume workload).
Satisfying security requirements without hamstringing programmers. DB2 features such as roles and trusted contexts can give developers the data access they need to do their jobs (and end users the privileges they need to use new applications) with the precision, control, and traceability demanded by security managers and auditors.
The reusability ripple effect. When data-access logic is pushed into the DBMS itself, the application development benefits can be wide ranging. For example, a DB2 for z/OS SQL stored procedure developed to support a Java application could just as easily be called from a CICS transaction program written in COBOL. A trigger defined on a table in a DB2 for LUW-managed database could enforce complex data-domain rules for inserts from programs written in all kinds of languages, from C# to Ruby. SQL user-defined functions can simplify query coding for batch as well as online transactional programs. Get those data-access building blocks built, and let developers concentrate on coding business and user-interface logic.
So, developer-DBAs can do a lot to enhance the effectiveness of application development teams. What’s not always clear is where application-enabling DBAs should be placed with respect to the programmers. Should they be “embedded” with development groups, so that their desks are in close physical proximity to those of programmers? That might seem like an obviously good choice, but if it results in developer-DBAs being spread out among physically dispersed application development teams, DBAs may not get together themselves. Esprit de corps and cross-pollination (idea sharing) could suffer. On the other hand, keeping the DBAs physically together might lessen their positive impact on application development if face-to-face time with programmers is thereby reduced. In truth, both of these DBA-placement approaches—embedded and centralized—have been used successfully by different organizations. Go with what works in your environment.
The trends I described in this article—new autonomic and new application-oriented features arriving with each new release of DB2 (on all platforms)—are virtually certain to continue. It’s what IT leaders at DB2-using organizations want: “Let DB2 manage itself, and let my DB2 experts apply their talents to the development of applications that save my company money, grow revenue, and enable us to achieve separation from our competitors.” So, if you’re thinking that developer-DBA is a horse you can ride for a long time, I’d say you’re right. Saddle up.
- Learn more about DB2 for z/OS at the
DB2 for z/OS page on developerWorks.
- Learn more about the autonomic features of DB2 in the
DB2 for z/OS Information Center.
- Get a wealth of information about DB2 for z/OS at the
DB2 for z/OS best practices page.
- Read more articles in
IBM Data Management magazine.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
