Engineering Analytics - delivery and developers

Engineering Analytics turns the data AppArch already collects - merge requests, scans, deployments, issues, incidents - into delivery metrics. One rule runs through every screen: a number that cannot be measured is shown as unmeasured, never as zero, and two series shown side by side are never claimed to be cause and effect.

Project health scorecard (/reports/health)

Every score the platform keeps per project on one card: ArchScan, ArchSecurity, Compliance, Git Health and the SonarQube-derived score (reliability, security and maintainability ratings mapped A=100 … E=20), each as that tool’s latest 0-100 number or a dash when the tool never assessed the project.

• Consensus - the average of the sources that exist, always shown with how many that was (“from 3 sources”). It is not a weighted index and never treats a missing source as zero.
• Assessed by - how many projects each lens has actually looked at, so a high consensus over one source is read as exactly that.
• Tools disagree - projects where ArchScan and the Sonar score are 20 or more points apart, with the direction (“Sonar kinder” / “Sonar stricter”). Not a verdict on either tool; a place to look.
• All lenses green - every assessing source at 80 or more, with at least two sources.
• External findings - open GitLab and SonarQube security findings per project (total, critical, high) listed under the ArchSecurity score as counts; they never enter the consensus. A tile sums the open criticals across the card.
• Trend lines per project over the selected period for ArchScan and Sonar, Sonar quality gate, coverage and duplication, and a project-group filter.

MR Insights (/reports/mr-insights)

Every merge request of every connected project is synchronised (every 30 minutes) with author, state, opened/merged/closed times, who merged it, size (additions, deletions, changed files) and the first review time.

• Weekly throughput - opened, merged and closed per week.
• Risk list - merges scored on size, self-merge, missing approval and missing review comments; the highest scores first.
• Symptoms - large MRs, long review waits, self-merges, unreviewed merges, with the numbers behind each one.
• Activity heatmap - “when does work land”: 7 days x 24 hours in the viewer’s own time zone, opened and merged combined. Merges outside Monday-Friday 08:00-19:59 local are counted separately - not as a verdict, as a question to ask.
• Review coverage - share of merged MRs (with comments synced) that received at least one counted human comment from someone other than the author; the rest merged in silence. Uses the review-comment verdicts, so acknowledgements do not count as review.

Approval columns cover only the MRs ArchPilot has seen.

Review comments (/reports/review-comments)

Every human comment on a synced merge request is stored next to it (GitLab, GitHub, Bitbucket Cloud and Azure DevOps; system events such as “added 2 commits” and ArchPilot’s own comments are never stored). The question the screen answers is who actually reviews, and the count is kept honest by a verdict on every comment:

• Not judged - counts as review work until someone says otherwise.
• Review - substantive: a question, a problem, a suggestion, a decision.
• Excluded - an acknowledgement (“thanks”, “ok, will do”, an emoji). Left out of every count.

A workspace owner or admin sets verdicts by hand. With Module settings > ArchPilot > Classify pending comments with AI turned on, the installation’s AI provider judges the not-yet-judged comments every 10 minutes; an admin’s verdict is never overwritten. The switch only appears when the instance administrator has configured an AI provider and turned on at least one AI feature. The page’s AI card shows what classification has cost so far (calls, comments judged, input and output tokens) and what the last call did; an admin can queue a pass immediately with Classify pending now (up to 40 comments, two provider calls). Classification spends the installation’s AI key and counts against the assistant allowance.

Counted comments feed the Review comments tile and the Who comments distribution on MR Insights, and the Review comments figure on a developer’s profile. Comments the MR’s author writes on their own MR are listed but never counted as review given.

AI Impact (/reports/ai-impact)

What the installation’s AI provider cost this workspace - finding explanations, assistant answers and review-comment classification calls (input/output tokens, regenerations, by person and model; the last two are workspace-level and counted in the all-projects view only) - next to what changed in the same weeks: ArchScan score, ArchPilot finding density, merged features and fixes. The page footnote says it plainly: the series are shown together, causation is not claimed.

DORA (/reports/dora)

All four metrics are shown; the two that need incident data stay empty until an incident source is connected.

Metric	Source	Notes
Deployment frequency	Catalog deployment events (Argo CD, Kubernetes, Flux)	Deploy time is an observation with up to 10 minutes of lag, not a webhook. Kubernetes-only sources report image tags, not commits, and are counted as untraceable.
Lead time	Merge time (from MR facts) to the deployment that carries the commit	Per environment; an unmatched revision is unknown, never zero. Stage breakdown shows waiting for review, in review and waiting to ship; the two unmeasured stages are drawn grey.
Change failure rate	Incidents opened within one hour of a deployment of the same service	Time correlation, not proof of cause - the page says so.
Time to recover	Incident open to incident close	Same source.

Elite/high/medium/low bands are an approximation of the weekly cadence and sit beside the real number, never instead of it. Stage medians are independent; they do not add up to the headline median.

Issue flow (/reports/issue-flow)

With a Jira connection, issues are read back every 30 minutes and the flow is derived from each issue’s changelog: first transition out of new starts the clock, the last transition into done stops it. Throughput, cycle time, work in progress and ageing are reported, with seven alarms (WIP overload, stale in-progress, ageing backlog, unassigned in-progress, reopened, bug-heavy, low flow coverage). Sub-tasks are excluded from throughput so a team that splits every story into six does not look six times faster.

Incident sources

Dynatrace and New Relic incidents are pulled into the workspace and matched to services by name. Unmatched incidents are counted and shown; a connected platform that has stored no incidents at all gets its own warning, because a token scoped to the wrong account validates perfectly and then feeds nothing - which DORA would otherwise read as a 0% failure rate.

Compliance & Git Health history (/reports/score-history)

Both scores over time. A project’s weekly value is its last successful scan that week; the estate line is the mean over the projects scanned that week and says how many. Weeks without a scan are gaps, never carried forward. Per project: latest score, change between the first and last scan inside the period, scan count and a trend line; tiles show the current average, the mean change and how many projects improved or declined.

Security findings trend (/reports/security-trend)

GitLab and SonarQube findings as a lifecycle. The detection date is the provider’s; a finding counts as closed when a sync no longer sees it open (resolved or dismissed). From those two dates the page rebuilds, per week and per source: new findings, closed findings and the open backlog at week end - reconstructed, not sampled, so history exists for weeks before the page was first opened. Tiles: open now (with criticals), new and closed in the period, net change, median days to close. Per-source and per-project tables. AppArch’s own ArchSecurity scans are per-run snapshots and stay out of this lifecycle.

ADR lifecycle (/reports/adrs)

Architecture decisions as a process: counts by status, open proposals with their median age, decisions per month by outcome, average days from creation to decision, accept rate, superseded decisions, tags and per-project distribution. Proposals older than 30 days are listed oldest first - a proposal nobody decides is a decision made by default.

Access vs contribution (/reports/developer-access)

For every synced developer: the projects they are a member of (per the provider), the ones they were active in during the period (a merge request opened or a counted review comment written), and the dormant memberships - access without activity. Also the reverse: contributions on projects the provider does not list them as a member of. Dormancy is claimed only for projects whose merge requests are synced; the page says how many that is. Service accounts are listed but excluded from the tiles.

Developers (/developers)

Every person who touches a connected repository - members and MR authors - is synchronised per project, only for projects where developer sync is switched on (off by default). Each developer gets a profile (/developers/{id}) with the projects they touch, the MRs they authored and an ArchPilot-based review score. Bots are detected from provider signals and marked as service accounts; the mark can be set or cleared by hand, and a manual mark is never overwritten by sync.

What you need

• A Git credential with pull-request access for MR Insights, the heatmap and developers.
• A deployment source (Argo CD, Kubernetes, Flux) for deployment frequency and lead time.
• Jira for issue flow; Dynatrace or New Relic for change failure rate and time to recover.
• AI Impact needs the installation’s AI provider, set up by the operator (AI); there is no per-workspace key.