The Future of Hybrid Multi-Cloud

The Future of Hybrid Multi-Cloud

Aug 27, 2025 | Multi-Cloud, Sovereign Cloud

Most organizations today operate a mix of on-premises systems, private cloud platforms, and multiple public clouds. This is not always the result of an overall strategy, but often the consequence of acquisitions, project-specific decisions, or the practicalities of compliance and regulation.

The result is a landscape that is both full of choice and complexity.

Hybrid multi-cloud has become the de facto reality for some in IT. Enterprises already live in a world where applications and data are distributed across different infrastructures, each with its own tools, contracts, and governance models. What used to be a patchwork born out of necessity is now evolving into a deliberate strategy. Making use of the strengths of different environments while trying to tame the complexity they bring.

Why Hybrid Multi-Cloud Is Here to Stay

Several forces are driving this development. Regulations around data residency and sovereignty mean that some workloads must stay within national borders. Business-critical systems that are tightly integrated with legacy processes cannot simply be moved to the cloud overnight. At the same time, organizations want to tap into the rapid innovation of hyperscale platforms or make use of specialized services like AI or advanced analytics. And then there is the matter of resilience. Distributing workloads across different infrastructures helps reduce dependency on a single provider and lowers risk.

But hybrid multi-cloud is not a silver bullet. Managing multiple platforms comes with a cost. Operations teams need to juggle different interfaces, tools, and billing models. Cost transparency across environments is still a weak point. Finding experts who can handle everything from traditional infrastructure to cloud-native architectures is difficult. And perhaps most importantly, moving data across platforms and regions remains expensive and technically challenging.

A Pragmatic “Lift and Learn” Approach

One of the most common questions when discussing hybrid multi-cloud is how to actually get there. Large application portfolios can’t be transformed overnight, and ambitious modernization programs often collapse under their own weight. That’s why the “lift and learn” methodology is so compelling.

In essence, this approach unfolds in two focused phases:

Phase 1 – Lift and Shift
Begin by moving applications as-is. No re-architecture, no delay, no over-analysis. This speeds up cloud adoption and often compresses migration timelines to just a few months. The result? Systems are live in the cloud quickly, giving organizations both visibility and breathing room.

Phase 2 – Learn and Modernize
With the time savings from the first phase, IT teams gain the freedom to explore. They can understand native cloud services, build up needed skills, and gradually rethink how apps can be modernized. On their own schedule, without pressure.

In 2022, I explored this pattern in an article describing how VMware’s “lift and learn” approach gave teams crucial time to upskill and experiment before starting innovation. The lesson remains valid today. Successful cloud strategies respect both human capacity and technological ambition.

Nuanced Workload Placement

Cloud strategies are also maturing. What started as “cloud-first” enthusiasm has shifted toward more pragmatic “cloud-smart” models, and in some cases is now labeled “repatriation“. Surveys often highlight the trend of workloads moving back on-premises, but the reality is far more nuanced. This is not about retreating from the cloud, but about placing workloads more intelligently!

Repatriation is not reversal. You really have to understand this. Organizations are not abandoning cloud, they are rebalancing. Certain workloads, particularly steady-state, predictable, or data-heavy ones, may be more cost-effective or secure on-premises. This is nothing new. Others, such as experimental, elastic, or short-lived applications, remain ideal for public cloud. Some move to the edge or sovereign clouds to meet latency or compliance requirements.

What matters is building a framework for placement decisions. Cost, performance, data proximity, compliance, and strategic flexibility all play a role. Workloads need to live where they make the most sense and where they deliver the most value.

This is the natural evolution of hybrid multi-cloud and not a binary choice between “cloud or not”, but an ongoing, data-driven exercise in finding the right home for each workload.

Workload Mobility and Cloud-Exit Strategies

Hybrid multi-cloud is not only about placing workloads intelligently. It is also about being able to move them when circumstances change. This capability, often overlooked in early cloud journeys, is becoming critical as organizations experience new pressures and triggers that may force them to rethink their choices.

VMware Workload Mobility

Source: https://www.cloud13.ch/2024/08/05/distributed-hybrid-infrastructure-offerings-are-the-new-multi-cloud/ 

Why Workload Mobility Matters
In a world where business conditions, regulations, and technologies can change rapidly, no workload placement decision should be permanent. The ability to move applications and data across infrastructures, between clouds, or back to on-premises, is a strategic safeguard. It ensures that decisions made today do not become tomorrow’s limitations.

Exit Triggers – Why Organizations Rethink Placement
Several factors can trigger the need for a cloud-exit or relocation:

  • Costs: Cloud pricing models are attractive for elastic workloads but can spiral out of control for long-running, predictable systems. Unexpected egress fees or sudden price increases can make repatriation or rebalancing attractive. Keep in mind that price increases can also happen on-premises, as I have described it in the article “Sovereign Clouds and the VMware Earthquake: Dependency Isn’t Just a Hyperscaler Problem“

  • Regulatory and Sovereignty Requirements: New or changing laws may force workloads to be moved closer to home, into national clouds, or into sovereign environments under local control.

  • Access to Innovation: Sometimes the opposite is true. Workloads may need to leave legacy environments to take advantage of innovations in AI, analytics, or industry-specific platforms.

  • Strategic Flexibility: Businesses may want to avoid overdependence on one provider to maintain leverage and resilience. Also known as concentration risk.

Building Mobility into the Architecture
Workload mobility does not happen automatically. It requires foresight in architecture and governance:

  • Using containerization and orchestration platforms to abstract workloads from specific infrastructures

  • Follow a “consistent infrastructure, consistent operations” approach

  • Employing infrastructure-as-code and automation for repeatable deployments

  • Designing data strategies that minimize lock-in and enable portability

  • Establishing clear governance on when and how exit strategies should be executed

Mobility is not just about planning for the worst case. It is about creating long-term agility, so that organizations can move workloads toward opportunity as easily as they can move them away from risk.

Business Continuity and Cyber Recovery

Another dimension where hybrid multi-cloud demonstrates its value is business continuity and cyber resilience. Outages, ransomware attacks, or large-scale breaches are operational risks every CIO must plan for. In this context, having access to more than one cloud or infrastructure environment can make the difference between prolonged downtime and rapid recovery.

A Second Cloud as a Safety Net
Traditionally, disaster recovery was designed around secondary data centers. In a hybrid multi-cloud world, however, another cloud can serve as the recovery target. By replicating critical data and workloads into a separate cloud environment, organizations reduce their exposure to a single point of failure. If the primary environment is compromised, whether by technical outage or cyberattack, workloads can be restored in the alternate cloud, ensuring continuity of essential services.

Cyber Recovery and Forensics
Hybrid multi-cloud also opens up new options for cyber recovery. A secondary cloud can be isolated from day-to-day operations and act as a clean recovery environment. In case of a ransomware attack, for example, this environment becomes the trusted place to validate backups, perform integrity checks, and safely restore systems.

Source: https://www.cohesity.com/blogs/isolated-recovery-environments-the-next-thing-in-cyber-recovery/ 

It can also serve as a forensic sandbox, where compromised systems are analyzed without risking production operations.

Planning for the Unthinkable
The lesson here is clear. Hybrid multi-cloud is not only about optimization, innovation, or cost control. It is also about resilience in the face of growing threats. By designing continuity and recovery strategies that span across different providers, organizations build insurance against both natural outages and man-made disruptions.

Looking Ahead

The future will not remove this complexity, but it will change how we deal with it. We will see more organizations adopting a unified cloud operating model, where it no longer matters whether an application runs on-premises, in a private cloud, or in a public one. Abstraction and automation will take away much of the manual overhead, with AI-driven operations playing a key role. Infrastructure will become more decentralized, extending into regional clouds and edge locations. And with that, the focus will shift even further away from servers and workloads, toward outcomes and business value.

What Decision-Makers Should Keep in Mind

Hybrid multi-cloud is not about choosing the “best” cloud. It is about designing IT architectures that remain flexible in a constantly changing environment. Decision-makers should start from business outcomes, not infrastructure preferences. They should think about resilience, sovereignty, and innovation together – not in isolation. Skills and people remain the most critical success factor.

Technology can abstract a lot, but it cannot replace good governance and a strong IT culture.

Conclusion

Hybrid multi-cloud is an ongoing journey. Organizations that embrace flexibility, invest in skills, and build governance models that span across different environments will be best prepared. The future of IT is about mastering many clouds, without being mastered by them.

Swiss Government Cloud – Possible Paths, Components and Vendors Compared

Swiss Government Cloud – Possible Paths, Components and Vendors Compared

Aug 24, 2025 | AWS, Azure, Google Cloud, OCI Dedicated Region, Oracle Alloy, Oracle Cloud Infrastructure, Oracle Compute Cloud@Customer, Sovereign Cloud, VMware Cloud Foundation

Disclaimer: This article reflects my personal opinion and not that of my employer.

The discussion around a Swiss Government Cloud (SGC) has gained significant momentum in recent months. Digital sovereignty has become a political and technological necessity with immediate relevance. Government, politics, and industry are increasingly asking how a national cloud infrastructure could look. This debate is not just about technology, but also about governance, funding, and the ability to innovate.

Today’s starting point is relatively homogeneous. A significant portion of Switzerland’s public sector IT infrastructure still relies on VMware. This setup is stable but not designed for the future. When we talk about the Swiss Government Cloud, the real question is how this landscape evolves from pragmatic use of the public cloud to the creation of a fully sovereign cloud, operated under Swiss control.

For clarity: I use the word “component” (Stufe), in line with the Federal Council’s report, to describe the different maturity levels and deployment models.

A Note on the Federal Council’s Definition of Digital Sovereignty

According to the official report, digital sovereignty includes:

  • Data and information sovereignty: Full control over how data is collected, stored, processed, and shared.

  • Operational autonomy: The ability of the Federal Office of Information Technology (FOITT) to run systems with its own staff for extended periods, without external partners.

  • Jurisdiction and governance: Ensuring that Swiss law, not foreign regulation, defines control and access.

This definition is crucial when assessing whether a cloud model is “sovereign enough.”

Component 1 – Public Clouds Standard

The first component describes the use of the public cloud in its standard form. Data can be stored anywhere in the world, but not necessarily in Switzerland. Hyperscalers such as AWS, Microsoft Azure, or Oracle Cloud Infrastructure (OCI) offer virtually unlimited scalability, the highest pace of innovation, and a vast portfolio of services.

Amazon Web Services (AWS) is the broadest platform by far, providing access to an almost endless variety of services and already powering workloads from MeteoSwiss.

Microsoft Azure integrates deeply with Microsoft environments, making it especially attractive for administrations that are already heavily invested in Microsoft 365 and MS Teams. This ecosystem makes Azure a natural extension for many public sector IT landscapes.

Oracle Cloud Infrastructure (OCI), on the other hand, emphasizes efficiency and infrastructure, particularly for databases, and is often more transparent and predictable in terms of cost.

However, component 1 must be seen as an exception. For sovereign and compliant workloads, there is little reason to rely on a global public cloud without local residency or control. This component should not play a meaningful role, except in cases of experimental or non-critical workloads.

And if there really is a need for workloads to run outside of Switzerland, I would recommend using alternatives like the Oracle EU Sovereign Cloud instead of a regular public region, as it offers stricter compliance, governance, and isolation for European customers.

Component 2a – Public Clouds+

Here, hyperscalers offer public clouds with Swiss data residency, combined with additional technical restrictions to improve sovereignty and governance.

AWS, Azure, and Oracle already operate cloud regions in Switzerland today. They promise that data will not leave the country, often combined with features such as tenant isolation or extra encryption layers.

The advantage is clear. Administrations can leverage hyperscaler innovation while meeting legal requirements for data residency.

Component 2b – Public Cloud Stretched Into FOITT Data Centers

This component goes a step further. Here, the public cloud is stretched directly into the local data centers. In practice, this means solutions like AWS Outposts, Azure Local (formerly Azure Stack), Oracle Exadata & Compute Cloud@Customer (C3), or Google Distributed Cloud deploy their infrastructure physically inside FOITT facilities.

Diagram showing an Outpost deployed in a customer data center and connected back to its anchor AZ and parent Region

This creates a hybrid cloud. APIs and management remain identical to the public cloud, while data is hosted directly by the Swiss government. For critical systems that need cloud benefits but under strict sovereignty (which differs between solutions), this is an attractive compromise.

The vendors differ significantly:

Costs and operations are predictable since most of these models are subscription-based.

Component 3 – Federally Owned Private Cloud Standard

Not every path to the Swiss Government Cloud requires a leap into hyperscalers. In many cases, continuing with VMware (Broadcom) represents the least disruptive option, providing the fastest and lowest-risk migration route. It lets institutions build on existing infrastructure and leverage known tools and expertise.

Still, the cloud dependency challenge isn’t exclusive to hyperscalers. Relying solely on VMware also creates a dependency. Whether with VMware or a hyperscaler, dependency remains dependency and requires careful planning.

Another option is Nutanix, which offers a modern hybrid multi-cloud solution with its AHV hypervisor. However, migrating from VMware to AHV is in practice as complex as moving to another public cloud. You need to replatform, retrain staff, and become experts again.

Hybrid Cloud Management diagram

Both VMware and Nutanix offer valid hybrid strategies:

  • VMware: Minimal disruption, continuity, familiarity, low migration risk. Can run VMware Cloud Foundation (VCF) on AWS, Azure, Google Cloud and OCI.

  • Nutanix: Flexibility and hybrid multi-cloud potential, but migration is similar to changing cloud providers.

Crucially, changing platforms or introducing a new cloud is harder than it looks. Organizations are built around years of tailored tooling, integrations, automation, security frameworks, governance policies, and operational familiarity. Adding or replacing another cloud often multiplies complexity rather than reduces it.

Gartner Magic Quadrant for_Distributed_Hybrid_Infrastructure

Source: https://www.oracle.com/uk/cloud/distributed-cloud/gartner-leadership-report/ 

But sometimes it is just about costs, new requirements, or new partnerships, which result in a big platform change. Let’s see how the Leaders Magic Quadrant for “Distributed Hybrid Infrastructure” changes in the coming weeks or months.

Why Not Host A “Private Public Cloud” To Combine Components 2 and 3?

This possibility (let’s call with component 3.5) goes beyond the traditional framework of the Federal Council. In my view, a “private public cloud” represents the convergence of public cloud innovation with private cloud sovereignty.

“The hardware needed to build on-premises solutions should therefore be obtained through a ‘pay as you use’ model rather than purchased. A strong increase in data volumes is expected across all components.”

Source: https://www.fedlex.admin.ch/eli/fga/2024/1408/de#lvl_2/lvl_2.4 (translated from German)

Solutions like OCI Dedicated Region or Oracle Alloy can deliver the entire Oracle Cloud stack– IaaS, PaaS, databases, analytics – on Swiss soil. Unlike AWS Outposts, Azure Local, these solutions are not coming with a limited set of cloud services, but are identical to a full public cloud region with all cloud services, only hosted and operated locally in a customer’s data center.

OCI Dedicated Region Overview

Additionally, Oracle offers a compelling hybrid path. With OCVS (Oracle Cloud VMware Solution) on OCI Dedicated Region or Alloy, organizations can lift-and-shift VMware workloads unchanged to this local public cloud based on Oracle Cloud Infrastructure, then gradually modernize selected applications using Oracle’s PaaS services like databases, analytics, or AI.

OCI Dedicated Region and OCVS

This “lift-and-modernize” journey helps balance risk and innovation while ensuring continuous operational stability.

And this makes component 3.5 unique. It provides the same public-cloud experience (continuous updates, innovation pace; 300-500 changes per day, 10’000-15’000 per month) but under sovereign control. With Alloy, the FOITT could even act as a Cloud Service Provider for cantons, municipalities, and hospitals, creating a federated model without each canton building its own cloud.

Real-world Swiss example: Avaloq was the first customer in Switzerland to deploy an OCI Dedicated Region, enabling it to migrate clients and offer cloud services to other banks in Switzerland. This shows how a private public cloud can serve highly regulated industries while keeping data and operations in-country.

In this model:

  • Component 2b becomes redundant: Why stretch a public cloud into FOITT data centers if a full cloud can already run there?

  • Component 2 can also be partly obsolete: At least for workloads running a local OCI Dedicated Region (or Alloy) deployment, there’s no need for parallel deployments in public regions, since everything can run sovereignly on a local dedicated OCI region in Switzerland (while workloads from MeteoSwiss on AWS remain in component 2).

A private public cloud thus merges sovereignty with innovation while reducing the need for parallel cloud deployments.

Another Possibility – Combine Capabilities From A Private Public Cloud With Component 2b

Another possibility could be to combine elements of components 3.5 and 2b into a federated architecture: Using OCI Dedicated Region or Oracle Alloy as the central control plane in Switzerland, while extending the ecosystem with Oracle Compute Cloud@Customer (C3) for satellite or edge use cases.

Oracle Compute Cloud@Customer – Wichtige Funktionen

This creates a hub-and-spoke model:

  • The Dedicated Region or Alloy in Switzerland acts as the sovereign hub for governance and innovation.

  • C3 appliances extend cloud services into distributed or remote locations, tightly integrated but optimized for local autonomy.

A practical example would be Swiss embassies around the world. Each embassy could host a lightweight C3 edge environment, connected securely back to the central sovereign infrastructure in Switzerland. This ensures local applications run reliably, even with intermittent connectivity, while remaining part of the overall sovereign cloud ecosystem.

By combining these capabilities, the FOITT could:

  • Use component 2b’s distributed deployment model (cloud stretched into local facilities)

  • Leverage component 3.5’s VMware continuity path with OCVS for easy migrations

  • Rely on component 3.5’s sovereignty and innovation model (private public cloud with full cloud parity)

This blended approach would allow Switzerland to centralize sovereignty while extending it globally to wherever Swiss institutions operate.

What If A Private Public Cloud Isn’t Sovereign Enough?

It is possible that policymakers or regulators could conclude that solutions such as OCI Dedicated Region or Oracle Alloy are not “sovereign enough”, given that their operational model still involves vendor-managed updates and tier-2/3 support from Oracle.

In such a scenario, the BIT would have fallback options:

Maintain a reduced local VMware footprint: BIT could continue to run a smaller, fully local VMware infrastructure that is managed entirely by Swiss staff. This would not deliver the breadth of services or pace of innovation of a hyperscale-based sovereign model, but it would provide the maximum possible operational autonomy and align closely with Switzerland’s definition of sovereignty.

Leverage component 4 from the FDJP: Using the existing “Secure Private Cloud” (SPC) from the Federal Department of Justice and Police (FDJP). But I am not sure if the FDJP wants to become a cloud service provider for other departments.

That said, these fallback strategies don’t necessarily exclude the use of OCI. Dedicated Region or Alloy could co-exist with a smaller VMware footprint, giving the FOITT both innovation and control. Alternatively, Oracle could adapt its operating model to meet Swiss sovereignty requirements – for example, by transferring more operational responsibility (tier-2 support) to certified Swiss staff.

This highlights the core dilemma: The closer Switzerland moves to pure operational sovereignty, the more it risks losing access to the innovation and agility that modern cloud architectures bring. Conversely, models like Dedicated Region or Alloy can deliver a full public cloud experience on Swiss soil, but they require acceptance that some operational layers remain tied to the vendor.

Ultimately, the Swiss Government Cloud must strike a balance between autonomy and innovation, and the decision about what “sovereign enough” means will shape the entire strategy.

Conclusion

The Swiss Government Cloud will not be a matter of choosing one single path. A hybrid approach is realistic: Public cloud for agility and non-critical workloads, stretched models for sensitive workloads, VMware or Nutanix for hybrid continuity, sovereign or “private public cloud” infrastructures for maximum control, and federated extensions for edge cases.

But it is important to be clear: Hybrid cloud or even hybrid multi-cloud does not automatically mean sovereign. What it really means is that a sovereign cloud must co-exist with other clouds – public or private.

To make this work, Switzerland (and each organization within it) must clearly define what sovereignty means in practice. Is it about data and information sovereignty? Is it really about operational autonomy? Or about jurisdiction and governance?

Only with such a definition can a sovereign cloud strategy deliver on its promise, especially when it comes to on-premises infrastructure, where control, operations, and responsibilities need to be crystal clear.

PS: Of course, the SGC is about much more than infrastructure. The Federal Council’s plan also touches networking, cybersecurity, automation and operations, commercial models, as well as training, consulting, and governance. In this article, I deliberately zoomed in on the infrastructure side, because it’s already big, complex, and critical enough to deserve its own discussion. And just imagine sitting on the other side, having to go through all the answers of the upcoming tender. Not an easy task.

Why Changing Platforms or Adding a New Cloud Is Harder Than It Sounds

Why Changing Platforms or Adding a New Cloud Is Harder Than It Sounds

Aug 15, 2025 | OCI Dedicated Region, Oracle Cloud Infrastructure, Sovereign Cloud, VMware Cloud Foundation

Switching enterprise platforms isn’t like swapping cars and more like deciding to change the side of the road you drive on while keeping all the existing roads, intersections, traffic lights, and vehicles in motion. The complexity comes from rethinking the entire system around you, from driver behaviour to road markings to the way the city is mapped.

That’s exactly what it feels like when an enterprise tries to replace a long-standing platform or add a new one to an already complex mix. On slides, it’s about agility, portability, and choice. In reality, it’s about untangling years of architectural decisions, retraining teams who have mastered the old way of working, and keeping the business running without any trouble while the shift happens.

Every enterprise carries its own technological history. Architectures have been shaped over years by the tools, budgets, and priorities available at the time, and those choices have solidified into layers of integrations, automations, operational processes, and compliance frameworks. Introducing a new platform or replacing an old one isn’t just a matter of deploying fresh infrastructure. Monitoring tools may only talk to one API. Security controls might be tightly bound to a specific identity model. Ticketing workflows could be designed entirely around the behaviour of the current environment. All of this has to be unpicked and re-stitched before a new platform can run production workloads with confidence.

The human element plays an equally large role. Operational familiarity is one of the most underestimated forms of lock-in. Teams know the details of the current environment, how it fails, and the instinctive fixes that work. Those instincts don’t transfer overnight, and the resulting learning curve can look like a productivity dip in the short term. Something most business leaders are reluctant to accept. Applications also rarely run in isolation. They rely on the timing, latency, and behaviours of the platform beneath them. A database tuned perfectly in one environment might misbehave in another because caching works differently or network latency is just a little higher. Automation scripts often carry hidden assumptions too, which only surface when they break.

Adding another cloud provider or platform to the mix can multiply complexity rather than reduce it. Each one brings its own operational model, cost reporting, security framework, and logging format. Without a unified governance approach, you risk fragmentation – silos that require separate processes, tools, and people to manage. And while the headline price per CPU or GB (or per physical core) might look attractive, the true cost includes migration effort, retraining, parallel operations, and licensing changes. All of this competes with other strategic projects for budget and attention.

Making Change Work in Practice

No migration is ever frictionless, but it doesn’t have to be chaotic. The most effective approach is to stop treating it as a single, monolithic event. Break the journey into smaller stages, each delivering its own value.

Begin with workloads that are low in business risk but high in operational impact. This category often includes development and test environments, analytics platforms processing non-sensitive data, or departmental applications that are important locally but not mission-critical for the entire enterprise. Migrating these first provides a safe but meaningful proving ground. It allows teams to validate network designs, security controls, and operational processes in the new platform without jeopardising critical systems.

Early wins in this phase build confidence, uncover integration challenges while the stakes are lower, and give leadership tangible evidence that the migration strategy is working. They also provide a baseline for performance, cost, and governance that can be refined before larger workloads move.

Build automation, governance, and security policies to be platform-agnostic from the start, using open standards, modular designs, and tooling that works across multiple environments. And invest early in people: cross-train them, create internal champions, and give them the opportunity to experiment without the pressure of immediate production deadlines. If the new environment is already familiar by the time it goes live, adoption will feel less like a disruption and more like a natural progression.

From Complex Private Clouds to a Unified Platform

Consider an enterprise running four separate private clouds: three based on VMware – two with vSphere Foundation and one with VMware Cloud Foundation including vSphere Kubernetes Services (VKS), and one running Red Hat OpenShift on bare metal. Each has its own tooling, integrations, and operational culture.

Migrating the VMware workloads to Oracle Cloud VMware Solution (OCVS) inside an OCI Dedicated Region allows workloads to be moved with vMotion or replication, without rewriting automation or retraining administrators. It’s essentially another vSphere cluster, but one that scales on demand and is hosted in facilities under your control.

OCI Dedicated Region and OCVS

The OpenShift platform can also move into the same Dedicated Region, either as a direct lift-and-shift onto OCI bare metal or VMs, or as part of a gradual transition toward OCI’s native Kubernetes service (OKE). This co-location enables VMware, OpenShift, and OCI-native workloads to run side by side, within the same security perimeter, governance model, and high-speed network. It reduces fragmentation, simplifies scaling, and allows modernisation to happen gradually instead of in a high-risk “big bang” migration.

Unifying Database Platforms

In most large enterprises, databases are distributed across multiple platforms and technologies. Some are Oracle, some are open source like PostgreSQL or MySQL, and others might be Microsoft SQL Server. Each comes with its own licensing, tooling, and operational characteristics.

An OCI Dedicated Region can consolidate all of them. Oracle databases can move to Exadata Database Service or Autonomous Database for maximum performance, scalability, and automation. Non-Oracle databases can run on OCI Compute or as managed services, benefitting from the same network, security, and governance as everything else.

This consolidation creates operational consistency with one backup strategy, one monitoring approach, one identity model across all database engines. It reduces hardware sprawl, improves utilisation, and can lower costs through programmes like Oracle Support Rewards. Just as importantly, it positions the organisation for gradual application modernization, without being forced into rushed timelines.

A Business Case Built on More Than Cost

The value in this approach comes from the ability to run new workloads, whether VM-based, containerized, or fully cloud-native, on the same infrastructure without waiting for new procurement cycles. It’s about strategic control by keeping infrastructure and data within your own facilities, under your jurisdiction, while still accessing the full capabilities of a hyperscale cloud. And it’s about flexibility. Moving VMware first, then OpenShift, then databases, and modernizing over time, with each step delivering value and building confidence for the next.

When done well, this isn’t just a platform change. It’s a simplification of the entire environment, an upgrade in capabilities, and a long-term investment in agility and control.

Swiss Government Cloud – Was macht der Cloud Service Broker und wie neutral ist er wirklich?

Swiss Government Cloud – Was macht der Cloud Service Broker und wie neutral ist er wirklich?

Aug 15, 2025 | Sovereign Cloud

Hinweis: Dieser Beitrag spiegelt ausschliesslich meine persönliche Meinung und Einschätzung wider. Er basiert auf öffentlich zugänglichen Informationen sowie eigenen Analysen und Erfahrungen. Er stellt nicht die offizielle Position oder Meinung meines Arbeitgebers dar.

Früher war die interne IT beim Bund die Abteilung, die Server bestellte, installierte und betrieb. Heute ist sie Orchestrator eines hochdynamischen Ökosystems aus internen Plattformen und externen Cloud-Diensten. Private Clouds in Bundesrechenzentren, Public Clouds bei internationalen Anbietern und all das unter strengen Vorgaben für Sicherheit, Datenschutz und Souveränität.

Hinzu kommt, dass das Bundesamt für Informatik und Telekommunikation (BIT) nicht über die nötige Erfahrung und Anzahl festangestellter Spezialisten verfügt, um alle Themen wie etwa Applikationsmodernisierung oder komplexe Cloud-Migrationen eigenständig umzusetzen. Deshalb sind in vielen Bereichen externe Partner tätig, sei es in Body-Leasing-Verträgen oder als Berater in längerfristigen Mandaten. Diese Partner bringen wertvolle Expertise ein, nehmen aber zwangsläufig auch Einfluss auf die strategische Ausrichtung, die Technologieauswahl und die operativen Entscheidungen.

Das kann helfen, weil Erfahrungen aus anderen Projekten einfliessen, birgt aber auch das Risiko, dass bestimmte Präferenzen oder Lösungsansätze bevorzugt werden, noch bevor ein formaler Evaluationsprozess startet.

Die Rolle des Cloud Service Brokers

Der Bezug von Public-Cloud-Leistungen durch die Verwaltungseinheiten der Bundesverwaltung erfolgt heute über einen Cloud Service Broker (CSB). Dieser CSB ist aktuell nur für die Public-Cloud-Seite zuständig. Sobald jedoch die Swiss Government Cloud (SGC) steht, wäre es aus meiner Sicht logisch und notwendig, dass der CSB auch die Private Cloud miteinbezieht. Denn nur so kann im Rahmen der Ausschreibungen und Pflichtenhefte korrekt bewertet werden, ob ein Projekt on-premises in der Private Cloud oder in einer Public Cloud umgesetzt werden sollte. Anstatt nur innerhalb eines einzelnen Betriebsmodells zu entscheiden.

Cloud Governance_de

Quelle: https://www.bk.admin.ch/bk/de/home/digitale-transformation-ikt-lenkung/bundesarchitektur/cloud/public-clouds-bund.html 

Ein vendor-agnostischer Blick ist dabei essenziell. Es gibt bereits Plattformlösungen am Markt, die alle Stufen des Cloud-Stufenmodells, von hochsensiblen Private-Cloud-Umgebungen bis hin zu skalierbaren Public-Cloud-Regionen, innerhalb einer einheitlichen Architektur abbilden könnten. In solchen Szenarien würde das komplexe Stufenmodell der Bundesverwaltung in seiner heutigen Form weitgehend obsolet werden. Eine private (eigene, dedizierte) Public-Cloud-Region liesse sich dann direkt in den Rechenzentren des BIT betreiben, ohne Abstriche bei Souveränität oder Sicherheitsanforderungen machen zu müssen.

Vendor-Neutralität – Anspruch und Wirklichkeit

Das Konzept eines anbieterneutralen Pflichtenhefts soll sicherstellen, dass alle potenziellen Anbieter gleich behandelt werden. Im Kriterienkatalog dazu werden technische Anforderungen (Ausschlusskriterien) wie Compute, Identity und Access Management, Messaging, Resilienz, Sicherheit, Storage und DevOps definiert. Ergänzt wird dies um Zuschlagskriterien etwa zu Monitoring, Networking, Cloud-Strategie oder Migrationskosten.

Zur Erinnerung, heute sind folgende Public-Cloud-Anbieter beim Bund zugelassen:

Bund Public Cloud Gartner MQ Aug2025

Die Praxis sieht so aus: Basierend auf dem freigegebenen, signierten anbieterneutralen Pflichtenheft und dem Kriterienkatalog erstellt ein Angebotsteam für alle fünf zugelassenen Public-Cloud-Anbieter eine Konfiguration und füllt den Kriterienkatalog aus. Kann ein Anbieter ein Ausschlusskriterium nicht erfüllen, wird dies dokumentiert. Am Ende der Evaluation liegen maximal fünf dem Pflichtenheft entsprechende Angebote vor. Der Evaluationsbericht bewertet diese Angebote und begründet die Auswahl.

Kritisch wird es, wenn in der Realität trotz anbieterneutralem Verfahren am Ende doch immer dieselben zwei Cloudanbieter den Zuschlag erhalten, selbst dann, wenn ein anderer Anbieter 50% günstiger gewesen wäre. Das wirkt umso paradoxer in einer Zeit, in der viele Diskussionen über steigende Public-Cloud-Kosten geführt werden und Public Clouds oft als “zu teuer” erachtet werden.

Der Einfluss externer Partner

Externe Partner sind ein wichtiger Teil der Bundes-IT, ganz klar. Sie bringen tiefes Fachwissen und Erfahrung aus vergleichbaren Projekten mit, haben aber auch eigene Partnernetzwerke und oft eine technologische “Konfortzone”. Das ist nicht zwingend schlecht, kann aber in einem angeblich anbieterneutralen Verfahren zu einer leicht versteckten Bevorzugung führen, etwa, wenn dieselben Firmen/Partnernetzwerke an der Erstellung des Pflichtenhefts, der Evaluation und der Umsetzung beteiligt sind.

Besonders kritisch ist es, wenn Partner, die ein Projekt beim Bund erfolgreich umgesetzt haben, diese Referenz aktiv nutzen, um bei anderen Ämtern oder Bedarfsträgern Fuss zu fassen. So kann sich ein Anbieter oder eine Technologie im Bund durchsetzen. Nicht, weil sie immer die objektiv beste Wahl ist, sondern weil sie bereits etabliert ist. Wenn ein Cloud Service Broker externe Partner in zentrale Rollen einbindet, muss dies transparent erfolgen und durch klare Regeln abgesichert sein, inklusive Offenlegung potenzieller Interessenkonflikte.

Fazit

Ein Cloud Service Broker ist ein mächtiges Instrument, um die Cloud-Nutzung beim Bund zu steuern und im Idealfall neutral, transparent und im Interesse des Ganzen. Damit das gelingt, muss der CSB künftig auch die Private Cloud in seine Bewertung einbeziehen, Plattformlösungen berücksichtigen, die alle Stufen abdecken können, und externe Einflüsse klar benennen.

Die Swiss Government Cloud wird nur dann zu einem echten Erfolg, wenn Auswahlentscheidungen nachvollziehbar sind, alle relevanten Betriebsmodelle fair geprüft werden. Dazu gehört auch, dass nicht nur kurzfristige technische Kriterien zählen, sondern ebenso langfristige Kostenentwicklungen, strategische Unabhängigkeit und die Fähigkeit, künftige Technologien flexibel einzubinden.

Gerade in einem Umfeld, in dem viele externe Partner mitarbeiten und bestehende Erfahrungen oder Präferenzen unweigerlich Einfluss nehmen, braucht es klare Leitplanken, um echte Wahlfreiheit zu sichern. Das bedeutet nämlich Transparenz im gesamten Prozess, konsequente Anwendung der eigenen Kriterienkataloge und den Mut, auch einmal gegen Gewohnheiten zu entscheiden, wenn es im Gesamtinteresse sinnvoll ist.

Nur wenn der Auswahlprozess tatsächlich offen ist und nicht von Präferenzen, Gewohnheiten oder bestehenden Anbieterbindungen geprägt wird, kann die Swiss Government Cloud ihr Potenzial entfalten.

Als echte, souveräne und innovative Plattform für die Verwaltung.

Die versteckte Innovationsbremse in der Bundes-IT

Die versteckte Innovationsbremse in der Bundes-IT

Aug 14, 2025 | Sovereign Cloud

Hinweis: Dieser Beitrag spiegelt ausschliesslich meine persönliche Meinung und Einschätzung wider. Er basiert auf öffentlich zugänglichen Informationen sowie eigenen Analysen und Erfahrungen. Er stellt nicht die offizielle Position oder Meinung meines Arbeitgebers dar.

In meinem ersten Artikel habe ich die Gefahr aufgezeigt, dass die Swiss Government Cloud (SGC) am Ende nur eine 1:1-Kopie der heutigen Plattform sein könnte. Technisch neu, aber schon alt, bevor wir überhaupt mit der Modernisierung beginnen. Im zweiten Artikel habe ich das Cloud-Konzentrationsrisiko beim Bund thematisiert und gefragt, ob wir wirklich Vielfalt haben oder nur eine Scheinvielfalt, die in der Praxis wenig Mehrwert bringt.

Nun geht es um eine dritte, mindestens ebenso entscheidende Dimension. Was passiert, wenn wir während der Migration nicht modernisieren?

Auf der Grundlage der Gesamtbetriebskostenrechnung des BIT vom September 2023 und Erfahrungen aus schon durchgeführten Lifecycle-Vorhaben, die ebenfalls eine Plattformmigration beinhalteten, hat das BIT einen Migrationskostenfaktor kalkuliert. Dieser beläuft sich auf 35 Prozent der jährlichen Betriebskosten. Systeme und Anwendungen, die aktuell noch nicht in einer der Cloud-Plattformen des BIT betrieben werden (sogenannte Legacy-Systeme), sind in der Schätzung der Migrationskosten nicht enthalten. Es liegt in der Verantwortung der Leistungsbezüger, die Modernisierung dieser Lösungen einzuplanen und zu beauftragen. Die Ablösung der Legacy-Systeme birgt weiteres Sparpotenzial. Das Thema wird daher im Digitalisierungsrat Bund parallel zur SGC prioritär angegangen.

Gesamthaft entstehen demnach Migrationskosten in der Höhe von 74 Millionen Franken. Es wird von einer Schätzgenauigkeit von ±20 Prozent ausgegangen. Diese schwankende Kostenschätzung ist auf den langen Planungshorizont zurückzuführen: Zwischen dem Zeitpunkt der Schätzung (Ende 2023) und dem Zeitpunkt der Migration (ab 2027) werden sich sowohl die Technologielandschaft auf dem Markt als auch die Anwendungslandschaft der Leistungsbezüger weiterentwickeln. Aufgrund der ausstehenden Beschaffung ist zudem auch die Zielplattform der Migration unbekannt. Eine genaue Schätzung der Migrationskosten ist daher zum jetzigen Zeitpunkt nicht möglich. Es besteht daher das Risiko, dass die effektiven Aufwände für die Migration höher ausfallen als geschätzt.

Quelle: https://www.fedlex.admin.ch/eli/fga/2024/1408/de#lvl_3/lvl_3.1/lvl_3.1.3 

Für mich ist die Antwort klar: wir bauen uns zwar eine souveräne Cloud, nehmen aber die gesamten technischen Altlasten (Technical Debt) einfach mit. Und das könnte langfristig die Innovationsfähigkeit des Bundes stärker bremsen als jedes Konzentrationsrisiko, welches ich im zweiten Teil näher erklärt habe.

Die Logik hinter “erst migrieren, dann modernisieren”

In grossen Behördenprojekten ist diese Reihenfolge Standard. Erst wird die neue Plattform aufgebaut, dann werden bestehende Anwendungen per Lift & Shift migriert, und erst danach denkt man über Modernisierung nach. Aus Sicht von Projektleitern und Politik klingt das nachvollziehbar. Die Stabilität geht vor, Risiken sollen minimiert werden, und der Zeitplan soll beherrschbar bleiben.

Bezüglich der geschätzten Programmausgaben und Migrationskosten wurde bestätigt, dass die Schätzung der Programmausgaben schlüssig und nachvollziehbar und die Schätzung der Migrationsaufwände im Rahmen der verfügbaren Daten fundiert und adäquat ist.

Quelle: https://www.fedlex.admin.ch/eli/fga/2024/1408/de#lvl_3/lvl_3.1/lvl_3.1.4 

Das Problem ist nur, dass IT-Anwendungen nicht wie Möbel sind, die man einfach in ein neues Haus stellt. Sie altern auch während des Umzugs weiter. Sicherheitslücken entstehen, Technologien werden obsolet, und moderne Funktionen der neuen Plattform bleiben ungenutzt. Am Ende haben wir zwar den physischen Ort gewechselt, aber an der Substanz der Anwendungen nichts verändert und damit die eigentlichen Probleme nicht gelöst.

Die Kosten von Technical Debt in souveränen Umgebungen

Technical Debt bedeutet, dass man technische Altlasten weiterträgt und damit einen Preis in der Zukunft zahlt, meist in Form von höheren Kosten, höherem Risiko und verpassten Chancen. In einer souveränen Cloud wie der SGC kann sich das besonders stark auswirken. Wenn Fachapplikationen erst in eine Private Cloud migriert und später z.B. ein zweites Mal in eine Public Cloud verschoben werden müssen, entstehen unnötige Mehrfachmigrationen. Gleichzeitig bleiben Möglichkeiten wie Automatisierung, Self-Service oder KI-Integration ungenutzt, weil die Anwendungen nicht dafür vorbereitet sind.

Auch wirtschaftlich ist das ein Problem. Legacy-Anwendungen verbrauchen mehr Ressourcen, sind schwerer zu warten und erfordern oft spezielle Skills, die teuer und rar sind. Sicherheitsrisiken verschärfen die Lage zusätzlich, da alte Systeme sich nur schwer auf den neuesten Stand bringen lassen.

Warum “Modernisierung während Migration” auch beim Bund möglich wäre

Es muss nicht zwingend heissen: erst migrieren, dann modernisieren. Ein paralleler Ansatz ist machbar, auch in einem hochregulierten Umfeld wie dem Bund. Applikationen können in Wellen migriert und direkt modernisiert werden. Bei einem Replatforming können moderne Plattformdienste (PaaS) schon während der Migration genutzt werden, um Funktionen wie elastische Skalierung, automatisierte Sicherheitspatches oder integrierte Datenanalyse sofort verfügbar zu machen.

Der Vorteil ist offensichtlich: Die technischen Schulden werden nicht einfach mitgenommen, sondern Schritt für Schritt abgebaut. Die Verwaltung und die Bürger:innen profitieren schneller von einer besseren Performance, mehr Funktionalität und einem moderneren Nutzererlebnis.

Die Rolle der Partnerlandschaft

Externe Partner, ob Systemintegratoren, Cloudanbieter oder spezialisierte Softwarehäuser, haben einen grossen Einfluss darauf, ob Modernisierung tatsächlich stattfindet. Das Beispiel von MeteoSchweiz zeigt, dass es auch anders geht. In der Ausschreibung zur Erneuerung der Rechenzentrums- und Cloudinfrastruktur war Modernisierung von Anfang an Teil der Zielsetzung. Die ausgewählten Partner konnten zeigen, dass sie nicht nur migrieren, sondern auch optimieren und teilweise ersetzen können.

Solche Projekte setzen Massstäbe und beeinflussen, wie andere Bundesämter ihre eigenen Strategien gestalten. Doch hier liegt auch ein Risiko: Wenn Partner, die in einem Amt einen erfolgreichen Lift & Shift durchgeführt haben, ohne Modernisierung beauftragt werden, multipliziert sich genau dieser Ansatz in weiteren Projekten und die Chance, echte Innovation einzuführen, schwindet.

Handlungsempfehlung

Damit die Swiss Government Cloud mehr als nur ein neues Zuhause für alte Anwendungen wird, braucht es verbindliche Ziele. Eine definierte Modernisierungsquote pro Migrationswelle könnte helfen. Migrations- und Modernisierungsplan sollten von Beginn an miteinander verknüpft sein. Und es sollte transparent gemacht werden, welche technischen Altlasten bewusst übernommen werden. Nur so lässt sich später nachvollziehen, ob man den richtigen Weg gewählt hat.

Genauso wichtig ist es, erfolgreiche Modernisierungsprojekte aktiv zu kommunizieren und als Vorbild zu nutzen. Sie zeigen, dass es auch unter den Rahmenbedingungen des Bundes möglich ist, Migration und Innovation gleichzeitig umzusetzen.

Gerne bin ich für ein Gespräch verfügbar, um zu zeigen, dass:

  • man die bisher “verlorene” Zeit wieder aufholen kann
  • man das Stufenmodell vereinfachen bzw. abschaffen und kombinieren kann mit nur einer Plattform (inkl. Hosting von VMware und OpenShift Workloads, Konsolidierung von Datenbanken und Reduktion der Betriebskosten)
  • man trotzdem schon modernisieren kann während der Migrations- und Betriebphase (Entlastung vom Betriebsteam, damit mehr Zeit zum Modernisieren zur Verfügung steht)
  • man Geld sparen kann mit einem neuen Plattformansatz (inkl. Zugang zu den neuesten Technologien)

Gedanke: Ich hoffe, dass wenigstens in der Ausschreibung das Thema “Künstliche Intelligenz” (aus Sicht Infrastruktur) bisschen populärer behandelt wird.

Fazit – Souveränität ohne Innovation ist nur die halbe Miete

Die Swiss Government Cloud wird zweifellos ein Meilenstein. Aber wenn wir sie nur nutzen, um bestehende Systeme unverändert zu verschieben, dann schaffen wir kein Fundament für die nächsten Jahrzehnte, sondern nur ein neues Parkhaus für alte Fahrzeuge. Wer sagt “wir modernisieren später”, muss sich bewusst sein, dass später oft teurer, riskanter und manchmal gar nicht mehr möglich ist.

Man muss den Mut haben, nicht nur das Alte ins Neue zu stellen, sondern es gleich besser zu machen.

Cloud-Konzentrationsrisiko beim Bund – Vielfalt oder nur Scheinvielfalt?

Cloud-Konzentrationsrisiko beim Bund – Vielfalt oder nur Scheinvielfalt?

Aug 13, 2025 | Sovereign Cloud

Hinweis: Dieser Beitrag spiegelt ausschliesslich meine persönliche Meinung und Einschätzung wider. Er basiert auf öffentlich zugänglichen Informationen sowie eigenen Analysen und Erfahrungen. Er stellt nicht die offizielle Position oder Meinung meines Arbeitgebers dar.

In meinem vorherigen Artikel zur Swiss Government Cloud (SGC) habe ich beleuchtet, welche Risiken entstehen, wenn man während der Migration alter Anwendungen zu lange mit der eigentlichen Modernisierung wartet. Heute möchte ich auf einen anderen, eng damit verbundenen Aspekt eingehen: die Frage, ob die beim Bund offiziell propagierte Vielfalt an Cloudanbietern in der Praxis tatsächlich existiert oder ob wir es am Ende nur mit einer Scheinvielfalt zu tun haben.

Vielfalt in der Theorie und die Vorgaben von WTO20007

Seit der Ausschreibung WTO20007 hat die Bundesverwaltung formal Zugriff auf die Public-Cloud-Leistungen von fünf grossen Anbietern: Amazon Web Services, Microsoft Azure, Oracle, IBM und Alibaba Cloud. Ergänzt wird das durch die Private-Cloud-Infrastruktur des BIT, die primär auf VMware-Technologien basiert.

Die Theorie klingt ideal: Leistungsbezüger sollen aus einem breiten Spektrum von Cloudanbietern auswählen können, um für jede Anwendung die beste Plattform zu finden. Dafür existiert ein definierter Abrufprozess, der mit einem anbieterneutralen Pflichtenheft beginnt.

Dieses Pflichtenheft beschreibt die funktionalen, technischen und sicherheitsrelevanten Anforderungen der geplanten Anwendung. Dazu gehört ein Kriterienkatalog, der vorgibt, wie die Anbieterangebote bewertet werden. Basierend darauf erstellt ein Angebotsteam für alle fünf Public-Cloud-Anbieter passende Konfigurationen unter Verwendung der Preisinformationen für die jeweils gültige Region.

WTO20007 Abrufverfahren

Quelle: https://www.bk.admin.ch/dam/bk/de/dokumente/dti/themen/cloud/abrufverfahren-public-clouds-bund-wto-20007-v1.0.pdf.download.pdf/Abrufverfahren%20Public%20Clouds%20Bund%20(WTO%2020007)%20V1.0.pdf 

Falls ein Anbieter ein oder mehrere Ausschlusskriterien nicht erfüllt, wird dies dokumentiert. Am Ende liegen maximal fünf Konfigurationen vor, die im Evaluationsbericht objektiv miteinander verglichen werden. Ja, ganz nach den Regeln des Pflichtenhefts. Der Bericht hält den Ablauf fest und begründet den finalen Abrufentscheid.

In dieser strukturierten, formal sauberen Welt könnte man annehmen: Vielfalt ist garantiert.

Das Konzentrationsrisiko

Auf dem Papier klingt eine breite Streuung auf viele Cloudanbieter wie eine Risikoreduzierung, aber in der Praxis kann es jedoch genau das Gegenteil bewirken.

Jeder zusätzliche Anbieter bedeutet einen weiteren Technologie-Stack, eigene Schnittstellen, Sicherheitsrichtlinien, Abrechnungsmodelle und Supportprozesse. Das erhöht die operative Komplexität, erfordert spezialisierte Skills und belastet die Organisation.

Selbst grosse Organisationen wie das BIT stossen hier an Grenzen, sowohl personell als auch finanziell. Erfahrungsgemäss lässt sich eine Umgebung mit mehr als drei aktiven Cloudanbietern kaum effizient und sicher betreiben. Alles darüber hinaus erzeugt mehr Koordinationsaufwand, höhere Betriebskosten und längere Entscheidungswege.

Die Realität – Weniger ist oft mehr

Tatsächlich zeigt sich aber, dass der Bund heute mehrheitlich nur zwei der fünf Public-Cloud-Anbieter regelmässig nutzt.

Das wirft Fragen auf: Handelt es sich um eine technische Notwendigkeit, weil bestimmte Anforderungen nur von diesen Anbietern erfüllt werden können? Oder sind es bestehende Projekte, Partnerschaften und persönliche Präferenzen der Entscheidungsträger, die zu einer faktischen Konzentration führen?

Auch die Leistungsbezüger selbst, also die Ämter und Organisationen, die die Cloud-Leistungen abrufen, spielen hier eine Rolle. Oft sind externe Firmen in Body-Leasing- oder Beratungsmandaten eingebunden, die mit ihren Erfahrungen, Tools und Partnerschaften die Entscheidungspfade beeinflussen.

So kann ein Muster entstehen: Statt Vielfalt auf allen Ebenen zu leben, etabliert sich eine Kerngruppe an bevorzugten Anbietern, mit denen man “eingespielt” ist.

Das sind die offenen Geheimnisse, welche man in der Informatikbranche kennt. Dieses potenzielle Szenario und Risiko kann also überall auftreten, nicht nur beim Bund.

Theorie trifft Praxis und der Preis bleibt Nebensache

Selbst mit einem formal korrekten, anbieterneutralen Pflichtenheft und einem objektiven Kriterienkatalog kann das Ergebnis am Ende stark von den ursprünglichen Erwartungen abweichen.

Ein fiktives Beispiel: In einer Ausschreibung erfüllen mehrere Anbieter alle technischen und sicherheitsrelevanten Anforderungen. Einer davon liegt preislich rund 50% unter dem bevorzugten Anbieter und das in einer Zeit, in der vielerorts kritisiert wird, dass Public Cloud zu teuer sei und die grossen Hyperscaler das “Böse” verkörpern.

Trotzdem entscheidet man sich für den teureren Anbieter. Offiziell mag das durch andere Bewertungskriterien gedeckt sein, in der Praxis aber zeigt es, dass bestehende Präferenzen, bekannte Ökosysteme oder der Wunsch nach minimalem Umstellungsaufwand oft schwerer wiegen als reine Wirtschaftlichkeit.

Wie vendorneutral sind Pflichtenhefte wirklich?

Auf dem Papier klingt das Verfahren vorbildlich. Ein anbieterneutrales Pflichtenheft wird erstellt, ergänzt durch einen detaillierten Kriterienkatalog. Dort finden sich wohl Kriterien zu Themen wie zum Beispiel Compute, Storage, Netzwerk, Identity und Access Management, DevOps, und IT-Security. 

In der Praxis bleibt jedoch die Frage: Wie “neutral” sind diese Pflichtenhefte tatsächlich formuliert? Oft werden technische Anforderungen so gesetzt, dass sie implizit bestimmte Anbieter bevorzugen. Nicht zwingend absichtlich, aber basierend auf bisherigen Projekten, vorhandenen Skills oder bekannten Plattformen.

Für den nicht involvierten Anbieter bleibt der Prozess eine Blackbox  und bekommt am Ende wohl lediglich den Hinweis: „Ein anderer Anbieter hat die Anforderungen besser oder vollständiger erfüllt.“ Ohne das Pflichtenheft jemals gesehen zu haben, ohne den direkten Austausch mit dem Kunden (Bedarfsträger), und ohne zu wissen, ob einzelne Kriterien vielleicht auf Technologien zugeschnitten waren, die man selbst gar nicht im Portfolio hat.

Das Resultat ist eine formell korrekte, aber in der Wirkung oft unausgewogene und unfaire Auswahl.

Ist natürlich auch kein transparenter Prozess für den Steuerzahler, da auch keine öffentlichen Dokumente dazu existieren.

Fazit

Vielfalt ist kein Selbstzweck. Im Cloud-Kontext bedeutet sie nicht automatisch mehr Sicherheit oder Flexibilität. Manchmal sogar das Gegenteil. Entscheidend ist nicht, wie viele Anbieter theoretisch verfügbar sind, sondern wie gut die genutzten Anbieter in die strategischen Ziele passen und wie konsequent Modernisierung umgesetzt wird.

Die SGC bietet die Chance, beides zu verbinden: eine überschaubare, operativ beherrschbare Anbieterlandschaft und eine Plattform, die nicht nur heutigen Anforderungen genügt, sondern auch zukünftige Entwicklungen antizipiert.

Aber die Auswahl der Cloudanbieter soll auch fair passieren.

Hier geht es zum dritten Teil: Die versteckte Innovationsbremse in der Bundes-IT