If you have been reading this blog, you probably have noticed that very few posts have discussed complex technical topics in-depth. There is a wealth of information available on database administration and tuning topics provided by a host of qualified (and totally unqualified) presenters.
Being a successful DBA requires much more than just technical expertise. Over the years, I’ve found that becoming lax in non-technical areas of database administration and not following my own best practices could create just as much havoc as a technical problem.
I don’t care what database you support. If you want to excel in this profession, you need to be viewed as more than just a DBA “table jockey.” You must be seen as someone who understands both the business and technical aspects of the applications you support. Gone are the days when being technically proficient was enough to get by. That is definitely not the case in today’s business environment.
Let’s begin Part 1 of our 2 part series with a general set of recommendations on keeping your database administration customers happy.
Good Communication is the Key to Successful Customer Relationships
As most readers know, I run a remote database administration services shop in Pittsburgh called Remote DBA Experts (RDX for short). It is a tough business. Our customers have turned over their most valued data assets to our organization. Trust me when I say it is a responsibility that we don’t take lightly. We are held to a very high standard by our customers, and that’s OK with us. We should be.
Achieving “ZERO technical defects” goes without saying. We have virtually dozens of in-house procedures, repeatable processes, checklists and tools to ensure that our work is of the highest quality. Over the last 20 years, we have designed, tuned and tweaked our remote monitoring and support infrastructure until it has become a “remote services engine” that truly provides best-in-class services to our customers.
But we must also make every effort to ensure that effective communications are occurring between our organization and our customers. Not having the luxury of “face time” with our customers on a daily basis drives us to use all communication mechanisms and best practices possible to ensure our customers are comfortable with the services we are providing to them. Remote support doesn’t mean communications are any less important; conversely, maintaining constant, high-quality communications is an absolute requirement for keeping our customers happy.
But the same high-quality communications requirement holds true with your internal customers. You need to create and foster good communications from the very beginning of your relationships with end-users and developers. From internal Service Level Agreements to project statuses and problem notifications, DBA units need to maintain constant, high-quality communications with their customer base.
Here’s a quick laundry list of hints and tips that can jumpstart your strategy to improve communications with your customers:
Document and Distribute Service Level Agreements (SLAs)
Service Level Agreements (SLAs) help to solidify support requirements and dispel any inflated expectations a business or application development unit may have. They probably won’t be aware of your current workload and resulting work request lead times until you tell them. A standard set of work request completion timelines should be established for the organization. The work requests can be categorized any number of ways. Here at Remote DBA Experts, we have standard documentation that breaks the work requests into categories based on complexity and the estimated time to complete them. We then provide numerous examples of activities that fall into each of the categories.
The DBA team lead should also meet with each individual unit supported to establish a set of measurable Service Level Agreements that include support activities required, maintenance windows and application performance and availability objectives. A unique customer profile for each unit supported can be created that describes everything the DBA unit needs to know to provide high-quality support. What makes them tick? What is important to them? What keeps them up at night? Those are the questions you need to ask.
The notification lead-time required for the database administration team to perform a requested change can then be formalized, documented and distributed to business and application development units.
DBA unit customers need to understand the amount of time the DBA unit will take to process a given work request. This will prevent your team from getting a request to migrate a database from test to production in the morning with a required date for that afternoon. Of course, we all know that never happens.
We also understand that the world does not revolve around the DBA Unit. I don’t care which business any of our customers are in. Each market sector is a competitive one. There are times when business objectives require that we “burn the midnight oil” to get our administrative work complete. That is part and parcel of what DBAs do. I was in a conversation with a customer recently. Although I kept telling him he really had no need to apologize for the rash of short-term requests he was asking for, he stated, “Chris, it’s not like I’m sitting on these until 5 minutes before they are needed. We are trying to remain competitive, and the business users think this application will help us survive.”
Document and Distribute DBA Unit Notification Methods
How do you want your customers to contact you for work requests? Is it a traditional ticketing system, e-mail or phone call? Your unit’s ability to react to a work request, problem or outage notification depends upon the mechanism used to notify you.
- Support Line
- Support Tickets
- E-mail Groups and Individual E-mails
Support lines don’t have to be for external customers or off-hours calls only. An internal support “hot line” can be used to notify the DBA unit of problem during the day as well as after hours. The hot line can be used for any issue that affects the availability of the database. This includes outages, global performance issues, data quality issues (data changed/deleted by mistake) and connectivity problems. The support line should also be used for emergency change requests that must be performed immediately.
Support tickets are Remote DBA Experts’ required method (because of our SSAE16 Type II and PCI audits) for work request notifications. If the work request doesn’t come in through our customers’ or our ticketing system, we don’t make the change.
If your unit uses a ticketing system, you need to provide hints and tips for your customers to ensure miscommunications do not occur. Although my shop processes requests around the clock, what are the procedures if one of your customers enters a ticket after your unit’s workday is complete? How about weekend tickets? If you assign tickets entered after 6PM on the morning of the next work day, you need to let your customers know that. The same is true for weekends. How about work request priorities? If you don’t tell your customers what a critical priority means in terms of turn-around time, you have a very good chance of miscommunications occurring. You need to be crystal clear on virtually every piece of information that is associated with that ticket. In this case, too much is probably still not enough.
This is probably the most common and absolutely the least preferred method of communicating with any support unit. It is important to tell your customers that an individual technician may be out of the office for any number of reasons (vacation, illness, business travel, etc.). All support technicians should be required to configure “out-of-office” greetings for their desk phones and e-mail accounts when they are out of the office for any reason.
Internal DBA Unit website
The internal DBA unit website provides your unit name, mission statement, SLAs, databases supported, personnel contact information, calendar listing DBA vacations, on-call, etc. The more creative you are, the more popular your internal website will become.
Application Change Management
Database administrators usually support different business units with each unit having their own set of unique procedural requirements. Formalizing and documenting the change request process minimizes the potential for miscommunication between the business units, application development areas and the database administration unit. This is even more important to remote DBA services providers. Standardized communication practices are a key ingredient of a trouble-free application environment. This ensures that there are no “surprises” when a change is implemented in production.
If your organization doesn’t have a formal change request process in place (and many shops don’t), create your own! There are dozens of change management and source code versioning tools available on the market today. The prices can range from thousands to tens of thousands of dollars.
Although I highly recommend these types of products, I wouldn’t let the lack of having one prevent me from formalizing the change management process. Do the best with what you have. Be creative and focus on procedural enforcement that results in high-quality implementations and not, “Oh woe is me, I have no tools.”
From creating a single index to the implementation of a complex, multi-tier database-driven application architecture, good communication is absolutely critical during the change management process.
I hope you enjoyed the first part of my recommendations on keeping your customers happy. Look for the conclusion in my next post.