Attendees#
| Roles | Personnel |
|---|---|
| Data Owner | --- |
| Product Owner | -- |
| Data Modeller | -- |
| Data Engineer | -- |
| Data/Solution Architect | -- |
Inputs#
- Business Objectives and Key results
- Strategic Business Goals
Outputs#
-
High level cost and capacity estimate including need for MVP/prototyping.
-
Approved Choice of tools and technology
-
Risk considerations
-
Data Governance foundation and key roles established
-
The Business Level Requirements document completetely filled that serves as a foundation for building the Requirements Specification
Key Points to consider#
-
Did you find a similar product in NNDM, if yes why can't it be re-used?
-
The problem statement that you have, are their similar problems in your area. If yes, are they being solved separately and why can't they be combined into one solution. What are the challenges?
-
Is the list of sources which provide the required data exhaustive or are there any other sources providing similar data or can arrive in the future?
-
Any preference of technology or are you using any tools in the current ecosystem which can be re-used or you have a preference?
-
Is there a logical or a conceptual data model that exists for the required data domain?
-
Consider protyping or MVP/pilot to understand the complexities in the use case better
-
Attempt shaping the backlog at a high level as per business needs. Its not expected to break the EPIC into features at this point but a project outline of what features could look like and what is doable in what time duration would help in better planning.
-
Is the use case a data product be definition or a simple data pipeline?
-
What could be potential cost markers and resourcing estimates?
-
How can we establish robust data governance for our data products by ensuring clear data ownership and stewardship, conducting thorough risk assessments, and capturing essential metadata attributes to make FAIR data products? To know more about Data Governance, click here
How to conduct this workshop#
-
Use this miro template to agree on high level requirements with inputs from all stakeholders: Data Product Canvas
-
Consider a 2-week duration:
-
First primary workshop to discuss on Business Requirements Document. Outcome will be the high level functional and non functional requirements.
-
The GDAI technical team would evaluate the use case for 2 weeks() and conduct the Architecture Feasibility Outcome and assumptions. The technical team can refer to this guide How to do Feasibility Assessment - Data Products
-
GDAI delivery team is expected to get the above architecture feasibility outcome reviewed by the GDAI architecture to ensure right architecture, technology and mitigate or flag the gaps and decide if a POC is needed.
-
-
The follow-up after 2 weeks would contain finalized Architecture Feasibility Outcome with high level costs and solution hypothesis including existing gaps and risks which will be presented to Product Owner and Solution Delivery Manager. .