total_score

maturity_band

maturity_next_step

Timp Apps Platform Health Assessment

app_foundations_score

delivery_perf_score

reliability_ops_score

platform_dev_score

Environment-specific configuration and secrets are commonly hardcoded or committed alongside application code.

Some configuration is externalized, but practices differ between services and important values remain in application code or configuration files stored in Git.

Most configuration is externalized, but storage and delivery practices vary between services.

Configuration and secrets are externalized, access-controlled, auditable, and delivered consistently across environments.

(1) How does your team manage configuration that differs between environments, such as service URLs, feature settings and credentials?

Dependencies are incomplete or installed manually, so builds frequently differ between machines.

Dependencies are declared, but builds still rely on globally installed tools, undocumented setup, or loosely controlled versions.

Dependencies and build tools are explicitly declared and reproducible from a clean environment for most applications.

Clean, repeatable builds are automatically verified, with dependencies and build tools pinned, updated, and governed consistently.

(2) How reliably can your team reproduce an application's dependencies?

Important persistent state is stored on individual application instances.

Most state is external, but some services still rely on local files, sessions, or instance-specific data.

Application processes are generally stateless, with persistent data stored in appropriate backing services.

Instances are disposable and stateless, and backing services have documented ownership, recovery, scaling, and availability controls.

(3) Where do running application instances store information that must survive a restart or replacement?

Environments differ substantially in runtime, dependencies, configuration, or deployment method.

Some standards are shared, but meaningful differences regularly cause deployment surprises.

Environments use substantially the same runtime definitions and deployment process, with documented differences.

The same build artifacts and runtime definitions are promoted between environments; differences are intentional, externalized, and automatically reproducible.

(4) How closely do development, test, staging and production environments resemble one another?

Build, configuration, and release are one integrated, manual process.

Build creates an artifact, but release configuration is applied manually or inconsistently during deployment.

Immutable artifacts are built once and promoted through most environments, with a few manual configuration steps.

Immutable artifacts are built once, combined with traceable release configuration, and promoted without rebuilding or modifying them.

(5) How clearly does your delivery process separate building an artifact, configuring a release and running that release?

Deployments are primarily manual and depend on engineer-specific commands or knowledge.

Reusable scripts exist, but routine deployments still require substantial manual execution or coordination.

Routine deployments are automated and repeatable, with intentional approvals or occasional service-specific manual steps.

Routine deployments are standardized, auditable, self-service, and require no unnecessary manual intervention.

(6) How are routine production deployments performed?

We avoid routine Friday deployments because failures can be difficult to detect, diagnose, or recover from.

We deploy only urgent changes or changes receiving significant coordination and monitoring.

We can usually deploy routine changes, but some services or teams remain risky.

Routine, low-risk changes are safe, observable, and quickly reversible on any normal working day.

(7) How comfortable is your team deploying a routine, low-risk change on a Friday during normal business hours?

Recovery is improvised and may take hours or require help from a specific engineer.

A recovery procedure exists, but it is manual, inconsistently tested, or unreliable for some services.

Most services can be restored within minutes using a documented and tested rollback or roll-forward procedure.

Failures are detected quickly, and recovery is fast, routinely tested, observable, and appropriate to each service's risk.

(8) When a production deployment fails, how quickly and reliably can the team restore service?

Several weeks or longer, with substantial queues, handoffs, or release windows.

Several days to a few weeks, with recurring environment waits, approvals, or coordination.

Most routine changes reach production within one or two days through a repeatable process.

Routine changes can reach production within hours through an automated process with appropriate risk controls.