# ALM maturity gaps in people, process and technology

*Platform Development Lifecycle and Deployment Architect Study Guide · Planning · Last updated October 26, 2026 · https://www.certifyforce.com/study-guide/platform-development-lifecycle-and-deployment-architect/planning/alm-maturity-gaps-in-people-process-and-technology*

How to assess a Salesforce team against the Well-Architected Operational Excellence maturity levels and name the fix for each gap: correlated logging, runbooks and distributed review, declarative review, real quality gates, fast CI with callout mocks, blameless postmortems, on-call rotation, version control as the change record and environments defined in source.

- Certification: Salesforce Platform Development Lifecycle and Deployment Architect
- Exam section: Planning
- Study guide: https://www.certifyforce.com/study-guide/platform-development-lifecycle-and-deployment-architect

**Official exam objective:**

> Given a complex customer scenario, assess ALM maturity and identify the people, technology, and processes required.

## What the exam expects

- Place a team on the Well-Architected Operational Excellence maturity levels (Lean, Scale and Governance Optimized) and name the next step that fits its size and risk.
- Spot people gaps (one reviewer, one release person, one incident owner) and recommend distributed review, runbooks and an on-call rotation.
- Spot process gaps: unreviewed declarative changes, quality gates nobody trusts, blame-focused incident reviews.
- Spot technology gaps: uncorrelated logs, slow all-or-nothing CI, orgs as the only change record, hand-built environments, and know when to start source-driven development.

Key terms: **observability** (understanding internal state from logs, metrics and traces); **correlation ID** (one identifier carried through every step of a process so its log entries join up); **bus factor** (how many people can leave before knowledge is lost); **quality gate** (an automated check a change must pass to move on); **blameless postmortem** (an incident review that seeks the systemic cause, not a culprit); **infrastructure as code** (an environment's definition and seed data in version control).

## Key facts

| Fact | Detail | Source |
|---|---|---|
| Approvals | Two for production-bound changes; three in a five-person team is a bottleneck | [Operational Excellence](https://architect.salesforce.com/docs/architect/well-architected/guide/operational-excellence.html) |
| Declarative review | Flows, validation rules, permission sets and sharing rules get the same review as code | [DevOps Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/operational-excellence-devops-patterns.html) |
| Pipeline time | Target under 15 minutes; 45-60+ minutes is an anti-pattern | [DevOps Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/operational-excellence-devops-patterns.html) |
| Callouts in tests | Tests that perform callouts fail by default; use `Test.setMock` so the callout is not made and the mock response is returned | [Testing HTTP Callouts](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_restful_http_testing.htm) |
| Postmortems | All Severity 1 and 2 incidents, within 24-48 hours, blameless | [Operational Excellence](https://architect.salesforce.com/docs/architect/well-architected/guide/operational-excellence.html) |
| Setup Audit Trail | Date, user and what changed; download covers the past 180 days, after which entries are deleted | [Setup Audit Trail](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&language=en_US&type=5) |
| Scratch org definition file | Edition, add-on features and settings; check a team version into source control | [Scratch Org Definition File](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm) |
| Source-driven timing | Complete the move early, before org-based habits solidify | [DevOps Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/operational-excellence-devops-patterns.html) |

## Check yourself

- Why does a correlation ID help more than extra log volume when a multi-step process fails?
- When does a single incident owner stop being an acceptable model?
- What happens to an Apex test that makes a real HTTP callout?
- When should a team move from org-based to source-driven development?

## Sources

- [Operational Excellence | Well-Architected Framework](https://architect.salesforce.com/docs/architect/well-architected/guide/operational-excellence.html)
- [Operational Excellence - DevOps Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/operational-excellence-devops-patterns.html)
- [Reliability | Well-Architected Framework](https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html)
- [Application Lifecycle Management for Salesforce Teams](https://trailhead.salesforce.com/content/learn/modules/salesforce-application-lifecycle-management-quick-look/learn-about-salesforce-application-lifecycle-management)
- [Monitor Setup Changes with Setup Audit Trail](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&language=en_US&type=5)
- [Testing HTTP Callouts](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_restful_http_testing.htm)
- [Testing HTTP Callouts by Implementing the HttpCalloutMock Interface](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_restful_http_testing_httpcalloutmock.htm)
- [Build Your Own Scratch Org Definition File](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm)

## About the full unit

The "Core concepts", "Exam traps" and "Worked scenario" sections of this unit, its 10 linked practice questions, and unlimited timed mock exams are included with the Platform Development Lifecycle and Deployment Architect pack (USD $19): https://www.certifyforce.com/practice-exams