Merge pull request #2553 from em0ney/solutions-engineering_360

Solutions - engineering 360

Author: sivanel97

docs/solutions/engineering-360/_category_.json

@@ -0,0 +1,9 @@
+{
+    "label": "Engineering 360",
+    "collapsible": true,
+    "collapsed": true,
+    "position": 2,
+    "customProps": {
+      "description": "Engineering 360"
+    }
+  }

docs/solutions/engineering-360/improve-lead-time.md

@@ -0,0 +1,72 @@
+---
+title: Improve lead time
+sidebar_position: 5
+---
+
+# Improve lead time
+
+Lead time for changes is a DORA metric that focuses how long it takes for a desired change to go from initial commit to being successfully deployed in production. Reducing lead time enables faster delivery of value to customers and quicker feedback loops for product teams to test their ideas. In theory (all other things being equal), this leads to higher quality software and increased business agility. By optimizing lead time, organizations can respond more rapidly to market demands.
+
+Lead time is made up of coding time, review time and then integration/deployment time. We'll dig into where a developer portal can help you across each of these categories.
+
+![Lead time for change](/img/solutions/engineering-360/lead-time-for-change.png)
+
+## Improve coding time 
+
+While coding time is best optimized through stable and detailed requirements, a good development platform and AI enhanced developement tools, the data in the software catalog has a role to play.
+
+Port can enhance the detail on your tasks, through a task-assistance AI Agent
+
+- [Enrich task with AI](/guides/all/enrich-tasks-with-ai/)
+
+## Improve review time
+
+Review is typically the greatest bottleneck and contributor to long lead times. 
+Changes are still a pain to integrate. We want to protect production from risk, and make sure that the changes meet our standards and will be maintainable for the team in the future.
+
+There are a few ways that Port can help
+
+### Chase PR reviewers
+
+Sometimes, it's just a matter of our developers having a small context window, or being in the wrong chat session without enhanced memory. A simple reminder works for overdue bills, and it works for chasing PR reviews too.
+
+- [Self-service action to nudge PR reviewers](/guides/all/nudge-pr-reviewers/)
+- [Automated Slack alert for overdue PRs](/guides/all/automate-slack-alert-for-overdue-prs/)
+
+### Avoid wasted time around PRs not meeting conventions 
+
+Standards are important. Teams need to agree on the right detail to include on a PR to make it reviewable by others. 
+However, the last thing engineering leaders want to see are lengthy back and forth threads on a PR, detailing missing details that need to be added before someone starts a review.
+For this, it is useful to measure PR standards, to ensure teams are aligned on the "right way" and can self-govern their own PRs, for a faster pickup from reviewers.
+
+- [Working agreements and measuring PR standards](/guides/all/working_agreements_and_measuring_pr_standards/)
+- [Track and enforce GitLab project maturity](/guides/all/track-gitlab-project-maturity-with-scorecards/)
+
+### Enrich pull-requests with catalog context to decrease review time
+
+To a developer looking at tens of Pull Requests that are awaiting their review, all may appear equal.
+However, many factors could influence what order they perform reviews, or how long they spend on each, for example:
+- How long the PR has been open
+- Whether the PR relates to a serious bug or customer escalation
+- Architectural complexity, or other risk factors around the related components that may affect the level of detail on the review
+- Criticality of the system, or whether the change relates to an important user flow.
+
+Adding this context can help developers prioritize their efforts better
+
+- [Setup PR enricher agent](/guides/all/setup-pr-enricher-ai-agent/)
+
+### Optionally auto-approve and merge some changes
+
+It could be that there is simply too much to review. Perhaps with a mature development platform, monitoring and incident management capabilities, your team will gain the comfort to auto approve and merge a subset of changes, creating focus on other changes that should be reviewed.
+
+- [Auto-approve and merge dependabot PRs](/guides/all/auto-approve-and-merge-dependabot-prs/)
+
+## Improve deployment time
+
+Once a pull request is merged, the change is integrated, but not yet in production.
+Often, the software needs to be rebuilt, deployed, promoted (once, twice, sometimes even thrice) and sometimes tested along the way. Many issues along the way can lead to deployments that take tens of minutes or even over an hour to complete. Environment preparation, cretion of requisite cloud infrastructure, flaky end-to-end tests, approvals and other factors can cause delays. 
+
+It's worth tracking deployment times across pipelines and looking for outliers. Remember that slow deployments don't just affect lead time, but MTTR too, where fast deployments contribute to faster resolution to incidents that require code changes.
+
+- [Pull Request and build metrics](/guides/all/pull-github-metrics-and-build-visualizations)
+- [Track GitLab Deployments](/guides/all/visualize-and-manage-gitlab-deployments/)

docs/solutions/engineering-360/measure-dora-metrics.md

@@ -0,0 +1,26 @@
+---
+title: Measure DORA metrics
+sidebar_position: 3
+---
+
+# Measure DORA metrics
+
+## Overview
+
+DORA (DevOps Research and Assessment) metrics are four key measurements that indicate the performance of software development teams: Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, and Change Failure Rate. Organizations value these metrics because they provide clear, data-driven insights into their software delivery performance. By tracking DORA metrics, companies can benchmark their performance against industry standards, identify bottlenecks in their development pipeline, and make targeted improvements to their development processes that directly impact business outcomes.
+
+## Guides
+
+<iframe
+  width="560"
+  height="315"
+  src="https://www.youtube.com/embed/Tnef7-mdKes"
+  title="DORA Metrics"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>
+
+- [Create and track DORA metrics in your portal](/guides/all/create-and-track-dora-metrics-in-your-portal)
+- [Track deployments and incidents from JIRA](/guides/all/setup-dora-metrics-jira)
+- [Track deployments from GitLab merge requests or jobs](/guides/all/set-up-deployments-dora-gitlab)

docs/solutions/engineering-360/more-engineering-metrics.md

@@ -0,0 +1,79 @@
+---
+title: More engineering metrics
+sidebar_position: 4
+---
+
+# More engineering metrics
+
+One of the key advantages of Port's flexible data model is the ability to measure arbitrary engineering metrics that matter to your organization, regardless of your engineering platform's architecture or version. 
+
+Port can normalize and connect data from across your entire engineering ecosystem. This enables tracking of custom metrics that matter specifically to your organization - whether that's measuring cross-team dependencies, tracking technical debt across multiple repositories, or analyzing the impact of architectural decisions on delivery speed. The managed relations between entities allow for multi-dimensional analysis, helping you understand not just what's happening, but where and why. For example, you could analyze deployment frequency not just by team, but by service type, technology stack, or business domain. This deeper insight helps engineering leaders make more informed decisions about where to focus improvement efforts.
+
+![GitHub metrics dashboard](/img/guides/github-metrics-dashboard.png)
+
+## Track developer onboarding, PR and build pipeline metrics from Github
+
+Port integrates seamlessly with GitHub to track key engineering metrics like time-to-tenth-PR for new developers, PR review cycles, and build pipeline performance.
+
+- [Pull Request and build metrics](/guides/all/pull-github-metrics-and-build-visualizations)
+
+## Measure the mean-time-between-failures, to add colour to mean-time-to-recovery
+
+While Mean Time to Recovery (MTTR) measures how quickly teams can resolve incidents, Mean Time Between Failures (MTBF) provides crucial context by showing how frequently those incidents occur in the first place. A service with a low MTTR might seem healthy at first glance, but if it also has a low MTBF, it indicates a system that fails often and requires frequent fixes. While the Change Failure Rate (CFR) accounts for this to some extent, it really looks at how the number of deployments relates to number of failures, often poorly accounting for legacy services with few changes, or services that fail regularly unrelated to changes. By tracking both metrics together, engineering leaders can better distinguish between services that are truly stable versus those that appear resilient only because teams have become efficient at fixing recurring problems.
+
+To reduce it to bullet points:
+- MTTR tells you how fast you recover.
+- CFR tells you how risky your changes are.
+- MTBF tells you how often you fail.
+
+This is a great example of how port makes it trivial to calculate arbitrary engineering metrics over the rich data in the catalog. Balancing metrics like these are key. After all, a service with a very low MTTR could even be the greatest contributor to the number of incidents and aggregate downtime.
+
+- [Track and show MTBF for services](/guides/all/track-and-show-mtbf-for-services/)
+
+## Visualize your Github repository history
+
+![Github insight dashboard](/img/guides/gitHubInsightDashboard2.png)
+
+Looking at your GitHub repository history provides a view of your development activity over time, helping you understand patterns in code contributions, team collaboration, and project momentum. By tracking metrics like commit frequency, issue counts, lead time and contributor distribution, engineering leaders can identify trends that impact productivity and code quality. This data-driven approach enables better resource allocation, helps identify potential bottlenecks, and validates the effectiveness of development practices.
+
+- [Visualize developer activity in Github](/guides/all/visualize-your-github-repository-activity/)
+
+## Visualize JIRA issues
+
+![JIRA Dashboard](https://docs.port.io/img/guides/jiraDashboard1.png)
+
+Visualizing JIRA issues provides insights into your team's workflow patterns, helping to identify bottlenecks, track issue resolution times and understand workload distribution across teams and individuals. By analyzing metrics like time spent in different states, critical issues/bugs and closure rates, engineering leaders can make data-driven decisions to optimize processes and improve team efficiency. This visibility into work patterns helps highlight areas where teams might be getting blocked or overloaded, enabling proactive interventions before they impact delivery timelines.
+
+- [Visualize JIRA issues](/guides/all/manage-and-visualize-jira-issues/)
+
+## Turn engineering metrics into decisions and actions
+
+<iframe
+  width="560"
+  height="315"
+  src="https://www.youtube.com/embed/TWUlajT7IE0"
+  title="Turn Metrics into Actions"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>
+
+Measurement is only the first step. As you identify issues in your survey and metric data, the next step is to create scorecards and initiatives to drive changes.
+
+## Measure ROI on your investments in tooling
+
+<iframe
+  width="560"
+  height="315"
+  src="https://www.youtube.com/embed/jX_-AYTM_oc"
+  title="Measure ROI on Github Copilot"
+  frameborder="0"
+  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
+  allowfullscreen
+></iframe>
+
+Engineering leaders want to quantify the return on investment in AI-assisted development tools. By tracking metrics like acceptance rates, time savings, and code quality improvements, they can start to see not just how many seats have been purchased, but how those seats are being utilized.
+Moreover, correlating this data with other trends around engineering and quality metrics, or even just developer sentiment from surveys, gives engineering leaders a deeper insight into the value derived from the investment.
+By analyzing Copilot's impact across different teams and project types, organizations can make data-driven decisions about expanding or optimizing their AI tooling investments. 
+
+- [Ingest Copilot Usage Metrics to Port](/build-your-software-catalog/sync-data-to-catalog/ai-agents/github-copilot/)

docs/solutions/engineering-360/overview.md

@@ -0,0 +1,55 @@
+---
+title: Overview
+sidebar_position: 1
+---
+
+# Engineering 360
+
+## Why measure engineering effectiveness?
+
+Engineering leadership and platform engineers face a critical question: Where should we focus our DevEx efforts to make the biggest impact? With limited resources and competing priorities, identifying the right areas for improvement can mean the difference between meaningful progress and wasted effort.
+
+## The journey
+
+Engineering360 is about avoiding the trap of perfectionism when it comes to analysis, and instead optimizing towards immediate measurement, insights and improvement regardless of the maturity of your Development Platform. 
+In the paragraphs below, we'll explore a tried and tested formula for initiating a culture of continuous improvement, in multiple cycles of measurement and improvement.
+
+### Surveys
+
+#### When chaos blocks accurate metric measurement, do surveys
+
+In the early stages of DevEx maturity, the development platform itself is often fragmented across multiple tools and systems. While Port is very effective at modeling and bringing order to this chaos, it takes time for customers to collect comprehensive quantitative data that provides a clear picture of developer productivity and satisfaction.
+
+During these formative periods, qualitative data from surveys often serves as the most reliable north star - while less precise than hard metrics, it offers rapid and meaningful insights into developer pain points, workflow bottlenecks, and areas where platform improvements would have the greatest positive impact.
+
+#### Use the survey as a catalyst for change, and to empower your team
+
+Don't just make the developer survey yet another administrative task. With the right approach, you can make your developer survey a seminal moment for your new Platform initiative, and communicate the "why" behind it.
+To maximize the impact of your developer survey, involve senior leadership in its rollout, create open channels for feedback, and ensure high participation through reminders and visible engagement. Share anonymized results and insights with the team to demonstrate that their input is valued and leads to meaningful action.
+
+You'll learn more about surveys in the next part of the solution, [surveys](/solutions/engineering-360/surveys).
+
+### DORA metrics
+
+DORA (DevOps Research and Assessment) metrics are a set of key performance indicators that help engineering organizations measure and improve their software delivery performance. The four core DORA metrics are:
+
+- **Deployment Frequency:** How often your team successfully releases to production.
+- **Lead Time for Changes:** The time it takes for a code commit to reach production.
+- **Change Failure Rate:** The percentage of deployments causing a failure in production.
+- **Mean Time to Recovery (MTTR):** How quickly your team can restore service after a production incident.
+
+By tracking these metrics, engineering teams gain a data-driven understanding of their delivery process, identify bottlenecks, and benchmark their performance against industry standards. DORA metrics are widely recognized as a standard for measuring DevOps and engineering effectiveness, helping organizations focus on both speed and stability.
+
+You'll learn more about [DORA metrics](/solutions/engineering-360/measure-dora-metrics) later in this solution.
+
+### More engineering metrics and improvement inititatives
+
+:::tip Example: Advanced metric tracking
+A team using Port was able to correlate service complexity (measured by number of dependencies) with deployment frequency and incident rates. This revealed that services with more than 5 inter-service dependencies had 3x more incidents, leading to targeted architectural improvements.
+
+Another customer was able to identify Tribes with a materially faster time to 10th PR metrics and chose to follow up with a secondment of engineering managers to those teams to learn.
+:::
+
+Port's flexible data model and managed relations create unique opportunities for measuring sophisticated engineering metrics. Unlike traditional tools that are limited to predefined metrics or siloed data sources, Port can normalize and connect data from across your entire engineering ecosystem. This enables tracking of custom metrics that matter specifically to your organization - whether that's measuring cross-team dependencies, tracking technical debt across multiple repositories, or analyzing the impact of architectural decisions on delivery speed. The managed relations between entities allow for multi-dimensional analysis, helping you understand not just what's happening, but where and why. For example, you could analyze deployment frequency not just by team, but by service type, technology stack, or business domain. This deeper insight helps engineering leaders make more informed decisions about where to focus improvement efforts.
+
+You'll learn more about [measuring arbitrary engineering metrics](/solutions/engineering-360/more-engineering-metrics) later in this solution.

docs/solutions/engineering-360/reduce-mttr.md

@@ -0,0 +1,31 @@
+---
+title: Reduce MTTR 
+sidebar_position: 5
+---
+
+# Reduce MTTR
+
+Mean Time to Recovery (MTTR) measures how quickly teams can restore service after an incident. A low MTTR indicates strong operational resilience and effective incident response processes. By optimizing MTTR, organizations minimize service disruptions and maintain high availability for their users.
+
+MTTR is influenced by several factors including incident detection time, diagnosis time and resolution time. Let's explore how a developer portal can help improve each of these areas.
+
+![MTTR breakdown](/img/solutions/engineering-360/mttr.png)
+
+Remember, the best solution is to prevent and reduce the impact of incidents. Take a look at our [incident management](/solutions/incident-management/prevent-and-minimize-incidents) solution for more.
+
+## Improve incident detection
+
+The faster an incident is detected, the sooner teams can begin working on resolution. Port can help streamline incident detection in several ways:
+
+- [Create JIRA issue from a NewRelic alert](/guides/all/create-jira-issue-from-newrelic/)
+- [Create a Pagerduty incident from a NewRelic alert](/guides/all/create-pagerduty-incident-from-newrelic-alert/)
+
+Take a look at our [incident management solution](/solutions/incident-management/detect-and-diagnose-incidents), where we cover detection in detail.
+
+## Improve incident diagnosis and resolution
+
+The faster your incident management team can access all the required data and diagnose a root cause, the sooner the incident can be resolved.
+
+By speeding up access to tools for privileged access to data or systems, or to take actions to address infrastructure issue - the incident can be resolved without lengthy approval bottlenecks.
+
+Take a look at our [incident management solution](/solutions/incident-management/operate-and-resolve-incidents), where we cover issue diagnosis and resolution in detail.