Database Administrators or Data Architects

The role of the database administrator (DBA), or data architect, cannot be over-emphasized in an IT project. The purpose of IT is the capture, storage, and retrieval of business information to further the organization’s core business objectives. In today’s environment all the information that used to be captured on paper records is now captured in electronic records that must be stored for retrieval in an electronic repository. This requires the use of relational databases for all but the smallest, simplest applications and the use of relational databases requires the skills of a database administrator and/or data architect.

There is little difference between the skill sets possessed by data architects and those possessed by database administrators. The difference tends to be in the focus of the two roles. Database administrators are responsible for the health of the database and the data it manages. This responsibility will include the architecture of new data and database dictionary as the business grows and changes. Database changes may occur as a result of a project which delivers new functionality, or in response to changes in the existing data. The focus of the database administrator is overall health of the database and the data it contains, including database availability, performance, and access. The data architect is a role that tends to come with the implementation of the initial database instance and large expansion projects. It is the database architects job to ensure that the database design and data dictionary are optimized to support the data storage retrieval and performance goals of the project.

The key difference between the two skill sets is the emphasis on operational activities and the health of the database on the one hand and the emphasis on the performance of the database on the other. The database administrator will inherit the work of the data architect if one is employed to design a database, or a database extension, as part of a project. They will be responsible for support of the database they designed if one is not. Other than this difference the skill sets are very similar, indeed most database courses make no distinction between the two roles. This article will treat the two roles interchangeably; the best practices described here are applicable to both roles. The only time a different approach is required is when you have both roles on the project in which case you will be required to distinguish between the two roles and assign each role the work they are best suited for.

Large database supported projects require the data architect skill set and the project manager should ensure that the person assigned to this role on the project possesses the architect skill set and experience. This is a role which is critical to the success of your project so if there is someone you in your organization who meets your requirements secure them for your project by identifying them as a critical resource in your project charter. Smaller projects may be served by the architectural skill set possessed by the DBA. You should go over the DBA’s background and check for training and experience in database design and performance. Previous experience on a database creation project would be ideal.

You will have to recruit the database architecture skill set externally if it isn’t available within your organization, or if the experience isn’t deep enough. Look for a data architect with experience in large database projects with a deep knowledge of the relational database your project is using. All relational databases manage data the same way but each has its own unique set of tools and without knowledge in this area the architect will have too much catching up to do to contribute to your project. Your architect should also have experience in database normalization so that your design will follow the best practices for relational databases. Data modeling is also a skill your architect should possess. If your organization does not have anyone with these skills and you are prevented from recruiting externally, or cannot attract this skill set, consider training your DBA. Make sure that you schedule the training early enough in the project so that the DBA is on board for the planning phase.

Your database architect should work closely with the solutions architect so that system design and database design align. The best way to do this is to ensure that each attends the other’s design sessions. Your database architect can only design an efficient database if they know how it will be used by the system and the system’s users. That is where the solutions architect can help. They will also have to work closely to define the data dictionary that the system will use. Data elements should be defined consistently throughout the system and the source for these definitions should be the database data dictionary.

Ideally, you should involve the data architect in design reviews and code reviews to ensure that the applications being designed utilize the database properly. Your architect may not have the bandwidth to attend each of these reviews. In that case, ensure that they at least review designs and approve them.

Development and testing environments require an instance of the database under development. This would normally be the responsibility of the DBA and if your project has the benefit of a data architect and a DBA it will be the DBA who installs the databases. If your project does not have a DBA, you’ll have to rely on your data architect to install the databases, or beg, borrow, or steal a DBA for the purpose. The installation of test databases should always be contingent on the system under development meeting the criteria for promotion to the testing phase.

Testing data is always a contentious issue for every project. Assembling test data is not the responsibility of the DBA but the DBA should be made responsible for refreshing databases with the set of test data they are given. Assign responsibilities for the gathering, "massaging” (making the existing data compatible with the new database), and inserting the test data. The testing team must identify the data they need to perform their testing. This data will very likely be a mix of "system” generated data and user generated data. The system generated data includes such things as the organization’s product inventory, customer list, etc. while the user generated data will include items such as customer orders. Assign a team member responsibility for identifying and capturing system data. Any "massaging” necessary will likely have to be done by the DBA or data architect. Test plans should make use of a common set of user generated data, data that wouldn’t normally be generated as part of a test case, so that the same data is used across multiple test cases. Once this data has been identified and assembled it is turned over to the DBA for maintenance and each time test environments must be refreshed, the databases should be cleansed and repopulated with this data and the system data.

Your data architect should be a SME for purposes of risk identification and change request analysis. The architect should attend team status review meetings and report on their progress with database development. Change requests that could entail changes to the database should be analyzed by the data architect to verify and quantify the impact of the proposed change.

Database architects are critical to the business of developing a system which meets the organization’s performance requirements. Your job is to determine what these requirements are. The data architect’s job is to identify the database structure, data dictionary and any hardware and software requirements the database would need to meet these objectives. Although I’ve left this issue to the end, it is something that should be addressed early in the planning phase. Design of the database is not an exact science but procuring the right hardware and software at the outset should allow you to meet your objectives. Finding out that the database you’ve built does not meet your needs during a testing phase will add time, effort, and cost to your project.