I was one of those kids. Grade school teachers more than once had a talk with my mother about Tom asking too many questions. Things remain unchanged today. When I need to know something, I ask questions. Asking questions is a big part of a data architect’s job of uncovering data requirements.
Questions serve many purposes. Data architects with countless projects and years of modeling under their belts are well versed in the questions that uncover data requirements and turn them into data designs. There are other questions that must be asked before the data architect begins their work. Here are five important questions that need to be asked sooner than later.
- What is the purpose of your project?
The answers the data architect should look for are beyond project name, web pages, reports and outputs. “How does this project add to the bottom line and improve the productivity of our employees?” It is a grave mistake to concentrate on the smaller picture of the purpose of the project without understanding the larger picture it ultimately contributes to the enterprise. Remember that data architects need to always look for the bigger picture.
- What story do you want your data to tell?
Most people can visualize rows and columns in MS Excel or MS Access as data. The data architect’s exercise in this line of questioning is to get people to understand that data is more than just rows and columns. Data requirements do tell a story. It’s the story of how data relates to other pieces of data and how that story turns data into information. Above all, help the project team visualize their data beyond the project boundaries and as part of the enterprise’s story of data.
- What do you need from me?
This simple question is often overlooked. Like other professions, data architects have a pattern of repeatable work processes and artifacts for data modeling initiatives. It is important to have a dialog with data customers about their expectations. Data architects need this alignment and understanding to work on the proper tasks to deliver the artifacts that satisfy the project’s data requirements. Methods can be standardized and repeatable while targeting deliverables and not wasting valuable data architect and project resources.
- How do you define success?
This open-ended question yields a good bit of vision into what makes the data customer tick. Is it speed? Is it higher quality? Is it improved efficiencies? Data architects should build on these hot button items in the course of their modeling. Data architects often live on the edge of the project. It is important that the architect have a clear idea of project dynamics, team expectations, and development culture. Data architects are pulled into the center of the team when they link their success to the data customer’s view of success.
- When do you need it?
Not meeting team expectations is deadly for the data architect. That is why this question needs to be asked ASAP. It is important that the data architect explore their involvement deeper than their bars on the Gantt chart. It is highly likely that the data model(s) are have multiple resources and tasks dependent on their delivery. Data architects are typically a shared resource that can limit their involvement in the team. Make sure that the team understands your workload beyond their project. At the same time, commit yourself to be actively involved with the team and deliver the data model(s) ahead of schedule.