What to look for in a platform assessment

A platform assessment should answer a practical question: which parts of your infrastructure are making software harder to deliver, operate, or maintain, and what should you change first?

A list of tools, a maturity score, and a collection of generic recommendations are not enough.

A useful assessment follows actual engineering workflows, examines the infrastructure behind them, and produces prioritized work that your team can execute.

Follow a real deployment and a recent incident

Ask the assessors to follow one production change before they interview anyone about strategy. Pick a normal one: a bugfix in a service that matters. Write down the waits. Who reviews infrastructure? Where does a human still intervene? Which environment is a lie?

Then ask them to follow one incident, or the last one you remember clearly. What question could you not answer from telemetry? Who was required in the room?

Those two traces will embarrass a checklist and educate a good engineer. They also stop the assessment from becoming a survey of tools. You already know you have Terraform, a cluster, and a CI vendor. The question is whether a developer can move through them without custom help.

What a platform assessment should examine

For a software company that has outgrown ad-hoc DevOps, the scope is the platform as a system, not a single tool:

• Cloud accounts or subscriptions, network, and identity
• Infrastructure as code, modules, and state
• Kubernetes, if it is in the path, including whether it should be
• CI/CD, GitOps, and environment promotion
• Secrets and the permissions CI actually has
• Observability, alerting, and how incidents run
• Reliability work: SLOs if they exist, toil if they do not
• Cloud spend, with attribution if the labels allow it
• Developer experience, measured on that real change

If a proposal excludes cost, it will miss a conversation your CFO is already having. If it excludes developer experience, it will recommend a platform nobody adopts. If it is only a Kubernetes review, it will optimize a runtime that may not be the constraint.

It does not need to be a six-month discovery. Depth comes from reading repositories, plans, and bills, not from more workshops.

Five deliverables worth expecting

Insist on these, in writing:

• Current state. How the system behaves, including the informal paths. If the diagram and the cluster disagree, the assessment should say so.
• Findings, ordered. A short list. A fifty-item register is a way to avoid judgment. Each finding needs a consequence: delivery time, incident risk, security exposure, or money.
• Cost opportunities, separated from guesses. Idle resources are not the same as “you might save 30% with a modernization program.” The second sentence is not a finding.
• A target shape. Not a vendor reference architecture pasted in. The smallest platform that would remove the constraints you actually have, using what you should keep.
• A 90-day roadmap. Ordered work, with what not to start. The first items should be doable by your team or by the people who wrote the assessment. If every item requires a new platform program, you bought a strategy deck.

A good assessment is slightly uncomfortable. It names the path everyone bypasses, the alert nobody believes, and the account that was never supposed to hold production.

Warning signs in an assessment proposal

Walk away, or at least recalibrate, if you see these:

• The document leads with a maturity score and a target level. Levels are not work.
• Every road leads to a product the assessor resells.
• There are no repositories, plans, or bills in the method. Only interviews.
• Savings are promised before the bill has been read.
• The recommendation is a platform team of fifteen people you were not going to hire.
• Kubernetes, a service mesh, and a developer portal appear as a bundle, unrelated to a constraint.

A fractional follow-on is reasonable if you want help implementing the roadmap. It is not reasonable as the hidden point of the exercise. You should be able to take the roadmap and execute the first month without the authors. That is the test of whether knowledge was transferred or rented.

What to prepare before an assessment

You do not need a perfect brief. You do need access. The assessment moves faster when someone can read, under your normal controls:

• The infrastructure repositories and recent plans
• CI configuration for one flagship service
• Cluster and cloud console access, read-only
• The last cloud bill, even if the labels are bad
• Two people who ship, and the person who gets paged

Hide nothing that is embarrassing. The informal deploy script is the system. The tidy diagram is the aspiration.

What a useful final readout looks like

The readout should fit in a conversation with a CTO and the engineers who will do the work. Disagreement is part of it. A finding you reject is still useful if the evidence is on the table. A finding everyone nods at, with no owner and no sequence, is not.

Leave with a first change. Not a transformation. One boundary in the Terraform, one promotion path, one set of signals, one chunk of waste deleted. The rest of the roadmap can be argued next. If the assessment cannot name that first change, it was not finished.

An assessment is useful when it makes the next engineering decision easier.

You should leave knowing what is wrong, why it matters, what to change first, and which improvements can wait. You should also have enough information to proceed without depending on the people who wrote the assessment.

That is the standard we apply to our own Platform & DevOps Assessment.

See what's included in our platform assessment.