Skip to main content

Metrics for Scorecard & Milestone automation

Syniti Knowledge PlatformMigrate

Automated Metric Refresh & Persistence Logic

Current Limitation: Currently, the Metric Scorecard and PMO Dashboard rely on manual developer intervention to trigger refreshes. This manual dependency introduces a significant risk of "stale data" and human error, which undermines the reliability of the PMO Dashboard.

Business Justification: In a Data Governance environment, real-time accuracy and data integrity are non-negotiable. Relying on manual updates is not a scalable solution and contradicts the principles of automated governance.

Proposed Feature/Solution:

  1. Automated Refresh Scheduler: Implement a backend feature to auto-populate and refresh metrics at defined intervals (e.g., hourly or daily).

  2. Event-Driven Triggers: Enable the system to automatically recalculate the Scorecard upon the completion of specific data jobs or migration cycles.

Impact: Making this feature available will ensure high-fidelity tracking of projects, reduce manual overhead, and provide leadership with a "single source of truth" that is always current.

Posted by Sunil Bhardwaj ·
Status: Planned2 comments

Log in to comment and vote

Comments2

  • John Munkberg

    Team•

    Feb 22

    Sunil - one of the key issues with the PMO Dashboard is that it reads directly from the Reporting and Migration tables in the working database.

    Because Migration is a very Iterative approach - the “state” of the Target Tables are only valid at the specific point where the developer as completed processing their targets successfully.

    A third party person cannot just “Collect” metrics at some random time because I might be in the middle of processing my Target tables - and my data is in a state of chaos (normal development…).

    Another example is the LOAD metrics. Those particular metrics can only be captured at the point where you have processed your target, completed Preload Validation, Loaded the Data, Read the data back, run the Postload Update logic (to set the zLoaded and zLoadDate fields on the target tables) - and then you can collect those metrics.

    At any other time those metrics are totally invalid.

    It’s because of these that we made it the responsiblity of each developer to collect the metrices related to a specific “Milestone” event. As each developer completes their LOAD they must update their LOAD METRICS, etc.

    In your case, I believe you are Auto-Processing (probably) the ETL jobs in more of a Data Quality capacity. For sure this makes for a nice, repeatable process.

    I think in this case it would nice to trigger the Metrics Collection as perhaps the last step of the ETL job itself. RUN the Target Transform - Update the Metrics. Ideally we might need a slightly different dashboard because in this case LOADING is not really the issue.

    We are releasing Charting into the new Cloud Construct, and working hard to expose some of this internal data (think MIG views) such that you can build focused, custom dashboards to track whatever is needed.

    I think this is a good use case for this set of features as it becomes available over the next few months.

    1 - Run Metrics Collection as part of an ETL task.
    2 - Create Custom Dashboards via construct preview (to start with).

    3 - Expose the Metrics Data via OData endpoints (so they can replicated, or just exposed in those charts.)

    Thank you so much for your input.

  • Kevin McDonald

    Team•

    Feb 10

    Hi Sunil -

    Thank you for your feedback — we’ve received it and are actively reviewing it.

    Should we need any additional details or clarification, we’ll reach out. We appreciate you taking the time to share your experience and help us improve the product.