This article is the second and concluding portion of a two-part series on staffing the data administration team. In the first installment we examined the roles of the project champion, data administrator, repository architect, and the data modeler. In this segment we will examine the roles of business analyst, data acquisition developer (back-end), data delivery developer (front-end), middleware developer, and infrastructure developer. Depending on the size of the implementation some of these roles can be filled by the same resource. This usually occurs with the middleware developer, and infrastructure developer roles. Other roles will require multiple resources to fulfill them. This is common is the data acquisition developer, and data delivery developer roles.

Business Analyst

The business analyst’s chief responsibility is to meet with the business and technical users to define the reporting requirements of the meta data repository. In order to accomplish this task this person will need to have experience leading JAD (joint application development) and workgroup sessions. During these sessions it’s very important for the business analyst to properly manage the expectations of the repository’s end-users. More then one project has failed, because of end-user expectations for the system being unrealistically high.

The business analyst must understand how to take the requirements that come from these JAD and workgroup sessions and apply them to design technical solutions. Lastly, this person needs to have excellent communication skills to work with the business/technical end-users and the development team for the meta data repository.

Data Acquisition Developer (back-end)

The data acquisition developer for the back-end of the meta data repository is charged with the task of extracting the meta data from its sources, programmatically integrating it together, and loading into the meta data repository. This role is primarily a programming one. If a meta data integration tool is being used to build the repository this person needs to become intimately familiar with how to use the tool to load the repository’s tables. Typically the tables of the repository are loaded into a relational database (e.g. Oracle, Informix, SQL Server). As a result, the back-end developer must come from a programming and SQL background. It is critical that this person has a strong concern for quality and that they work well with the repository architect.

Data Delivery Developer (front-end)

The data delivery developer for the front-end of the meta data repository is responsible with extracting the meta data from the meta data repository and presenting it to the technical and business users. It is quite common for a meta data access tool to be used to present the meta data to its users. In these situations the data delivery developer must understand how to use the tool, along with having a solid grasp of the tool’s strengths and weaknesses. In “better” meta data implementations the access tool for the data warehouse/data marts will be the same tool used to access the meta data repository. This is important because the reports that have the greatest value incorporate both meta data and data warehouse/data mart data.

The front-end developer must come from a programming and SQL background as typically the meta data will be pulled from a relational database. In addition, this person needs to understand how to create “user-friendly” reports that presents the meta data and data warehouse/data mart data in a clear and logical manner. Lastly, this role must have solid communications skills to work well with the business analyst and repository’s end-users.

Middleware Developer

This commonly overlooked role is typically staffed from a centralized IT (information technology) team. In today’s development environment we are consistently sourcing meta data from different hardware platforms (e.g. mainframe, PC, Unix). Quite often this chore can be much more difficult than initially expected, especially when speed is of the essence, as when the meta data is being sent to feed an end-user report. Often the solution for linking these diverse platforms comes in the form of middleware. This person needs to be able to work well with the infrastructure developer, and the repository architect.

Infrastructure Developer

The infrastructure developer, like the middleware developer is typically staffed from a centralized IT team. It is critical that this person is proactive and works with the middleware developer, and the repository architect at the onset of the repository implementation to make sure the hardware, software, and middleware can support the repository’s architecture. All to often a meta data repository project is negatively impacted because the end-user’s PCs do not support the access tools being used or the platform that the meta data is sourced from.

Now that we’ve presented the eight key roles of the data administration team let’s look at two additional topics. First, out of the eight roles we’ve discussed there are five qualities that are critical to all of them:

• Excellent organizational skills
• Team player
• Strong motivation
• Quick study
• Concern for quality

Personally I’ve always preferred to have a team that has these qualities, as oppose to a team that has the technical “know-how”, but is severely lacking in these areas. It been my experience that “Great talent finds a way!” If the people you have are quick studies, hard working, team players, and have a strong concern for quality they can, and will overcome any technical obstacles that they might have.

Second, it is important for all of the data administrators, managers, and architects to take the time to invest in your people. Spend time teaching them the knowledge that you have. Send them to conferences, and provide them with articles that you’ve found valuable. People are the greatest asset that you have, invest in them wisely, treat them honestly and with respect, and the paybacks will always be great.