From Legacy to Sovereignty: Driving the Future of Insurance through Platform Engineering

Most platform stories are told as tool selections. Sergiu Petean tells his as a sequence of identity changes: every time the platform team's scope grew, the team's topology, its metrics, and the story it told the board had to be rebuilt too. His central thesis is that platform engineering in a heavily regulated enterprise is an experience and stakeholder problem before it is a tooling problem, and that a platform team survives budget scrutiny only if it can translate its capabilities into the language each board persona already cares about.

Petean has spent over 15 years in financial services and insurance and led the CNCF Technical Advisory Board working group on reference architecture. The talk covers roughly five years at Allianz Direct, a European direct insurer, starting in February 2021. It was recorded at InfoQ Dev Summit Munich and runs 51 minutes and 40 seconds.

These notes report what Petean presented. Where I add context that an intermediate engineer needs but that the talk did not state, it is marked as supplementary.

What You Will Learn

• Why a static reference architecture is less useful than two dated versions of a changing one, and how the gap between them becomes a backlog.
• How a platform team's topology should change as its scope grows, through five concrete stages from advocacy team to multi-platform team.
• How to make a security scanner's output actionable rather than paralysing, and how to attach ownership to every finding.
• How DORA metrics can be extended with a financial metric and used as a self-improvement mirror rather than a performance ranking.
• How to map platform capabilities to specific board personas (COO, CFO, CEO, Chief Transformation Officer) so that cost-reduction conversations become trade-off conversations.
• What "innovation sovereignty" and "digital sovereignty" mean for tooling choices, and why open source functions as an exit strategy.

Framing: Foundations Before Flying Cars

Petean opens with an analogy. Boards and engineering rooms alike are drawn to "flying cars" — AI-driven innovation that looks spectacular. He argues this is an opportunity cost. Autonomous cars were not a revolution; they were years of incremental foundation work that only looked sudden from the outside. His advice is blunt: make flying cars your hobby, build something strong as a profession, and you will enjoy both.

He then splits enterprise reality into three pillars. Most organizations still spend most of their time on legacy infrastructure, which is also where most of the revenue is generated. Some have moved to cloud-native transformation. The luckiest are already working on platforms, whether cloud-native or AI. His observation about the current economic cycle is that we are "trading productivity for cost reductions", which makes the financial and strategic impact of platforms something that must be explicitly understood and defended rather than assumed.

Reference Architectures Should Be Dynamic

The CNCF working group Petean led started with a natural assumption: produce one single reference architecture for cloud-native. That assumption failed on two counts.

First, a single diagram forces a vendor-selection fight. He describes the debate over which vendors should not appear, and how many enemies each inclusion would make. Second, and more importantly, a single image cannot represent the range of constraints that actually shape a platform. The group moved instead to clustering by parameters:

The second correction is the more transferable one. A static reference architecture tells you where someone arrived, but not where they came from, what they had to fight, what they called legacy, or where they intend to go next. Petean's practice is therefore to maintain two versions: the current state, and the intended state roughly six months out. He found six months a good interval. The delta between them is, in his words, most likely your backlog — which gives a product team an unambiguous definition of what it should be working on.

Inside Allianz Direct the first future-state reference architecture was about 99% open source, which he describes as a courageous choice for an enterprise at that time.

Platform Engineering Is Not the Same Thing as an IDP

Petean's working definition is that platform engineering is about experience more than tooling. Technology matters, but which technology you use is determined by the forces and stakeholders acting on you.

The common preconception is that a platform is one-to-one with an Internal Developer Platform (IDP), and that an IDP is about developer experience. In his environment developers were not the strongest stakeholder. Security, compliance, the CEO office and the Chief Transformation Office were larger forces. So the platform had to be aware of all of them, and he had to understand where each one derives value in order to hold a KPI conversation with them.

He notes a structural asymmetry in why this matters. Business success is routinely summarised in two or three KPIs — growth, return, premiums, happy customers — and everyone accepts the story. Platform engineering has no equivalent shared vocabulary for success, no way to compare yourself with anyone else, and therefore no way to have a credible conversation about whether you succeeded and for whom.

Stage 1: Escaping the Fake SRE Anti-Pattern

Petean joined Allianz Direct in February 2021 and found the team was living in a wrong identity: it believed it was doing SRE, and it was not. The slide labels this Anti-Type H: Fake SRE. (Supplementary: the "anti-type" naming convention comes from the widely used DevOps topologies catalogue associated with Team Topologies, which classifies recurring team patterns as either patterns or anti-types. The talk did not explain the label.)

His first step was realisation, then hard conversations to define the team's principles and internal identity. The first principle he insists on is that you are a product team building a product driven by principles — personal or ideally company-wide — with a written mission.

Writing them down matters for a practical reason he emphasises: people join, people leave, and you constantly deal with third parties. The written principles are what holds the team together and forms its culture. He makes them available to HR and puts them in job descriptions so that hiring filters for compatibility with the principles rather than only for skills.

Stage 2: DevOps Advocacy Team

With a new identity as a product, the team declared itself an advocacy for DevOps: this is how DevOps should be implemented in our organization, and these are the qualities we want. The 2021 mission — written before "platform engineering" was a common term — was to build a future-proof platform and enable teams to deploy, monitor, and maintain their own production environments. Petean restates it as the old DevOps principle with an amendment: you build it, you run it, but not alone — you do it through us, with our help.

Innovation Sovereignty as a Build/Buy Stance

The team needed a companion catalogue of services on top of the hyperscalers, but did not want to become pure consumers. This is where Petean introduces the concept he returns to throughout the talk: innovation sovereignty, which he reduces to a simple choice between consuming and creating. Their decision was to create — leveraging the wisdom already available in CNCF projects and open source, but being deliberate about pulling that expertise inside the team, retaining it, and moving with the cloud-native stream.

Rewriting the Release Process

The trigger was a live launch in a new country using the old way of working: Jenkins plus roughly 200 scripts written in an assortment of languages. The whole team focused for two months and replaced the software release process with a new CI/CD system built on Tekton. He notes GitHub Actions was not yet where it is today and was not considered reliable enough at that point; today they run Tekton and GitHub.

(Supplementary: Tekton is a Kubernetes-native CI/CD framework where pipelines and tasks are custom resources, so the delivery system is declared and versioned the same way as the workloads it deploys. That property is what makes it a natural fit for an open-source-first, portable platform.)

Measuring With DORA, Then Extending It

Having changed everything at once, the team needed to know whether the change was positive. They adopted DORA metrics — deployment frequency, lead time for changes, change failure rate, time to restore, plus reliability. Petean's strong opinion, which he still holds, is that you should not only compare yourself with your past self but with the industry as a whole, because otherwise you cannot tell how meaningful your improvement is. They were surprised to land in the elite cluster, releasing on demand several times a day. He immediately names the counterforce: reliability under that speed.

The more interesting evolution is what DORA became afterwards. Rather than a one-off confirmation, they turned it into a tool for identifying improvement patterns per engineer and per team, comparing behaviours across teams and holding up the best teams as examples. Zooming into pull requests and feature requests surfaced concrete diagnoses. One team was failing heavily at a very late stage in pre-production and releasing slowly to production as a result; the root cause was insufficient unit testing in the test environment, meaning they were not using CI/CD properly to get early quality feedback.

The team then promoted the results — Petean is explicit that a team needs to create a brand and go and brag in front of the board. The first substantive pushback came from the COO, who was concerned about cost per unit: it is nice to be as good as Google, but does that cost too much? That question produced Petean's own addition to DORA, a cost per change unit. At the time it was about €49 per change, which he judged not a bad deal, though he acknowledges the open question of what anyone else's figure is and therefore whether it is good or bad. He frames this financial metric as the platform team's contribution to DORA, added specifically to bring the CFO and COO into the conversation.

(Note: he cites €49 per change in this section and €48 later when describing the progression. The talk does not reconcile the two figures; treat it as approximately €48–49 at the starting point.)

Making Security Scanning Actionable

Regulated environments push hard for security to be embedded in the release process. The team had an unused licence for Prisma being applied only reactively and decided to configure it properly. The result was more than 50,000 vulnerabilities — a number Petean says makes shifting left impossible and that blocked the whole organization.

The fix was not another scanner. He hired a small, strong team that built a vulnerability management module sitting on top of tools like Prisma and Wiz, injecting the organization's own security intelligence to reduce noise. The count dropped to fewer than 100, at which point shifting left became feasible. The remaining question — which he treats as the harder one — was not what to fix but who needs to act.

Petean's takeaways from this phase: innovation sovereignty depends on getting and keeping the right talent and giving it room to grow; hiring the first technical leads and establishing a culture of work ethics and quality is essential because those people recruit their peers and carry the culture outward; and team identity plus product mindset underpin everything else.

Stage 3: Federated SRE (SRE as a Service)

The next challenge was extending CI/CD to reflect stakeholders beyond developers. The team brainstormed across security, incident management, delivery and users, identified KPIs for each, and concluded that the platform needed a process capable of identifying owners and giving them actionable insight into their own concerns.

Concretely, for security they built a catalogue of services and automated its integration with Opsgenie, which centralises incidents and alerts. Previously all alerts hit one small team; the redesign routed them across the organization. Two rules made this bearable:

• Any alert that does not carry a runbook does not carry an actionable insight, so runbooks were made mandatory behind alerts.
• Each team received up to 10 vulnerabilities to fix within the next 28 days.

Petean credits this with producing an SRE process capable of understanding the full governance of their IT assets, which he calls essential, and it opened the door to automation conversations and feedback loops with other stakeholders, including first steps towards continuous compliance.

The OrgSRE Topology

The topology changed to match. A group he calls OrgSRE or OrgOps — platform engineers focused on SRE rather than a conventional SRE team — defined the process and the tools, exchanged with every stakeholder consuming the new services, and behaved as a centre of excellence, educating the rest of the organization on how to automate their own needs into the process.

Federation was forced by scale. Allianz Direct grew from 150 employees to around 1,000 with more than 300 engineers, and today has around 2,000 engineers. A DevOps team cannot scale at the same rhythm, and the budget would not allow it. So the platform was made self-service by design, and the knowledge was federated.

The organizational lever was a negotiation with the business for 20% of every squad's time to be dedicated to operations, prioritised as incidents first, then security, then SRE. Alongside it they created an SRE community, and teams started becoming independent.

Adoption Lags Delivery

This is one of the most useful numbers in the talk for planning purposes. The technical work — changing the whole stack and creating new processes — took about four months and initially produced no results at all, because adoption did not follow. It took a further eight months of convincing the organization of the qualities the new process brought.

Three things helped: building the community; the 20% negotiation; and above all a new organizational role, the TTL (Technical Tribe Lead) — a technical person seated next to the business decision maker in each business tribe (for example, a claims tribe). TTLs had the authority to tell engineers that SLOs and the APIs covered by SLAs matter to the business, which caused the business to allocate real time to that work. It was made mandatory for every squad.

Stage 4: Reverse Conway and the Cognitive Load Problem

Federation solved scale but exposed cognitive load. The stack had grown large enough that only two people — the technical leads who had been there from the beginning — could cover more than 90% of it. A product needs a holistic view, so the question was how to give other engineers that view without waiting a year for each of them to absorb the entire stack.

Petean applied a reverse Conway manoeuvre: rather than letting the existing team structure dictate the architecture, he reshaped teams to mirror the target reference architecture. (Supplementary: Conway's law observes that systems mirror the communication structures of the organizations that build them; the reverse manoeuvre deliberately restructures teams to obtain the architecture you want.)

The mechanism is DDO — Distributed DevOps — temporary working groups lasting a few months, each covering a slice of the stack. Within a DDO an engineer holds one of three roles:

• Student — learning the domain.
• Executor — doing most of the work.
• Consultant — setting direction.

Rotation through DDOs was made mandatory with targets. The effects Petean reports are worth separating because they address two different problems. For onboarding, a new hire contributes from day one in the DDO matching their expertise — an API expert contributes to the API DDO immediately — instead of being overloaded with the whole stack. For depth, an engineer covers roughly three DDOs a year, four if they are especially bright, and over two years the team produced two or three more people capable of handling more than 85% of the stack and therefore of making holistic product decisions.

The DDO domains he names are observability, SRE, CI/CD, IAM, operations, storage, and Kubernetes plus AWS. He is explicit that this is not a silo structure because engineers rotate: they are temporary silos, and that is precisely what makes them a simplification device for growing into areas where you lack expertise.

Stage 5: Shielded DevOps Topology

The next regrouping addressed where the team's time was actually going. Under pressure not to scale headcount with the organization, they found too much time consumed by incident noise and by invisible compliance work. The response was role specialisation designed to protect the backlog:

The target was for the team to spend more than 80% of its time on the backlog, where the backlog is defined exactly as before: how to get from reference state A to reference state B. The ninja role isolates external conversation to one person so everyone else stays on that backlog. The tech desk was explicitly tasked not just with answering questions but with creating automation, documentation and self-service, and with filtering noise before it reaches other teams.

His takeaway here is a resource argument: a DevOps or platform team is expensive and highly skilled, so do not waste its energy on writing or handling tickets unless those tickets are genuinely written for it.

KPIs Became the Organization's OKRs

Because the team had built credible conversations with business and the COO, when the organization moved to OKRs it asked the platform team for its KPIs to become the technical OKRs. Petean describes this as setting the tone for business and becoming equals with it — something he says does not happen often in Germany, where IT is mostly treated as a cost centre. The practical payoff was the ability to write demands to the business: the 20% allocation became genuinely 20%, negotiated in quarterly business reviews and mandatory for everyone, and availability plus API SLOs were added to the shared objectives.

Stage 6: Multi-Platform Team

Having demonstrated and articulated value, the platform team was asked to ride the AI wave. Petean's reasoning for why it fell to them is that the cloud-native platform team was the only internalised group capable of executing on any revolution and was already recognised for implementing and enforcing standards.

He rejected what he calls the chaos approach — hundreds of proofs of concept that all fail and from which nothing is learned, because no reusable components are captured. Instead, about a year and a half before the talk, he created a reference architecture for AI cloud-native and the team was first to execute on AI use cases. The team thereby became a multi-platform team under the same financial pressure, unable to grow, taking care of several platforms with essentially the same focus and structures.

Architecture And Data Flow

The system Petean describes is really two loops: a delivery loop that produces changes, and a governance loop that routes findings to owners and reports capability metrics upward.

flowchart TD
    subgraph Delivery["Delivery loop"]
        DEV[Product squads] --> CI[Tekton and GitHub CI/CD]
        CI --> ENV[Non-prod and prod environments]
    end
    subgraph Governance["Governance loop"]
        SCAN[Prisma and Wiz scanners] --> VM[Vulnerability management module]
        VM --> OPS[Opsgenie routing with mandatory runbooks]
        OPS --> DEV
    end
    ENV --> SCAN
    ENV --> DORA[DORA metrics plus cost per change]
    DORA --> KPI[Platform capability KPIs]
    VM --> KPI
    KPI --> BOARD[Board personas: COO, CFO, CEO, CTrO]
    BOARD --> BACKLOG[Platform backlog: state A to state B]
    BACKLOG --> PLAT[Platform team]
    PLAT --> CI
    PLAT --> SCAN

The organizational structure that operates this system changed five times. The progression is easier to read as a sequence of scope expansions:

flowchart LR
    A[Anti-type: Fake SRE] --> B[DevOps advocacy team]
    B --> C[Federated SRE / OrgOps]
    C --> D[Reverse Conway with DDO rotation]
    D --> E[Shielded DevOps with ninja and tech desk]
    E --> F[Multi-platform team incl. AI]

Two details make the governance loop work rather than merely exist. Alerts without runbooks are removed, so routing an alert to a team always hands them something they can act on. And vulnerabilities are throttled to at most ten per team per 28 days, so ownership is a workable commitment rather than an unbounded queue.

Translating Platform Capabilities to the Board

This is the part Petean calls the best part, and it is a framework rather than an anecdote. Under pressure to defend his team's size and the organization's investment, he examined each board persona, identified capabilities the platform already provided that the persona was not aware of, and translated those capabilities into terms the persona already took for granted.

Compliance enabler. The COO in a German enterprise has two major objectives: mitigate risk first, contain cost per unit second. When a conversation arose about the team being too large, Petean could point to years of monitoring and to 14 different audits in less than one year. That reframes a cost cut as a trade: we can execute the reduction, but there will be a consequence for compliance — would you accept, say, 95% instead of 100%? The answer was no, and the price per unit suddenly became acceptable.

Financial performance. His claim here is that a platform team that does the job well becomes a centre of expertise, and that selling knowledge, expertise and even technology then becomes easy. In the year of the talk they made €1.4 million profit and were scaling from that. The CFO, who had worried about overspending on the team, became a supporter. This is reported as his experience inside one insurer, not as a general rule.

Innovation driver. The CEO and Chief Transformation Officer want to launch new features in new markets fast, test scenarios and react. In insurance that means testing pricing schemas and marketing strategies and getting feedback per market. Petean deliberately attaches this to changes across all environments, not only production changes as DORA measures, because much innovation happens in non-production environments.

The cost curve. Correlating change volume with the financial metric gives the headline progression: from about €48 per change down to €13 per change, while adding 100,000 changes a year. He contextualises the volume: with around 150 microservices, that is changing each service a few times every day.

Operational resilience. Speed and reliability balance each other. Reliability grew in importance because the entity became an InsurTech and began writing contracts with technology companies that demanded SLAs, making reliability a fundamental KPI in every contract and therefore a reputational risk factor concerning both CEO and COO. The transformation executive responsible for those contracts was satisfied that the main SLA was monitored and held.

The deeper point is the last one: the board should understand not only that capabilities exist but where they come from, and what the consequences would be of trimming the platform's cost.

Owning the Operational Model

Petean's second set of learnings is about influence. He prefers the word educator to influencer: a platform leader must become an equal force in driving operations and innovation and cannot be reactive. He acknowledges this is hard in Germany, where the business/technology relationship is unequal and IT is treated as an outsourceable cost centre.

His example is a group programme he advised the previous year, which had less than eight months to go from nothing to a cloud-native platform in production supporting markets including Australia and Brazil. The architecture function — another strong force in an enterprise — was writing the operational model, and the platform team was only optionally invited. He says that had that operational model gone live, their life would have been "a horror movie". He joined late, corrected it, and re-scripted the operational model.

The underlying friction he identifies is the belief that infrastructure is a small component whose owners should only care about operations and know nothing about release, compliance and security. His counter is that a platform is not infrastructure; it has many other capabilities that have a large effect on the operational model. Getting the right scope for the right functions into it — his example is versioning, specifically how software is released on APIs and how services are decoupled from APIs — simplifies subsequent work enormously. If someone else writes it, you become captive to a projection that does not fit your work.

Simplify everywhere. The team destroyed and rebuilt its architecture at least four times, using the creation of a new tenant as the opportunity each time rather than copying the existing setup forward. Treating the old setup as legacy gave them the chance to change significant things at architecture level. He ties this directly to FinOps: the biggest force in FinOps is your architecture, and if the architecture is designed for efficiency there is comparatively little FinOps work left to do.

Sovereignty

Petean argues sovereignty and resilience should be part of every platform conversation and embedded in platform design. He expects the multi-cloud conversation of a few years ago to be succeeded by a multi-cloud plus private cloud conversation, and recommends having an explicit sovereignty strategy defined by how fast and how expensive it would be to move from a hyperscaler to a private cloud or data centre. That constraint should feed back into tool selection.

For him, going open source was exactly that: an exit strategy already in hand, because 90–95% of their tools can move wherever Kubernetes runs. There is effort and cost, but far less than the alternative — and he offers this as an argument platform teams can use when defending design choices.

He grounds digital sovereignty in examples rather than abstraction: sovereignty at state level is under threat, and a major Google Maps outage he cites disrupted a platform Europe does not control but that Europeans depend on daily.

On top of that he places his personal concept of innovation sovereignty: the capacity to create. Investing in technology and in people, and giving them space to grow, is what makes you able to jump on the next wave — when AI arrives, you have the means and tools to create your own future rather than only to consume someone else's.

He also raises cultural sovereignty, at the personal rather than state level: mental models are formed by what we consume, and young people consume TikTok, US platforms and LLMs authored outside Europe, so there is little European or democratic value reflected in the tools shaping the next generation. He notes he joined the board of the European Resilience Summit, where the spectrum of sovereignty and resilience is being discussed, and suggests Europe's plausible role is open sovereignty — open source as something other states can contribute to — because trust has to be in the open in a fragmented world.

KPIs, Gaming, and Deciding Which AI Use Cases Are Real

Two audience questions produced material worth carrying forward.

How do you stop developers from optimising the KPI rather than the outcome? Petean's position is that KPIs should not be a mechanism for enforcing work ethics. DORA worked for them because it was a mirror, not a sheriff: no wall of shame, no team getting slammed. Teams looked at themselves, understood their own behaviour better, compared with teams handling different domains, and learned from each other. If you have a culture of continuous improvement this goes smoothly; in a toxic environment where KPIs are a weapon, gaming them becomes a survival skill and the metric tells you nothing.

For the platform team's own people metrics he describes a peer survey covering QA, coding, focus, growth and especially impact, where team members evaluate the people around them on whether that person made their work better and helped them grow. He is explicit that they never measured lines of code, infrastructure designed, or number of APIs.

How do you keep AI work connected to the business? As head of GenAI he created a funnel for deciding which use cases to address. Ownership always stayed with the product or business person who brought the case, and they had to pitch with numbers and KPIs — for example, this conversational AI investment will save this many hours from this many agents, who can then spend more time selling and giving customers information from the policies. The funnel kept prioritisation data-driven and also filtered out what he calls fake AI: cases that could simply be coded with no reason to add an LLM, or cases that were a better fit for classical machine learning. The decision process is about choosing the right implementation and the right team, driven by data and accountability.

Trade-offs And Limitations

• Adoption is the long pole, not construction. Four months of engineering produced no measurable result until eight further months of persuasion. Plan organizational change budgets accordingly; a technically finished platform is roughly a third of the work.
• The 20% operations allocation is a real tax on feature delivery. It only held because it was negotiated with the business, made mandatory, and enforced through QBRs and the TTL role. Without that authority it degrades quickly.
• Noise reduction shifts trust into your own filter. Reducing 50,000 findings to under 100 means an internally built module is deciding what does not need attention. Petean does not describe how false negatives are guarded against, and in a regulated environment that suppression logic is itself something auditors will want to inspect. This caveat is mine, not the speaker's.
• DDO rotation trades short-term throughput for resilience. Having engineers cycle through unfamiliar domains as students costs delivery speed now to buy holistic decision-making later.
• Cost per change lacks an external benchmark. Petean is candid that he had no way to know whether €49 per change was good or bad relative to others; its value came from year-over-year comparison inside one organization.
• The €1.4 million profit is one organization's outcome. It depended on being able to sell expertise and technology internally within a large group, which is not available to every platform team.
• Open source portability is not free. The 90–95% portability claim comes with acknowledged effort and cost, and it assumes Kubernetes is available as the common substrate at the destination.
• Elite DORA performance has a counterweight. He names reliability as the competing force at high release frequency, which is why reliability and operational resilience appear as balancing KPIs in the board framework.
• Much of this depends on one leader's political access. Reframing a headcount cut as a compliance trade-off, or re-scripting another function's operational model, requires standing that a platform team may not have.

Practical Takeaways

• Maintain two dated reference architectures — current and roughly six months out — and treat the delta as your backlog.
• Write down team principles and mission, share them with HR, and put them in job descriptions so hiring reinforces the culture.
• Before shifting security left, invest in reducing findings to an actionable number and attach an owner and a deadline to each one. Ten items per team per 28 days is a concrete starting shape.
• Delete alerts that have no runbook. An alert without an actionable insight is noise you are paying for twice.
• Extend DORA with a financial metric such as cost per change, because it is the metric that brings the CFO and COO into the conversation.
• Use DORA diagnostically: drill into PRs to find causes such as late-stage pre-production failures caused by missing unit tests.
• Compare yourself with the industry, not only with your own past, so you know the size of your improvement.
• Create temporary, rotating cross-cutting working groups with explicit student/executor/consultant roles to spread stack knowledge without permanent silos.
• Create shielding roles — production manager, compliance officer, a single external-facing "ninja", and a tech desk that automates and documents — to protect the platform backlog.
• Map every board persona to a platform capability they already take for granted, so cost conversations become trade-off conversations.
• Insist on being in the room when the operational model is written, and make sure it covers versioning, API release, and service/API decoupling.
• Use tenant recreation or similar events as opportunities to rebuild rather than copy forward.
• Choose tooling with an exit path in mind, and state your sovereignty strategy as how fast and how expensively you could leave a hyperscaler.
• For AI work, require a numbers-based pitch owned by the business, and reject cases that are ordinary code or classical ML dressed up as GenAI.

Key Terms

• IDP (Internal Developer Platform) — a self-service platform aimed at developer experience; Petean argues it is a subset of platform engineering, not a synonym.
• DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service, plus reliability; used to classify delivery performance into clusters including elite.
• Cost per change unit — Petean's added financial DORA-style metric: total platform cost divided by number of changes delivered.
• Tekton — a Kubernetes-native CI/CD framework in which pipelines and tasks are Kubernetes custom resources.
• Prisma / Wiz — commercial cloud security posture and vulnerability scanning tools that generated the 50,000+ findings.
• Opsgenie — an alert and incident centralisation and on-call routing tool.
• SLO / SLA — a service level objective is an internal reliability target; a service level agreement is a contractual commitment, which in this case became a board-visible reputational risk.
• OrgSRE / OrgOps — Petean's name for a centre-of-excellence group of platform engineers who define SRE process and tooling for the whole organization rather than operating services themselves.
• TTL (Technical Tribe Lead) — a technical role embedded beside the business decision maker in a business tribe, with authority to prioritise technical work such as SLOs.
• DDO (Distributed DevOps) — a temporary, few-month cross-cutting working group covering one slice of the stack, with student, executor and consultant roles and mandatory rotation.
• Reverse Conway manoeuvre — restructuring teams to mirror the architecture you want, given that systems tend to mirror organizational communication structures.
• Innovation sovereignty — the organizational capacity to create rather than only consume technology, sustained by retaining and growing internal talent.
• Digital sovereignty — control over the digital platforms a society depends on, including the ability to migrate off a provider.
• FinOps — the practice of managing cloud cost; Petean argues architecture is its dominant lever.

Reference: From Legacy to Sovereignty: Driving the Future of Insurance through Platform Engineering