As DB2 Evolves, so, too, do DBA Roles
I recently gave a presentation on DB2 stored procedure trends and technology to a room full of application developers and DB2 DBAs, part of a "lunch and learn" program organized by a large company in the retail industry. Seated next to me at my table was a DB2 DBA manager, and as I sat down after delivering my presentation I mentioned to him that recent DB2 changes emphasizing application enablement (e.g., native SQL procedures in DB2 9 for z/OS, global variables in DB2 9.5 for Linux/UNIX/Windows, the IBM Data Studio development tool) and reducing the need for "hands on" system administration (examples include automated memory and disk storage management enhancements in DB2 9.5 for LUW, and partition-by-growth tablespaces in DB2 9 for z/OS) offered an opportunity for companies to re-think the ways in which DB2 DBAs can be engaged to deliver value to the organization. I went on to say that I was particularly interested in the rise of what might be called the application-focused DB2 DBA.
The DB2 DBA manager smiled and told me that his group had indeed recognized and acted on that opportunity by creating a new role, called "Procedural DBA". The title emphasizes stored procedure technology, which - with DB2 for z/OS V9's great-leap-forward support for native SQL procedures, about which I recently blogged - provided the DB2 DBA team with something to "sell" that the retailer's application development teams were very ready to buy. These application developers are - as they should be - focused on delivering functionality needed by the business. They use modern programming languages and techniques, they need access to DB2 databases on both mainframe and distributed systems platforms, and they need to move fast - which means, among other things, that they don't want to have to have the detailed DB2 database schema knowledge needed to embed SQL DML statements (SELECT, INSERT, UPDATE, DELETE) in their business-tier programs. For the development teams, being able to get the back-end DB2 database work done via stored procedures, and being able to call those procedures in a "native" way with respect to the programming language being used (e.g., via IBM's JDBC or ADO.NET drivers), is a very attractive proposition.
That's the demand side of the DB2 stored procedure equation at the big retailer. On the supply side, the DBA manager sees that all the pieces are now in place. With the native SQL procedure support delivered in DB2 for z/OS V9, preparation and deployment of stored procedures written in SQL no longer depends on having a C compiler (the C compiler requirement was similarly removed via DB2 V9 for the Linux, UNIX, and Windows platforms). Not only that, but the SQL programming extensions made available for native SQL procedures on the mainframe platform (such as nested compound statements) make it easier than ever to develop SQL procedures that can be deployed on different DB2 server platforms. Throw in a couple of cherries on top like the zIIP-eligibility of native SQL procedures called via DRDA (for more cost-efficient mainframe computing) and the great SQL procedure development interface of the aforementioned IBM Data Studio tool, and you've got a package that looks great to everyone from developers to systems programmers.
I told the DBA manager that this all sounded pretty cool, and that I'd expect some "traditional" DB2 DBAs to be eager to take the Procedural DBA role for a spin. Again a smile from the manager, and a gesture to person across the table: "Here's one of our first. You can ask her about it." The newly-minted Procedural DBA did indeed show a lot of enthusiasm in talking about her role. She liked all kinds of things about it, and found especially appealing the fact that it involved working with DB2 on both the mainframe and LUW platforms (DB2 for z/OS and DB2 for LUW have some systems programming and database administration differences, but from an application perspective they are virtually identical). She also welcomed the opportunity to move in a new technical direction and to pick up and hone some new skills. She and her Procedural DBA colleagues are poised to accelerate application implementation (a longtime president of Southwest airlines once said that a plane makes zero money when it's on the ground, and an application doesn't make or save money until its in production), because they'll be involved in the development process from concept through data modeling and data architecture all the way to deployment - no heaving stuff over the transom with a "You guys take it from here" (or, on the other side, picking up the pieces of stuff so heaved). The new Procedural DBA knows that she's caught a good wave, and she's looking forward to riding it for a long time.
New technology can benefit an organization. When the organization itself changes (for example, by defining new roles) to take advantage of new technology, that potential benefit can be substantially magnified. I spent time the other day with people from a large retail-industry company who really get this. That makes for a good day indeed.
The DB2 DBA manager smiled and told me that his group had indeed recognized and acted on that opportunity by creating a new role, called "Procedural DBA". The title emphasizes stored procedure technology, which - with DB2 for z/OS V9's great-leap-forward support for native SQL procedures, about which I recently blogged - provided the DB2 DBA team with something to "sell" that the retailer's application development teams were very ready to buy. These application developers are - as they should be - focused on delivering functionality needed by the business. They use modern programming languages and techniques, they need access to DB2 databases on both mainframe and distributed systems platforms, and they need to move fast - which means, among other things, that they don't want to have to have the detailed DB2 database schema knowledge needed to embed SQL DML statements (SELECT, INSERT, UPDATE, DELETE) in their business-tier programs. For the development teams, being able to get the back-end DB2 database work done via stored procedures, and being able to call those procedures in a "native" way with respect to the programming language being used (e.g., via IBM's JDBC or ADO.NET drivers), is a very attractive proposition.
That's the demand side of the DB2 stored procedure equation at the big retailer. On the supply side, the DBA manager sees that all the pieces are now in place. With the native SQL procedure support delivered in DB2 for z/OS V9, preparation and deployment of stored procedures written in SQL no longer depends on having a C compiler (the C compiler requirement was similarly removed via DB2 V9 for the Linux, UNIX, and Windows platforms). Not only that, but the SQL programming extensions made available for native SQL procedures on the mainframe platform (such as nested compound statements) make it easier than ever to develop SQL procedures that can be deployed on different DB2 server platforms. Throw in a couple of cherries on top like the zIIP-eligibility of native SQL procedures called via DRDA (for more cost-efficient mainframe computing) and the great SQL procedure development interface of the aforementioned IBM Data Studio tool, and you've got a package that looks great to everyone from developers to systems programmers.
I told the DBA manager that this all sounded pretty cool, and that I'd expect some "traditional" DB2 DBAs to be eager to take the Procedural DBA role for a spin. Again a smile from the manager, and a gesture to person across the table: "Here's one of our first. You can ask her about it." The newly-minted Procedural DBA did indeed show a lot of enthusiasm in talking about her role. She liked all kinds of things about it, and found especially appealing the fact that it involved working with DB2 on both the mainframe and LUW platforms (DB2 for z/OS and DB2 for LUW have some systems programming and database administration differences, but from an application perspective they are virtually identical). She also welcomed the opportunity to move in a new technical direction and to pick up and hone some new skills. She and her Procedural DBA colleagues are poised to accelerate application implementation (a longtime president of Southwest airlines once said that a plane makes zero money when it's on the ground, and an application doesn't make or save money until its in production), because they'll be involved in the development process from concept through data modeling and data architecture all the way to deployment - no heaving stuff over the transom with a "You guys take it from here" (or, on the other side, picking up the pieces of stuff so heaved). The new Procedural DBA knows that she's caught a good wave, and she's looking forward to riding it for a long time.
New technology can benefit an organization. When the organization itself changes (for example, by defining new roles) to take advantage of new technology, that potential benefit can be substantially magnified. I spent time the other day with people from a large retail-industry company who really get this. That makes for a good day indeed.
posted by Robert Catterall at
5:55 AM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home