This blog is intended for developers who are developing side-by-side extensions to keep in mind the DORA metrics to be taken care of in design, development, deployment, and recovery strategies to ensure high performance and reliability across your BTP systems.
What is DORA?
DORA stands for DevOps Research and Assessment, a framework developed by Google to measure software delivery performance. It’s based on years of research and real-world data from thousands of engineering teams. DORA identifies four key metrics that correlate strongly with high-performing software teams:
- Deployment Frequency
- Lead Time for Changes
- Change Failure Rate
- Mean Time to Restore (MTTR)
These metrics help teams understand how efficiently and reliably they deliver software—and where they can improve.
The Four DORA Metrics
Deployment Frequency
- How often code is deployed to production.
- High-performing teams deploy multiple times per day.
Lead Time for Changes
- Time from code commit to production deployment.
- Elite teams achieve this in under an hour.
Change Failure Rate
- Percentage of deployments that cause failures.
- Lower rates indicate better stability and testing.
Mean Time to Restore (MTTR)
- Time taken to recover from a failure.
- Elite teams restore service in less than an hour.
Benefits of DORA
- Objective Measurement: Tracks performance with real data.
- Continuous Improvement: Helps teams identify bottlenecks and improve.
- Benchmarking: Compare against industry standards.
- Collaboration: Encourages Dev and Ops teams to work together.
- Automation Focus: Promotes CI/CD, automated testing, and observability.
Use Cases
- DevOps Maturity Assessment
- Software Delivery Optimization
- Incident Management
- Performance Benchmarking
- Toolchain Integration (e.g., SAP Cloud ALM, Signavio, LeanIX, BTP)
Why DORA Matters for Side-by-Side Extensions
Side-by-side extensions are often developed in parallel with core applications, sometimes by different individual developers or teams or contributors in your project implementation for the need. This modular approach offers flexibility, but also introduces complexity in deployment, testing, and recovery. DORA metrics help manage that complexity by providing a clear lens into your development and delivery process.
Let’s break down how each metric applies:
1. Deployment Frequency
What it means: How often you release changes to production.
Why it matters:
In side-by-side development, frequent deployments allow you to iterate quickly without disrupting the core app. It also helps isolate bugs and reduce integration risks.
How to improve:
- Automate your CI/CD pipeline.
- Use feature flags to release safely.
- Keep changes small and focused.
2. Lead Time for Changes
What it means: Time from code commit to production deployment.
Why it matters:
Short lead times mean faster feedback and quicker delivery of new features or fixes. This is especially important when extensions need to respond to changes in the host application.
How to improve:
- Streamline code reviews.
- Avoid long-lived branches.
- Optimize build and test processes.
3. Change Failure Rate
What it means: Percentage of deployments that cause failures.
Why it matters:
Side-by-side extensions often interact with shared APIs or services. A high failure rate can disrupt the user experience or break integrations.
How to improve:
- Invest in automated testing (unit, integration, regression).
- Use canary releases or staged rollouts.
- Monitor error rates and logs post-deployment.
4. Mean Time to Restore (MTTR)
What it means: Time taken to recover from a failure.
Why it matters:
When an extension fails, users may lose access to key features. Fast recovery is essential to maintain trust and minimize downtime.
How to improve:
- Implement robust logging and monitoring.
- Use rollback strategies or hotfix pipelines.
- Document recovery procedures and automate where possible.
+-------------------------------------------------------------+
| DORA Framework |
| |
| ┌────────────────────────┐ ┌──────────────────────────┐ |
| │ Deployment Frequency │ │ Lead Time for Changes │ |
| │------------------------│ │--------------------------│ |
| │ - Frequent releases │ │ - Fast code-to-prod time │ |
| │ - CI/CD automation │ │ - Streamlined reviews │ |
| │ - Feature flags │ │ - Optimized builds/tests │ |
| └────────────────────────┘ └──────────────────────────┘ |
| |
| ┌────────────────────────┐ ┌──────────────────────────┐ |
| │ Change Failure Rate │ │ Mean Time to Restore │ |
| │------------------------│ │--------------------------│ |
| │ - Automated testing │ │ - Fast recovery │ |
| │ - Canary releases │ │ - Rollback strategies │ |
| │ - Error monitoring │ │ - Hotfix pipelines │ |
| └────────────────────────┘ └──────────────────────────┘ |
| |
| → Applied to Side-by-Side Extensions: |
| - Modular development |
| - Independent deployment |
| - Integration with core apps |
+-------------------------------------------------------------+Technologies Involved
| Technology | Role in Extension |
| CAP (Cloud Application Programming Model) | Backend services, APIs, business logic |
| SAP Build Apps | Low-code/no-code UI development |
| SAP Build Process Automation | Workflow orchestration, approvals |
| SAP HANA Cloud | Persistent data storage, analytics |
| SAPUI5 / Fiori Apps | Rich user interfaces |
| SAP Build Code - Joule for Developers | AI-assisted development, productivity boost |
Example Scenario: Leave Request Extension
- Frontend: SAP Build Apps or SAPUI5
- Backend: CAP service with business logic
- Workflow: SAP Build Process Automation for approvals
- Database: SAP HANA Cloud
- AI Support: Joule suggests code snippets and optimizations
- DevOps: CI/CD pipeline with GitHub Actions or SAP Continuous Integration and Delivery
Most Important for utlizing all the BTP Services and deployed in your space - Application Vulnerability Report is must
Bluesky
