The DataBug process
Understand how DataBug does its thing, and how you fit into that process as a techie.
Last updated
Was this helpful?
Understand how DataBug does its thing, and how you fit into that process as a techie.
Last updated
Was this helpful?
DataBug's purpose is to find data problems. These might include situations where good data is telling you about bad things or where the data is simply bad. When it spots data problems, it will raise cases for end users to resolve. For that to work, several things are needed:
A Connection. This tells DataBug how to connect to a data source. This might be a connection string, for example. You define a connection once, then re-use that connection across different problems.
A Problem Definition. This recipe tells DataBug which queries to run and how to create cases if problems are found. It's part queries, part Markdown templating.
An Agent who receives your Problem Definition on a schedule and carries out the instructions you've provided. This could be one of our hosted agents or an agent you host yourself using our Docker image. An agent hosted by yourself is often better suited to querying on-premise data.
Once the Agent has created cases for end-users to manage, team members will interact with those cases to resolve the issues identified. Crucially, a case can only be closed when the problem is no longer visible in the data (with a limited number of exceptions).
To configure the above, it might be that a variety of technical roles are needed:
an IT administrator to initially set up connections or deploy an on-premise agent;
a DBA or developer to create and maintain Problem Definitions.
Once the initial connection (and, optionally, agent) setup is complete, IT admins no longer need to be involved. The ongoing maintenance of problem definitions can be left to developers or DBAs.
Where the problem you're spotting isn't technical in nature - e.g., the data tells you that an operational business process isn't going well - it's often the people responsible for those operations that best explain the context, impact and resolution steps.
In these situations, for end-users to get the most value from the cases that are created using your Problem Definition, we strongly advise having end-users write the initial draft of the case content (e.g. in Word, a text document, etc.). As a techie, you can then translate that into Markdown.