Being a DBA for the People – 3 Ways to Start
Working with all of the different people that "touch" data you’re trying to manage can be challenging. The fact is that it’s extremely important to be involved in pretty much all phases of projects that work with information you’ll be helping with from a database standpoint. In today’s world of analysis, big data and business intelligence, that means that it’ll probably be more rare that you *don’t* want to help out.
Here are three different ways you can add value to the process along the way:
1. Data elements needed
It seems as projects start that one of the things often overlooked is the need to define exactly what the outputs are for the project. This is key to defining the inputs, but often times people are so focused on the application, data collected and so-on that they overlook the fact that the inputs have to provide the information to support what you need out of the system. Let’s face it, if the system doesn’t have a valuable or helpful output, there is really no reason to do it in the first place.
These meetings are pretty easy to help out with – "What do you need to get from the process when it’s all said and done?" is a great question to ask. Make sure the team is thinking through what will need to be captured, how it has to be managed and how it will be used. From there, you can work on helping them understand storage needs and processes and make sure your systems will support what will be stored and accessed.
2. Inter-application dependencies
Something that is often missed in the process of setting up a new (or update to an existing…) project are the dependencies on other applications. This can be as simple as using a common end-user system to access the software or as intricate as data shared between and modified by multiple applications.
Talk about other systems and applications that support the work for the project. Find out if any information is flowing from other sources, see how that process works. You’ll probably have some to-do elements out of this process, from security issues (what logins and application security can access which data elements) to working to support good performance between the applications. You’ll want to know these dependencies as you set up your disaster recovery processes too.
You may have additional steps you need to add to the DR process, and surely will have new things to check to confirm a DR process was successful.
3. Information and data protection
Lastly, you’ll want to understand the data stored and how it’ll have to be protected. What are the regulations? What are the best practices? The project team may, or may not, know these answers, but you can work with them to help explain and understand options, and you can find the solutions that will play well with other systems you may have in place (see #2 above).
This also needs to address access. What developers will be accessing the systems? What types of access will they need? If the application does interface with other solutions you have, will test data be needed to confirm the integration work? How will it be tested? What types of access security are anticipated for the application itself? These will define how you’ll be setting things up and supporting access to the databases.
One last note
Always go into meetings and conversations as a true team player. The saying "seek first to understand, then to be understood" is very important. Make sure your team is able to describe and define how they need to work with data – then you can help explain what will be needed and help in the decision and design process. In the longer-term you’ll be much better equiped to know what’s up with the application, which means you’ll be able to support the application objectives very readily. It can make all the difference in the world.