`What about my DBAs?' Tempted to outsource database administration? Better think twice

September  1996

"What about my DBAs?" is a common question asked by many information technology (IT) executives we talk to today. There tend to be lots of organizational issues to be addressed by executives when their company implements a new Networked Enterprise model. Do we even need IT? Do we need a data center? How do we manage databases politically? This article presents today's trends, and offers recommendations. Corporate culture, we find, plays an important role in defining the organizational structure, and especially IT. (1,500 words)

Mail this article to a friend

Information Technology is supposed to provide services to your organization that help improve productivity at the lowest practical cost. A customer-focused IT group adapts to changing needs, is sensitive to intangible cultural concerns, respects the organization's structure, and supports customers so well that they want to rely on the IT department.

Evidence mounts that the new Network Enterprise model helps IT accomplish these goals in a flexible, cost-effective manner. But IT must play the key role in implementing the new model. Why IT? Because it is very important to leverage the skills and expertise accumulating in a centralized IT. In fact, those skills become even more important in the New Enterprise model. Issues can become more difficult and complex to deal with. You must exploit the disciplines and process skills of the best of IT to be successful. IT knows what it means to support "mission critical." (If you are an old legacy IT person, you know what we mean.)

Several years ago, we saw a brief though highly publicized spate of major corporations outsourcing their entire IT organizations. They hoped IT was no longer required in the network computing age. For some organizations, outsourcing everything (especially legacy systems) is the right answer. But for many it's not.

Whether outsourced or not, it is important to deal with the functions performed by IT and the organizational structure. Again, much of this structure should be based on your company's culture. Yes, you do need:

• A data center

• Networking

• Applications development/support

• and yes, a Database Administrator (DBA)

The importance of the DBA
We've found that one of the most important IT functions in the new Networked Enterprise model is the Database Administrator. When asked what resources are required to get started in implementing client/server into the network, we always recommend two things, a Unix guru and a DBA.

Our own experiences really proved this to be true. Though we did work for a technology company and had Unix expertise available from outside IT, we still had to train our existing staffs (who were mainframe types) in the new technology because we wanted to make sure we carried their "mission critical" experience forward. But, whenever there was an opening, or someone left the organization, we were sure to fill it with Unix talent. The same goes for the DBA's function. While we had very qualified mainframe DBAs who really knew how to tune and make our mainframe hierarchical database perform, we also knew we needed the same function in the Unix client/server model.

Remember, a production system is a production system, is a production system. It doesn't matter what platform or operating environment you are using. There must be the same functions that support reliability, availability, and serviceability (RAS). You need the same kind of fine tuning and performance monitoring on your relational databases as you did on the mainframe databases. Actually, it is more important in the network model. The problems and issues can be more intense, complex, and difficult to analyze and IT must provide equal or better levels of service in the new networked computing model. If not, the customers of IT will blame the new technology and not want any part of the benefits that can be derived.

The DBAs are one of the key functions required to accomplish this. We had to re-train our existing staff and whenever we had DBA openings to fill it would be with expertise in the relational world (Sybase, Oracle, Informix, etc.) You see, in the old legacy world, most of the expertise came from our mainframe systems programmers. That's changed! It now takes a key team of people (you are very lucky if you can find all these skills in one person) to be successful in this complex world! And boy do we mean teamwork!

The role of the DBA
Another major issue we tend to focus on is the role played by the DBA staff. If you poll IT executives, you'll likely get a different opinion from each one. Some say DBAs should play a development role while others insist they should play a data architecture/data modeling role. And, in many cases they tend to forget about the day-to-day operational support function. All are true, but we're talking about a multi-headed animal here. We feel that it is very important to have DBA staff as part of the operational support group to handle the daily tuning and performance issues that always arise with production systems. Having DBAs for this role will help maintain those service level requirements as they should be chartered and measured on the availability and uptime for the new systems. If they are not, then service levels tend to suffer since the staff will not be spending time on performance or monitoring on a daily basis.

However, it is also important to have the DBA staff involved with the data architecture/modeling function. Again, in the new networked enterprise, data architecture and modeling become extremely important because of the requirement for a data repository for enterprise-wide data. With distributed applications and data, there needs to be some central control of data, which is handled by the repository. The DBA will support this effort and play an important role here. And finally, we need to look back at the development function. When developing or implementing new applications, the database design is very critical to success. Who should be responsible? The DBA, of course.

With all these different functional requirements it becomes difficult to decide where, organizationally, they belong. We'll recommend a model.

Where do they belong?
Once we understand the need for the DBA staff, the next step is to determine where they report, organizationally. This could be summarized by answering one simple question. Do you want to have one central pool of DBAs or do you want it decentralized? Our recommendation is a combination of both and must consider the size of the IT organization and company.

In most cases we feel the DBA staff can be placed in two organizations. The first would be in support of the data architecture/modeling roll. It is very critical to separate this from day-to-day activities so we suggest they be staffed within the IT new technology or architecture function. (We previously defined the role of the architect in our New Enterprise IT organization model.) We also recommend the position(s) be staffed with existing IT DBA personnel just as we do any of the architect roles.

Our second recommendation is to pool the remaining DBA staff within the Data Center function of our organizational model. We feel this is the best fit for supporting the new environment and keeping the staffing costs down (remember, centralized control). It also assumes that with this model they will be required to support the development effort (and will effectively through support agreements) and that there is an effective deployment methodology in place. (See chapter 9 of our second book, Managing the New Enterprise, The Proof Not the Hype, for a description of the deployment methodology we developed.)

By staffing the function within the Data Center organization, they will be chartered and measured on performance, a key requirement for supporting RAS and mission critical. The only exception to this model might be due to the size of the corporation and IT. If the IT organization has total staff numbering close to 1,000 (which then assumes the size of the organization) we would then recommend that the development DBA staff be separated from operations and report into the Applications Development organization. This meets the needs of the business systems requirements but pools the talent for operational support. We also recommend that a rotational model be put in place from operations, to development, to architecture and back (this rotational model can also be used for other IT staff, not just the DBAs).

Organizational and cultural issues (oh, those people issues) have been, and continue to be, critical to the success of your New Enterprise IT model. Furthermore, these issues are rising to the top of the IT executive's agenda. IT success or failure can be measured by how well these issures are addressed.

Resources

• Other Unix Enterprise
  /sunworldonline/common/swol-backissues-columns.html#unix

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-09-1996/swol-09-unix.html
Last modified: