Technical and DevOps Architecture

DevOps consulting is the work of shortening the distance between a decision and a system running in production, and keeping it short as the estate grows. It covers the delivery architecture, the environments, the release and approval path, the shared platform layer every team builds on, and the reliability practice that sits inside all of them rather than beside them. Vivaldi works one level above delivery: we decide the architecture and the operating model, and your engineering teams and build partners implement it. Vivaldi has advised on business and technology strategy since 1999.

• Since 1999business and technology strategy
• 200+published case studies
• 10 officeson four continents
• 5xWirtschaftsWoche Best of Consulting, Strategy and Innovation
• Architecture, not staffingwe design the model, your teams and partners build it

When companies bring us in

The trigger is almost never a tooling decision. It is the moment someone senior notices that competent engineering is producing slow delivery, and nobody can say where the time goes.

• The second capability is quoted at the same price as the first. Nothing was reused, because there is nothing shared to reuse. This is the cost that never appears in the first business case.
• The pipeline is automated and the release still takes six weeks. Automation ends where approval begins, and approval was designed for quarterly releases.
• A cloud bill has outgrown the forecast. Workload placement was decided per project, so cost at real volume was never anyone's decision.
• An AI or data capability is about to go into production. The model layer, the data path and the release model all have to be settled before the first system, not retrofitted around it.
• Delivery has slowed as the estate has grown. Each team solves identity, secrets, logging, deployment and rollback again, and the slowdown reads as a headcount problem.

Why DevOps programs stall after the tooling arrives

The tooling is almost never the constraint. Most organizations that describe themselves as blocked on DevOps have already bought the pipeline, the container platform and the observability suite, and the lead time from decision to production has not moved.

Three reasons, in the order we usually find them.

• The path to production is a committee, not a pipeline. Automation ends where approval begins. The build takes hours and the release takes six weeks, and the fast part is the part that got funded.
• Every capability is built as a first capability. No shared platform layer, so identity, secrets, logging, deployment and rollback are solved again by each team. The cost shows up in the second project rather than the first, which is why the business case never sees it.
• Nothing feeds back. Production tells the team almost nothing it uses. Without a feedback path from outcomes into how the next thing is scoped and staffed, the system on day 300 is the system on day 1 with more traffic.

The first is a governance problem, the second an architecture problem, the third an operating model problem. None of them is fixed by buying more tooling, which is why so much of this spending produces capable teams who still cannot get anything out of the door.

What our DevOps consulting services include

Four bodies of work. Each can be engaged on its own, and the diagnosis usually points at one of them as the real constraint.

1. Delivery architecture and the path to production

The route from a merged change to a running system, made explicit and then made short.

• Where automation ends and human approval begins, set deliberately on materiality and reversibility rather than by default
• Environment strategy, so testing tells you something about production
• Release and rollback design, because the ability to undo cheaply is what makes shipping often safe
• The measures that predict everything else: lead time for change, deployment frequency, change failure rate, time to restore

2. Cloud architecture that survives a change of mind

Architecture decisions are commitments about what you can change later. We make those commitments explicit before they are made by accident.

• Workload placement and the cost curve at real volume rather than pilot volume
• Portability where it earns its keep, and deliberate lock-in where it pays for itself
• A model layer that stays replaceable, with models chosen per workload, so switching is a deployment decision rather than a rebuild
• Data residency, tenancy and isolation decided before the first system, because retrofitting them is a program of its own

3. A platform layer, so the second capability is cheaper

The shared substrate every team would otherwise build alone: identity, secrets, deployment, logging, tracing, cost attribution and the paved road that makes the safe way the easy way. We specify it and set who owns it. Your platform team or build partner constructs it.

• What is standardized centrally and what teams choose for themselves, written down
• Self-service where teams are the fastest path, and a queue only where a queue is genuinely required
• Cost attributed to the team that spends it, so the tradeoff is visible where it is made
• The ownership model after the engagement, named, so the platform does not become our dependency

4. Reliability and the feedback path

Reliability is a set of agreements before it is a set of dashboards.

• Service levels agreed with the business rather than set by the platform team alone
• Incident review that changes design rather than review that produces a document
• Observability scoped to the questions people ask at three in the morning
• The return path from production outcomes into how the next capability is scoped and funded

How a technical and DevOps architecture engagement works

1. Diagnose. We trace two or three recent changes from decision to production and record where each one waited. Interviews with engineering, security, platform and the business owner, read against the delivery data you already hold. The output is a view of where lead time is actually spent, which is rarely where the team assumes.
2. Decide. The delivery model, the approval design, the cloud and workload placement commitments, and the boundary of the shared platform layer. Decisions with the exclusions written down, including what will deliberately not be standardized.
3. Specify. The platform layer, the release and rollback model, the reliability agreements and the measures, written to the level an engineering team or build partner can implement without us in the room.
4. Hand over. Ownership named per component, the review triggers that keep the architecture honest, and the measurement model, so the next capability is cheaper than this one without a second engagement.

Why companies choose Vivaldi for technical and DevOps architecture

Three reasons come up repeatedly in the briefs we win.

• We are not selling the implementation. We do not staff pipelines, run platforms or resell cloud, so the architecture is not shaped by what we would be paid to build next. The firms that implement it are chosen after the decision rather than before.
• The architecture is judged commercially. The test we accept is what the next capability costs compared with the last one, alongside lead time, deployment frequency, change failure rate and time to restore. An architecture with no line to either is being defended on taste.
• Governance is treated as part of the architecture. Approval design, ownership and the feedback path from production into scoping are specified in the same document as the platform layer, because the slow part of most delivery estates is the part no engineer controls.

How to evaluate a DevOps consulting firm

Worth putting to every firm on your shortlist, including us.

• What will lead time be at the end, and how will we know? A firm that cannot commit to a direction of travel on lead time, deployment frequency and time to restore is selling activity.
• What does the second capability cost after this work? The whole point of a platform layer is that the answer falls. If it does not, you funded a migration.
• Whose cloud commitments are you carrying? Reseller margin, partner tiers and committed-spend agreements all shape architecture advice. Ask what theirs are, and ask whether the recommendation would change without them.
• What happens to our approval gates? A firm that automates the pipeline and leaves the release committee untouched has improved the fast part of a slow process.
• Who runs this in a year? If the answer is the consultancy, you bought an operating dependency rather than an architecture.

Architecture consultancy, platform engineering firm or cloud reseller?

Related work

Technical architecture is rarely the only constraint. Three connected pieces:

• API and systems integration if the constraint is that systems cannot reach each other rather than that releases are slow.
• Data strategy if the platform is fine and the data underneath it is not retrievable or governed.
• Digital products and platforms if the open question is what should be built at all, before how it ships.

This work sits inside our Business Technology Strategy practice at Vivaldi, the strategy firm behind the Demand Landscape and the Interaction Field, where the argument is that platform architecture is what makes AI-era products ship rather than a cost line underneath them.

DevOps consulting in the US and worldwide

Our technical architecture work runs out of ten offices on four continents, with the US team in New York. Most engagements are multi-region from the start, because the decisions that are hardest to reverse are the regional ones: where data may sit, which approval regime applies to a release, and which market's requirements end up setting the default for every other market. Deciding those once, deliberately, is cheaper than discovering them one country at a time.