When gathering data requirements, focus on core business processes

not reporting requirements or source systems

#AgileDataWoW

When we collaborate with stakeholders on the data and information they need, they will often give us requirements in terms of the data extracts, dashboards or reports they want us to deliver.

They will focus on the last mile format they want the data to be delivered in, and they think of this as the best way to provide the requirements we need to gather from them.

This last mile format is what they see when we deliver an Information Product to them, and so that is how they have been educated to think.

The problem is we know that in the Data Domain we can Define the data Once, and Reuse it Often (DORO). We want to create data that is reusable so we can get repeatable value out of those Data Assets. Ideally we want to reuse those Data Assets to deliver multiple Information Products.

Alternatively as data experts we often want to focus on gathering the requirements based on the System of Capture that we need to collect the data from.

We know that every new source system we need to collect data from involves new effort and potentially new complexity in the way we collect that data. We know every new source system will give us a series of "surprises" around the quality of the data. We know we will probably need to map and transform the data we collect to make it fit for purpose.

We often try to cover this complexity when working with our stakeholders to understand their data and information requirements.

The data in our source systems has not been designed to support the stakeholders reporting requirements, they cannot answer the stakeholders business questions. If they could, we wouldn’t need to be involved.

Capturing requirements that are heavily coupled to these source systems is not where we should focus our data requirements gathering process.

Instead we should capture data requirements based on Core Business Processes.

We should capture them based on a pattern of “Who Does What”.

If you want to learn more about the 7W’s and the Who Does What process, I highly recommend the BEAM* approach pioneered by Lawrence Corr and his course. You can find details of his book here:

https://wow.agiledata.io/project/beam-book/

Or details of his Agile Dimensional Modeling course here:

https://wow.agiledata.io/courses/agile-dimensional-modeling/

We should treat Core Business Processes as a Semantic language that enables us to map the Source Systems to the Reporting Requirements.

Core Business Processes allow us to decouple data requirements from both the Source Systems and the final Delivery Type.

It allows us to change our Source System but retain the majority of our Data Design.

It allows us to reuse our Data Design to deliver data and information via multiple Delivery Types.

It provides the ability to absorb change, quickly, it provides increased data agility.

So next time you go to capture some data requirements, think about capturing them based on Core Business Processes over Source System or Reports.