Looking ahead just a short time, Apple could hold a powerful position in AI where it most makes sense: deployment.

Not only will the company offer up its own AI models for the kind of tasks millions use ChatGPT to do today, but it will provide more sophisticated on-device agentic models to help users get things done through Siri AI.

Apple also offers limited capacity for more complex tasks through Private Cloud Compute, and, in partnership with the likes of Google in the US and Alibaba in China, the company is giving users a trusted conduit through which to access even more sophisticated AI services. 

Deeply deployable

Critics can say it took Apple a long time to get to this point, but they also seem to think the company has finally got the mix right with its series 27 operating systems. Arriving late to a party doesn’t mean you won’t shine once you get there.

Apple is also coming up the inside lane around frontier AI, with iterative OS and hardware enhancements that mean its devices become increasingly effective for Edge AI use cases, on device — no cloud service required.

The company appears to be digging down into those use cases. Mark Gurman at Bloomberg recently predicted that future M7 Ultra Macs will support as much as 1.5TB RAM, making these systems more than capable of running full weight frontier models in people’s offices, colleges, and homes. 

While that does assume the AI-flationary memory market can supply that much RAM at prices humans can afford, it is also true that people are already running AI clusters using off-the-shelf Mac minis networked over Thunderbolt cables. It’s no stretch to believe this will continue to be the case, and that it will even broaden as the power/performance offered at the high end grows.

What’s wrong with good enough?

When combined with open AI stacks, particularly newly emerging varieties, Apple’s platforms should become leading contenders for private AI services and edge AI. Many business users will leap at the chance to offer their workers powerful, self-hosted, private AI services using one or more daisy-chained Mac Studios or Mac minis. The recent craze in deployment of both Macs to support OpenClaw instances shows they already are.

Ultimately, these different slices of momentum mean I agree with investor Jason Calacanis that Apple is in position to apply a great deal of pressure on OpenAI and Claude just by putting models on their devices. 

It’s also worth thinking about how people use AI today. How many of the queries made in the world right now constitute relatively simple tasks that could be transacted by on-device AI, such as the emerging new version of Apple Intelligence or even smaller LLM models running on device? You can even run PrismML’s 1-bit, 27-billion parameter Bonsai on an iPad using the Locally app, and that’s in the here and now.

What happens? Pretty soon you’ll find people recognize that they can already run the vast majority of their AI-augmented workflows using services they have on their existing device or can access on their on-prem Mac set-ups. And, of course, as people get used to running small tasks locally and larger tasks on premises, the actual space in which they need to turn to cloud-based frontier models will erode. That’s even as companies like PrismML work towards slimming down full-weight models so they don’t need to run on a server at all.

“It’s going to be wild when people have unlimited tokens on their desks,” said Calacanis in a podcast round table discussion.

Who has the most to lose?

The current incarnations of AI felt like they came from nowhere. Most people weren’t aware of the technology until returning to work after the 2022 holiday season. Since then, the industry has proliferated with dozens of competing models, most recently including powerful but affordable frontier models such as Qwen and Kimi.ai.

These models aren’t necessarily all as good as one another, but in many cases for much of what we do, we’ll find them to be good enough. That’s an existential crisis for some, as industry observers now think the inevitable pricing pressure means some services might have over-invested in capacity before finding any way to turn a profit.

Those profit-seeking services are the ones with the most to lose as Apple extends its hardware advantage, democratizing AI access for all while providing platforms suitable for edge AI, on-premises AI, private AI, and even AI access using third-party services. (The need for the latter will shrink as the capabilities of the former get better.)

Cupertino rising

What does this all mean? While the industry remains young, it is already fragmenting. And striding through the dust of that process comes Apple, equipped with the hardware, software, and approach to build its business even as the enterprise of first mover AI services erodes.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to my daily Apple-related news summaries at The Core.

Foto: I Believe I Can Fly – shutterstock.com

Enterprise Architecture (EA) Tools unterstützen Unternehmen und Organisationen dabei, mit ihren IT-Strategien die Geschäftsziele optimal zu unterstützen. Sie sorgen ebenfalls dafür, dass Unternehmen ihre Roadmaps für die digitale Transformation geordnet vorantreiben können. EA Tools bieten dafür unter anderem Collaboration-, Reporting-, Testing- und Simulationsfunktionen. Mit deren Hilfe lassen sich Modelle implementieren, die Geschäfts- und IT-Prozesse gezielt verbessern.

Um die beste Lösung für Ihr Unternehmen zu finden, sollten Sie zuerst prüfen, ob sich das jeweilige Tool mit Ihrem Technologie-Stack integrieren lässt. Anschließend gilt es abzuwägen, ob die Informationen, Diagramme und Tabellen, die die Software zur Verfügung stellt, für das Unternehmen auch einen echten Nutzwert haben.

Empfehlenswerte Enterprise-Architecture-Tools

Nachfolgend finden Sie einen Überblick über die wichtigsten Enterprise-Architecture-Tools – in alphabetischer Reihenfolge. Sie stellen einen Mix aus Visualisierungs-, Collaboration- und Project-Management-Funktionen bereit und unterstützen eine Vielzahl von Enterprise Architecture Frameworks.

Ardoq

Nachdem zuerst über einfache Formulare Informationen von Usern, Entwicklern und sonstigen Stakeholdern im Unternehmen eingesammelt wurden, lässt sich mithilfe von Ardoq ein digitaler Zwilling der gesamten Organisation erstellen. Der Ansatz setzt also darauf, die Menschen, die in ihren Rollen mit den verschiedensten Systemen arbeiten, realistisch in ihrer Arbeitswelt abzubilden.

Jede Mitarbeiterin und jeder Mitarbeiter im Unternehmen kann später von den Netzwerkvisualisierungen und Datenfluss-Diagrammen profitieren, um seine eigene Rolle optimal zu unterstützen und den Arbeitsplatz immer wieder anzupassen und zu modernisieren. Das Tool lässt sich mit den wichtigsten Cloud-Plattformen integrieren. Es bietet eine API, die individuelle Anpassungen in allen wichtigen Programmiersprachen (Python, C#, Java, etc.) ermöglicht.

Wichtigste Use Cases:

• “Architektonischen Stress” bei Lastspitzen simulieren, falls größere Veränderungen bevorstehen;

• Verstehen, wie verändertes Nutzerverhalten neue Anforderungen generiert;

• Application Portfolio Management, um besser strategisch zu planen.

Atoll Group SAMU

Das EA-Tool SAMU macht die Enterprise Architecture sichtbar, indem es tiefe Verknüpfungen zwischen On-Premises-Systemen, dem Cloud-Layer und Tools für das Business Process Management aufzeigt. Das Tool der Atoll Group bietet vielfältige Integrationsmöglichkeiten, zum Beispiel mit Monitoring-Tools (etwa Tivoli, ServiceNow), Configuration-Management-Datenbanken (zum Beispiel CA, BMC) oder Service-Organisations-Tools (BMC, HPE). Alle Informationen fließen in ein zentrales Datenmodell ein, das um den zusätzlichen Input der Stakeholder weiter angereichert wird.

Wichtigste Use Cases:

• Enterprise-Architektur visualisieren;

• strategische Planungsprozesse und Architektur-Reviews mit Informationen unterfüttern;

• mithilfe einer visuellen Verständnisgrundlage die Kommunikation verbessern.

Avolution Abacus

Dieses Tool erfasst die Breite und den Umfang der Unternehmensarchitektur mit Hilfe eines auf Diagrammen basierenden Dashboards. Die Integration mit gängigen Tools wie SharePoint, Excel, Visio, Google Sheets, Technopedia oder ServiceNow vereinfacht die Nutzung. Abacus wurde inzwischen auch um einen Machine-Learning-Layer ergänzt, der es Anwendern ermöglicht, ein Modell zu trainieren, das ihnen beispielsweise hilft zu erkennen, wer im Unternehmen für welches System verantwortlich ist.

Wichtigste Use Cases:

• die IT für das gesamte Unternehmen “öffnen”, um ein allgemeines Verständnis der Datenflüsse zu erzeugen;

• umfassendes Enterprise Modeling, um eine Roadmap für künftige Entwicklungen zu erstellen;

• Business-Metriken tracken, die mit der Unternehmens-Performance zusammenhängen.

BOC Group ADOIT

ADOIT soll Teams dabei unterstützen, Ressourcen zu verwalten, Bedarfe vorherzusagen und Assets zu tracken. Dazu mappt das Tool jedes System oder Softwarepaket mit einem Objekt. Die Datenflüsse zwischen den Systemen werden in Beziehungen umgewandelt, die von diesen Objekten mithilfe eines anpassbaren Metamodells erfasst werden. Geschäftsprozesse können auf ähnliche Weise über ein gut integriertes Begleitprodukt namens ADONIS modelliert werden. ADOIT ist Web-basiert und lässt sich auch mit Tools wie Atlassian Confluence integrieren, um die Datenerfassung und -entwicklung zu beschleunigen.

Wichtigste Use Cases:

• ein unternehmensweites Modell erstellen, das bei sämtlichen Teammitgliedern ein Verständnis über den Stack schafft – und wie man diesen verbessern kann;

• vollständiger Zugriff auf EA-Daten über eine Mobile-Anwendung;

• bei Fusionen und Übernahmen den Tech-Bereich durch genaues Asset-Mapping orchestrieren.

Bizzdesign Hopex

Nach der Übernahme von Mega International zählt die Hopex-Plattform zum Portfolio von Bizzdesign. Sie soll dabei unterstützen, Unternehmensanwendungen zu modellieren und dabei ein Verständnis der von ihnen unterstützten Geschäfts-Workflows schaffen. Dabei liegt ein Schwerpunkt auf den Bereichen Data Governance und Risikomanagement. Hopex basiert auf Microsoft Azure und stützt sich auf eine Reihe offener Standards wie GraphQL und REST Queries, um Informationen aus Komponentensystemen zu sammeln. Das Reporting ist mit den Office-Tools von Microsoft sowie mit grafischen Lösungen wie Tableau und Qlik integriert.

Wichtigste Use Cases:

• datengestützte Erkenntnisse herbeiführen, um Cloud- und Anwendungsbereitstellung zu steuern;

• akkurate Nutzungsmodelle erstellen, um Architekturanforderungen zu verstehen;

• eine Bedarfsschätzung mit Umfragen und anderen Tools vornehmen, um für die Zukunft zu planen.

Bizzdesign Horizzon

Das Tool dient dazu, Business Workflows und den zugrundeliegenden Tech-Stack zu modellieren. Dazu bietet Horizzon ein Graph-basiertes Modell, das Daten von sämtlichen Stakeholdern einsammelt und diese an eine Analytics-Engine weitergibt. Im Ergebnis entstehen Diagramme, die den aktuellen Systemzustand widerspiegeln. Wichtige Schwerpunkte dieses Tools sind Change Management und Zukunftsplanung: Horizzon ist nicht zuletzt dafür konzipiert worden, die Risiken eines Redesigns zu minimieren. Das Toolset unterstützt die wichtigsten Frameworks ArchiMate, TOGAF und BPMN. Neben Mega hat Bizzdesign im Januar 2025 auch den EA-Geschäftsbereich der Software AG – Alfabet – übernommen.

Wichtigste Use Cases:

• Vorhersage zukünftiger Anforderungen durch Predictive Modeling;

• Orchestrieren von Workflows auf der Basis der technischen und der Business-Architektur;

• Antizipieren von Risiken sowie Security- und Governance-Problemen durch die Modellierung von Datensicherheitsanforderungen.

Capstera

Das Tool von Capstera fokussiert darauf, die Business Architecture selbst abzubilden. Value und Process Maps helfen dabei, die Rollen der verschiedenen Unternehmensbereiche zu definieren und nachzuverfolgen. Dabei können im laufenden Prozess Verknüpfungen mit den zugrundeliegenden Softwarprodukten und Tools hinzugefügt werden.

Wichtigste Use Cases:

• Reports erstellen, die sich erst einmal mit der Business-Architektur selbst beschäftigen;

• Beziehungen zwischen Menschen, Abteilungen und Rollen analysieren;

• die langfristige strategische Planung vorantreiben.

Clausmark Bee360

Teammitglieder, die Clausmarks Flaggschiffprodukt Bee360 (früher Bee4IT) verwenden, wollen eine einfache “Single Source of Truth” über die Workflows im Unternehmen. Ziel ist es, verschiedenen betrieblichen Rollen intelligentere Entscheidungen zu ermöglichen. Das Modul Bee360 FM (Finanzmanagement) bietet etwa die Möglichkeit, Kosten nachzuvollziehen und zuzuordnen. Die Anwender können verschiedene solcher Module miteinander verknüpfen, um EAM, Finanzmanagement, Portfolio Management und Agile Planning nahtlos zu integrieren – bei maximaler Transparenz.

Wichtigste Use Cases:

• C-Suite-Ebene befähigen, Projekte zu managen und Assets zuzuweisen;

• präzise digitale Zwillinge entwickeln, um ein Verständnis über Datenflüsse zu schaffen und künftige Erweiterungen zu planen;

• integrierte Wissensdatenbank aufbauen, um alle digitalen Workflows zu tracken.

EAS

Das Essential-Paket von EAS (Enterprise Architecture Solutions) nahm als Open-Source-Projekt seinen Anfang und hat sich inzwischen zu einer kommerziell verfügbaren Cloud-Lösung weiterentwickelt. Das Tool erstellt ein Metamodell, das die Interaktionen zwischen Systemen und Geschäftsprozessen beschreibt. Ebenfalls enthalten sind Pakete, um gängige Business Workflows wie Datenmanagement oder DSGVO-Compliance zu tracken.

Wichtigste Use Cases:

• den technischen Reifegrad der eigenen Architektur evaluieren;

• Sicherheit und Governance durch besseres Asset Tracking optimieren;

• wachsende Systemkomplexität kontrollieren und managen.

OrbusInfinity

Orbus Software hat Anfang 2025 die Akquisition seines Konkurrenten Capsifi abgeschlossen. Der Anbieter stellt mit OrbusInfinity eine Enterprise-Transformation-Plattform auf KI-Basis zur Verfügung, die schnellere, bessere Entscheidungen, Kosteinesparungen und Risikominimierung verspricht. Architecture-Teams sollen mit Hifle von OrbusInfinity mit einer Vielzahl von Stakeholdern interagieren können, um eine “digitale Blaupause” ihres Unternehmens zu generieren, die eine einheitliche Sicht auf das aktuelle und künftige Geschäft realisieren soll. Diverse Drittanbieter-Tools lassen sich außerdem mit der Plattform integrieren, darunter etwa von Microsoft, Flexera, ManageEngine oder ServiceNow.

Wichtigste Use Cases:

• Stakeholder-Management;

• Enterprise-Landschaften visualisieren;

• Entscheidungsfindung und Datenanalyse automatisieren.

Planview Enterprise One

Planview bietet eine ganze Reihe von Produkten, mit denen Unternehmen Teamwork, Prozesse und die Enterprise Architecture nachvollziehen können. Die Enterprise Tools sind in drei Kategorien unterteilt: strategisches Portfolio-Management, Produktportfolio-Management und Projektportfolio-Management. Im Zusammenspiel entstehen hardware- und Software-übergreifende Layer, die rollenbasierte Perspektiven für Führungskräfte und Teammitglieder eröffnen. Das Toolset integriert mit gängigen Ticket-Tracking-Systemen wie Jira, um Workflow-Analysen und Reports zu erstellen. Inzwischen hat Planview nach einer Übernahme neue Tools in sein Portfolio integriert, die früher unter den Namen Daptiv, Barometer und Projectplace bekannt waren.

Wichtigste Use Cases:

• eine langfristige, strategische Vision für die Architekturentwicklung aufbauen;

• Entwicklungsarbeit auf Projektebene tracken und in eine beliebige Strategie integrieren;

• mit Fokus auf die Customer Experience und die Produktstruktur den Change vorantreiben.

QualiWare Enterprise Architecture

Das Enterprise Architecture Tool von QualiWare ist Teil einer größeren Sammlung von Modellierungswerkzeugen, die darauf abzielt, sämtliche Geschäftsprozesse zu erfassen. Beispielsweise ist es möglich, einen digitalen Zwillinge zu bauen, mit dem sich Customer Journeys nachvollziehen lassen. Qualiware hat diverse KI-Algorithmen integriert, um Dokumentation und Process Discovery zu optimieren.

Wichtigste Use Cases:

• ein kollaboratives Ökosystem für Business Manager aufbauen, das ein Verständnis von der Enterprise Architecture vermittelt;

• architektonische Designelemente erfassen, um ein Wissens-Ökosystem rund um den Stack aufzubauen;

• eine breite Beteiligung in Sachen Dokumentationserstellung und -überprüfung fördern.

Quest Erwin Evolve

Das Erwin Evolve Tool von Quest hat sich von einem Datenmodellierungs-Tool zu einem System für Enterprise-Architecture- und Geschäftsprozess-Modellierung weiterentwickelt. Um die Komplexität moderner, ineinandergreifender Softwaresysteme und der von ihnen gemanagten Geschäftsprozesse zu durchdringen, können Anwender auf benutzerdefinierte Datenstrukturen zurückgreifen. Das Web-Tool erstellt Modelle, rollenbasierte Diagramme und andere Visualisierungen, die in allgemein zugängliche Dashboards einfließen. Zum Paket gehört ein KI-basiertes Modellierungs-Tool, das Whiteboard-Skizzen integrieren kann.

Wichtigste Use Cases:

• einen digitalen Zwilling für die strategische Modellierung der Enterprise Data Architecture erstellen;

• Customer Journeys verstehen;

• Services und Systeme mit Application Portfolio Management tracken.

SAP LeanIX Enterprise Architecture Suite

Die Tool-Sammlung von LeanIX umfasst unter anderem Enterprise Architecture Management und andere Bereiche, die für Aufgaben wie SaaS– und Value-Stream-Management wichtig sind – etwa um Cloud-Deployments und darauf laufende Services zu tracken. Die Daten die dabei über die IT-Infrastruktur gesammelt werden, fließen in ein grafisches Dashboard ein. Das Tool ist eng mit wichtigen Cloud-Workflow-Tools wie Confluence, Jira, Signavio und Lucidchart integriert. Das ist für Teams von Vorteil, die diese Tools bereits nutzen, um ihre Entwicklungsstrategien zu planen und umzusetzen. Seit November 2023 ist LeanIX Teil von SAP.

Wichtigste Use Cases:

• Anwendungsmodernisierung und Cloud-Migration managen;

• Obsoleszenz von Software-Services evaluieren;

• Kosten kontrollieren und managen.

ServiceNow

Die Tool-Sammlung von ServiceNow lässt sich auf verschiedene Architekturtypen herunterbrechen, darunter Assets, DevOps, Security und Service. Die Tools katalogisieren die unterschiedlichen Hardware- und Softwareplattformen, um Workflows und Datenflüsse im Unternehmen abzubilden und zu verstehen. Ausführliche Reportings und detaillierte Dashboards ermöglichen Analysen, auf deren Grundlage Risiken minimiert und die Ausfallsicherheit der Systeme erhöht werden können.

Wichtigste Use Cases:

• Tracken von Assets, Services und Systemen, die das Unternehmen ausmachen;

• Governance-Themen, Risikobegrenzung, IT-Management und Security Operations werden in einer Plattform zusammengeführt;

• durch die Integration von CRM-Tools lassen sich auch kundenorientierte Services managen.

Sparx Systems

Um Teams und Projekte verschiedener Größe und Komplexität zu unterstützen, hat Sparx vier Versionen seines EA-Tools entwickelt. Allen gemeinsam ist eine UML-basierte Modellierung, mit der sich die Komponenten komplexer Systeme tracken lassen. Eine Simulations-Engine ermöglicht “War Gaming” und vermittelt ein Verständnis darüber, wie sich Fehler ausbreiten und kaskadieren können. Sparx stellt zudem eine Vielzahl von vorgefertigten Design Patterns bereit, um Teams bei der Modellierung zu unterstützen.

Wichtigste Use Cases:

• Nachfrage- und Lastveränderungen zur Prognose künftiger Anforderungen simulieren;

• (potenzielle) Probleme durch eine Verbindungs-Matrix im Auge behalten;

• Dokumentation erstellen.

Unicom System Architect

System Architect ist eines der Angebote aus Unicoms Team Blue. Es handelt sich um ein Tool, das ein Metamodell verwendet, um automatisiert so viele Daten wie möglich über die laufenden Systeme zu sammeln – manchmal auch durch ein Reverse Engineering von Datenflüssen. Dieses systemweite Datenmodell kann über benutzerdefinierte Dashboards Teammitgliedern aller Rollen zugänglich gemacht werden. Ein weiteres erwähnenswertes Feature: Die Ressourcenzuweisung lässt sich mit Hilfe von Simulationen optimieren.

Wichtigste Use Cases:

• Was-wäre-wenn-Fragen zum Architekturmodell stellen;

• ein Metamodell von Daten und Systemen aufbauen;

• Migrations- und Transformationspläne erstellen.

ValueBlue BlueDolphin

Dieses EA-Tool sammelt Daten auf dreierlei Art:

1. Es importiert Basisdaten auf der Grundlage standardgesteuerter Automatisierung (ITSM, SAM).

2. Es arbeitet mit den Dateiformaten von Architekten und Systemdesignern – etwa ArchiMate oder BPMN.

3. Es gibt Fragebögen an andere Stakeholder heraus, die auf anpassbaren Vorlagen basieren.

Die aufbereiteten Informationen werden in einer visuellen Umgebung bereitgestellt, die Auskunft über die historische Entwicklung von Systemen gibt.

Wichtigste Use Cases:

• systemweite Daten von internen und externen Stakeholdern automatisiert und formularbasiert erfassen;

• zukunftsorientierte Reportings erzeugen, um den Change zu überwachen und voranzutreiben;

• Kooperation und Zusammenarbeit durch offenes Data Reporting fördern.

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation CIO.com erschienen.

Enterprises typically operate separate systems for internal and external DNS because the two serve different audiences. Public DNS resolves names for services meant to be reached from the internet. Private DNS resolves internal resources, such as databases and internal applications, that should never be visible outside the corporate network. 

While public DNS is usually a single system, private DNS is often scattered across on-premises appliances, cloud-native resolvers, and split-horizon setups, where the same hostname resolves to a different answer depending on whether the query comes from inside or outside the network. Coordinating those deployments across headquarters, branch offices, and multiple clouds means ongoing manual synchronization work for network teams. 

Private DNS itself is not a new concept. It is already available from hyperscalers and established enterprise DNS vendors, but it typically runs apart from public DNS, with its own console, control plane and policy engine.

Cloudflare’s answer is a product it calls Internal DNS.

“Many organizations already use Cloudflare for their public DNS,” Enrique Somoza, product, performance and infrastructure at Cloudflare, told Network World. “Internal DNS extends that same platform to private DNS, so public and private are managed from the same global network and control plane.” 

How it works

Query handling starts at the resolver, not at the zone. That consolidation extends to daily operations as well.

“Instead of operating two separate DNS systems, customers use one API, one audit trail, one dashboard, and one policy engine for every DNS query—whether it is for a public website or an internal application,” Somoza said.

Policy first. The resolver sits ahead of every lookup, not behind it. “Architecturally, Cloudflare Gateway becomes the resolver that customers connect to, and can use WARP, DNS over HTTPS, DNS over TLS, or traditional DNS,” Somoza said. “Gateway evaluates zero -trust policies first, then routes the query to the appropriate DNS view based on context, such as source IP, device posture, or network location.”

No public path in. Internal zones sit outside the public DNS hierarchy entirely. “Internal zones are never assigned public nameservers—they are only reachable through Gateway, so every query is evaluated before it is resolved,” Somoza said.

One hostname, multiple answers. Branch offices, data centers and cloud environments no longer each need their own resolver stack. “Operationally, this simplifies environments that span branch offices, data centers, and multiple clouds,” Somoza said. “The same internal hostname can return different answers depending on where the request originated without maintaining separate resolver infrastructure, conditional forwarders, or duplicate zone files.”

Somoza described the underlying objective in direct terms: “The goal is to make internal DNS behave like a single service instead of a collection of independent deployments,” he said.

View selection. The same hostname can resolve to different IP addresses depending on where the request comes from. Gateway makes that call using several client signals. 

“View selection is policy driven,” Somoza said. “Gateway resolver policies evaluate the context of each DNS query, including attributes like source IP, device identity, or network location and determine which DNS view should answer the request.”

A view is a container, not a separate infrastructure stack. Somoza explained that a view is simply a logical grouping of internal zones. For example, a company could have separate views for Europe and North America, or for corporate users and operational technology networks.

Latency and resilience. Internal DNS inherits its performance characteristics from Cloudflare’s existing public network. “Internal DNS runs on Cloudflare’s global network, so queries are answered by the nearest available Gateway location, helping keep latency low for connected users,” Somoza said. “Because Internal DNS runs on the same global infrastructure as Cloudflare’s public DNS, it benefits from the same anycast architecture, geographic distribution, and resilient network design.”

How this differs from split-horizon DNS

Internal DNS replaces the duplicate-zone model traditional split-horizon setups depend on.

“Before migrating, many organizations maintain multiple versions of the same internal DNS zones across headquarters, branch offices, and cloud environments,” Somoza explained. “Conditional forwarders determine which resolver answers each query, and keeping those environments synchronized becomes an ongoing operational task.”

Internal DNS collapses those duplicate zones into a single authoritative copy split across views instead. “With Internal DNS, that configuration becomes much simpler,” Somoza said. “A customer might create a single corp.internal zone in Cloudflare and define multiple DNS views.”

For example, users in headquarters could receive one internal IP address for wiki.corp.internal, while branch offices receive a different address. Somoza emphasized that the zone itself only exists once. “Instead of maintaining multiple copies of the same configuration, administrators manage a single source of truth,” he said.

Early use cases and migration challenges

Not surprisingly, Somoza noted that the first use case Cloudflare sees for Internal DNS is for split-horizon DNS consolidation. There is also interest from organizations that operate across multiple cloud providers that want one consistent internal DNS service instead of managing separate DNS platforms in each environment.

Another common use case is extending zero-trust policies to internal name resolution. “Customers already use Gateway to control access to internet traffic, and Internal DNS lets them apply similar policy decisions before internal names are resolved,” Somoza said.

When it comes to migration, the friction customers report during migration is procedural rather than architectural.

“Customers need to think through API permissions, connectivity, and how existing local DNS forwarding rules interact with Gateway,” Somoza said. “Those are all well understood migration steps and customers often run both environments in parallel before completing the transition.”

Over the past year, I had the same conversation with almost every team starting an AI initiative. Should we build on Semantic Kernel, AutoGen or Foundry?

At first it felt like the most important architectural decision we’d make. Each framework had its own philosophy, each promised to be the foundation for enterprise AI, and picking the wrong one felt like an expensive mistake. I spent a lot of time helping teams weigh the trade-offs.

Looking back, I think we were asking the wrong question. I certainly was.

I watched teams spend months debating SDKs while the decisions that actually decided whether their applications survived production went unexamined. Some built elaborate orchestration layers for workflows that a few deterministic functions would have handled. Others avoided agent frameworks entirely and later found they’d designed themselves into a corner.

Then Microsoft settled it for us. It introduced the unified Agent Framework, quietly moved Semantic Kernel and AutoGen into maintenance mode, and the debate I’d spent months refereeing was suddenly over. Turns out the answer to “which of the three” was “none of the three, here’s a fourth.” The framework hit version 1.0 and general availability in April 2026, stable across .NET and Python.

What surprised me wasn’t the decision. It was how fast a debate that had eaten so much of our attention stopped mattering. Microsoft changed the menu.

It didn’t change the meal.

The framework was never the hard part

Framework selection dominated almost every early conversation I had about enterprise agents. Which SDK do we standardize on? Which orchestration model gives us the most flexibility? Which one is Microsoft actually betting on?

Fair questions. But after a year of watching these projects play out, I’ve slowly come around to a different view. Those weren’t the questions that decided anything.

The first question I ask now is much smaller. Does this thing actually need an agent?

It sounds obvious, and I still get it wrong sometimes. But it’s the mistake I see most. On one project, a team spent weeks designing a multi-agent workflow for a process that ran the same four steps every time: read a document, validate it, call an API, send a notification. The diagrams looked great. The system in production didn’t. A few well-tested functions would have been easier to build, easier to maintain and a lot easier to trust.

Part of this is just that “agent” has become the word everyone reaches for. Sometimes it’s the right call. Sometimes it’s a workflow we already knew how to build, wearing a newer label. An agent earns its complexity when it genuinely has to decide things you can’t predetermine, choosing between tools, adapting to what it finds, working out its own next step. If you already know every step, you have a workflow, and a workflow is usually the better engineering choice. The consolidation didn’t change that. It just made it easier to see.

What building production agents actually taught me

Once I stopped fixating on frameworks, the same three problems kept showing up. None of them had anything to do with the SDK.

Context beats model choice

Early on I spent a lot of time comparing models, the way you’d agonize over a restaurant menu and then order what you always order. Now I spend most of it thinking about context, which is far less fun and far more useful.

I’ve watched good models fail because they were handed too much, not too little. One team I worked with gave the model access to nearly every internal document they had on the theory that more information meant better answers. It went the other way. Responses got slower, less consistent and sometimes skipped right past the thing that actually mattered. When we cut the context down to only what the task needed, the quality jumped almost immediately. I didn’t predict that. It taught me to be suspicious of “just give it everything.”

The best agent systems I’ve worked on weren’t the ones with the biggest context windows. They were the ones careful about what reached the model, and when. That’s not something the framework hands you.

Failure is where the real work is

Most agent demos look great because they’re built around the happy path. Production doesn’t extend that courtesy.

I remember a project where everything held up in testing. Then a downstream API timed out after the agent had already completed several earlier steps. We couldn’t just restart, because part of the business process had already gone through. We ended up spending far more time on recovery logic than we ever spent on prompts. That project changed how I think about this work. The hard part was never getting the model to make a decision. It was making sure the system didn’t fall apart when reality refused to follow the script.

Tool calls fail partway through. APIs return inconsistent data. Models call the same tool over and over because the last answer wasn’t what they wanted. That’s not the exception; that’s a normal Tuesday. Whether you retry, roll back, pause for a human or push on with partial results is a judgment call, and no framework is going to make it for you.

Identity is the real security boundary

This one surprised me most. The moment an agent stops being a chatbot and starts touching real business systems, identity matters more than orchestration.

Every project gets to the same question eventually. Who is this agent actually acting as? The developer’s credentials? A service account? The user who asked? Get it wrong and you’ve built something autonomous running with more access than any single person should have, which is exactly the kind of thing that looks fine until an audit. The Agent Framework, like most modern tooling, makes it easier to wire agents to tools through standards like the Model Context Protocol. That helps. But where human approval belongs, what needs extra authorization, how much rope to give the thing, those are still yours to decide.

The surprises weren’t technical

Here’s what I didn’t see coming. The hardest part of last year wasn’t technical at all. It was organizational. The moment a team heard “agent,” expectations shifted under everyone’s feet. Business stakeholders started expecting full autonomy. Developers assumed the thing could reason its way through anything. People started designing for flexibility before we’d even agreed on what problem we were solving. The word did damage before any code did. I found myself spending as much time resetting expectations as I did discussing architecture.

Build for change, not for today’s winner

I don’t think the teams that struggled last year picked the wrong framework. Semantic Kernel was reasonable. AutoGen was reasonable. Foundry made sense for plenty of cases. I’d have signed off on any of them.

The ones that got hurt put all their eggs in one framework, treating it as the foundation of the whole system instead of as one more dependency. Microsoft provided a migration path. But teams that had tightly coupled their applications to framework-specific abstractions discovered that migrating and rewriting are not the same thing. That wasn’t Microsoft’s doing. It was their own architecture’s. The teams that moved easily had kept their business logic, prompts and orchestration loose enough to evolve independently of any one SDK. For them, the change was a manageable project, not a teardown.

For what it’s worth, nobody I work with is treating this as an emergency. Most are moving the smaller workloads first, watching how they behave and leaving the production-critical systems alone until they actually understand the new abstractions. That’s the right instinct. And I doubt this is the last consolidation we’ll see, the ecosystem is still young, frameworks will keep absorbing each other and over time the differences between them will be operational more than architectural.

I don’t regret the framework debates, honestly. They were reasonable at the time. What changed wasn’t Microsoft’s roadmap.

It was mine. Watching these systems run in production taught me that the framework is the easiest piece to swap out. Recovery logic, context management, security boundaries, the business workflow itself, those stay with you long after today’s SDK gets replaced by tomorrow’s.

So, Microsoft made one decision easier by turning three frameworks into one. Good. Five years from now we’ll be on different tools, and we’ll still be asking the same handful of questions.

Does this actually need an agent? Does it have the right context? Can it recover when something breaks, because something will? Is it acting as the right person?

Those questions outlast every rewrite. That’s where I’ve learned to put my effort.

Frameworks come and go. Good architecture has to survive all of them.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Defense research agency DARPA made its largest quantum computing award ever this week, with a $125 million agreement announced on Wednesday. The same day, the White House announced an additional $5 billion for the Genesis Mission, which focuses on AI for science but also includes technology to accelerate quantum computing and quantum sensors.

“Taken together, these announcements signal that U.S. quantum strategy is shifting from supporting individual research projects to building the infrastructure needed for a quantum-enabled economy,” says Heather West, research manager in the infrastructure systems, platforms, and technology group at IDC.

None of the individual quantum announcements are surprising, she says. But the level of coordination is new. “Government investment is expanding beyond foundational research toward commercialization, manufacturing, and deployment,” she says.

“The US government has been signaling that quantum computing is a priority,” says David Mooter, an analyst at Forrester Research. Part of it is the desire for the US to be a leader in quantum, as it has been in other high-tech areas, he says. And part of it is because the government itself can take advantage of quantum computers.

“Spy agencies would love to use them to decrypt intercepted messages, including messages they intercepted years ago and saved,” he says. And other departments could use quantum computers or networks for energy-related research, for supply chain optimization, and for secure communications. 

Quantum computing is accelerating, he says. “I would not be surprised to see a general gate-based quantum computer that’s good enough to provide commercial value for limited use cases by 2030.”

DARPA’s Quantum Benchmarking Initiative

DARPA’s Quantum Benchmarking Initiatives was launched in 2024, and 18 companies were selected in April of 2025 for Stage A of the project, with awards of up to $1 million each. The companies were to use the money to provide details of their concepts and show how they could lead to a functional, fault-tolerant quantum computer in under a decade.

Then, in November of 2025, DARPA chose 11 companies for Stage B of the project, with awards of up to $15 million for developing their research plans.

To date, only two companies have been chosen for Stage C: PsiQuantum and Microsoft. PsiQuantum announced $32 million of DARPA funding for testing and evaluation in September of last year. This week’s $125 million award will expand the scope and pacing of the validation and verification work. Stage C awards can go up to $300 million, according to DARPA.

This past May, PsiQuantum also announced $100 million from the Department of Commerce, part of the CHIPS and Science Act, to accelerate domestic manufacturing of critical quantum computing components.

Microsoft and PsiQuantum are both in Stage C, bypassing the sequential path that other companies are expected to follow, because they were both part of DARPA’s predecessor to QBI, the Underexplored Systems for Utility-Scale Quantum Computing program.

Genesis Mission

Genesis Mission was launched in late 2025 with the goal of using AI to accelerate scientific breakthroughs, and it now includes more than 15 government agencies.

As part of the Genesis Mission, quantum computing and sensing company Infleqtion announced three projects for the Department of Energy on Wednesday. The three projects focus on quantum circuit design for nuclear applications, atomic quantum sensing, and nuclear fusion energy research.

This announcement did not include the total monetary value of the projects, but, in May, the company announced a separate agreement with the Department of Commerce for $100 million to accelerate Infleqtion’s neutral-atom technology roadmap.

Other quantum-related Genesis Mission projects announced this week include $1.5 million for a BlueQubit quantum error correction project with Microsoft and other partners, a Stanford effort to model the behavior of electrons at quantum scale, an MIT quantum sensing project, Argonne National Laboratory projects on quantum circuit design and quantum sensors, Brookhaven Lab quantum sensor projects, and quantum computing projects at Northwestern University.

IBM, one of three dozen private companies that are part of the Genesis Mission Consortium, announced that it will be leading a project to support more effective quantum applications, and will contribute up to $50 million of quantum compute access for the Genesis Mission.

Enterprise priorities

This week’s quantum announcements aren’t a sign that enterprises need to run out and buy quantum computers, says IDC’s West. But they do need to start preparing for the quantum era — such as by identifying business areas where quantum computing could become a competitive differentiator over the next decade.

But the most immediate threat is that of adversaries using quantum computers to break current encryption standards. Organizations should be inventorying cryptographic assets and developing a roadmap for the migration to quantum-proof algorithms, West says.

The point of no return is closer than ever, and many major players in the encryption and communication space, including Google and Cloudflare, have been accelerating their timelines. In fact, this Wednesday was the federal deadline for naming their post-quantum cryptography migration leads under a June executive order.

“The preparation that needs to be done to prepare is to implement post-quantum cryptography yesterday,” says Forrester’s Mooter.

However, according to a survey released by DigiCert this morning, while 87% of organizations are planning, testing or implementing PQC initiatives, only 7% of organizations have deployed quantum-safe or hybrid cryptography across most of their digital certificates.

hasan as’ari – shutterstock.com

SAP-Anwenderunternehmen stehen unter Druck, auf SAP S/4HANA zu wechseln, weil die Mainstream-Wartung für SAP ERP (SAP ECC 6.0) Ende 2027 ausläuft und die bis Ende 2030 geltende erweiterte Wartung kostenpflichtig ist.

Zwar stellt SAP mit der „SAP ERP, Private Edition, Transition Option“ eine weitere Wartungsverlängerung bis 2033 in Aussicht. Da diese einer Neuimplementierung gleichkommt, bleibt SAP-Kunden mehr Zeit für die Planung, die Analyse und das Changemanagement. Der Nachteil: Wer diese Option nutzt, läuft Gefahr, technologisch ins Hintertreffen zu geraten, da Innovationen nahezu ausschließlich für SAP S/4HANA bereitgestellt werden.

Zögerliche SAP-S/4HANA-Transformation trotz Wartungsdruck

Obwohl der Druck hoch ist, hat eine große Zahl der SAP-Bestandskunden die Transformation auf die seit 2015 verfügbare ERP-Suite offenbar noch nicht vollzogen. Eine COMPUTERWOCHE-Expertenrunde zeigte, wo die größten Hürden liegen und was erfolgreiche Projekte auszeichnet.

Warum etliche Unternehmen die Transformation vor dem regulären Wartungsende scheuen und stattdessen zwei Prozent Mehrkosten für die erweiterte Wartung einkalkulieren, brachte ein Teilnehmender auf den Punkt: Firmen haben über Jahrzehnte in ihre SAP-ERP-Lösung investiert und sie an individuelle Prozessanforderungen angepasst, damit die Abläufe entlang der Supply Chain reibungslos laufen. Er habe daher in den vergangenen zehn Jahren keinen Kunden erlebt, der freiwillig umsteigen wollte. Alle hätten gesagt, dass sie müssen.

Nach Erfahrungswerten eines weiteren Experten nutzen erst rund 20 Prozent der SAP-Kunden SAP S/4HANA als Kernapplikation produktiv, unter anderem, weil entsprechende Transformationsprojekte auf sieben bis neun Jahre angelegt sind.

Altlasten bremsen die SAP-S/4HANA-Transformation

Unternehmen, die sich für den Wechsel entscheiden, verzichten häufig auf jede Modernisierung. Sie vollziehen einen Eins-zu-eins-Umstieg ohne Code-Modifikation, sei es in Form einer System Conversion (Brownfield-Ansatz) oder per Lift and Shift in SAP Cloud ERP Private (früher: SAP S/4HANA Cloud Private Edition). Dabei ist eine große Zahl von SAP-ERP-Installationen gar nicht zukunftsfähig, weil sie auf Prozessen aus den 1990er Jahren basieren und im Lauf der Jahre durch zahlreiche Eigenentwicklungen erweitert wurden.

Nicht selten gibt es bis zu mehrere tausend kundeneigene Programme im Z/Y-Namensraum, die zum Teil nicht mehr genutzt werden und das System unnötig belasten. Die Experten waren sich einig, dass eine solche rein technische Migration, bei der Altlasten wie ABAP-Eigenentwicklungen mitgeschleppt werden, keinen Mehrwert für das Unternehmen bringt.

Es muss geprüft werden, welche Eigenentwicklungen beibehalten werden, weil sie wettbewerbsdifferenzierend und damit geschäftskritisch sind, und welche gelöscht werden müssen, weil sie nicht genutzt werden oder weil es dafür inzwischen SAP-Standardfunktionen gibt. Handlungsbedarf besteht auch bei einer dreistelligen Anzahl von Buchungskreisen, von denen niemand weiß, welche noch benötigt werden, oder bei zahlreichen Dubletten in den Kreditoren- und Debitorenstammdaten.

Migrations-Tools und KI-Agenten beschleunigen den Umstieg

Um diesen Prüf- und Bereinigungsaufwand zu bewältigen, bietet SAP mehrere Tools, um die Transformation auf SAP S/4HANA zu vereinfachen: darunter SAP Activate, SAP Cloud ALM, Migration Cockpit, Readiness Check, Custom-Code-Check oder Modifikationsabgleich. Ergänzt werden sie durch Lösungen wie Signavio für die Prozessanalyse. Die Experten schätzen den Effizienzgewinn durch solche Migrationswerkzeuge auf 30 bis 50 Prozent.

Zusätzliche Produktivität versprechen KI-Agenten, die Altsysteme automatisiert analysieren, Code bereinigen und Datenflüsse transformieren. Das reduziert den Migrationsaufwand und beschleunigt den Umstieg.

Scope-Management als Schlüssel für den Projekterfolg

Einig waren sich die Teilnehmenden, dass SAP-S/4HANA-Transformationsprojekte in der Regel nicht an der Technologie scheitern, sondern an einer mangelhaften Scope-Definition und am unzureichenden Changemanagement.

Ein Scope-Management vor dem Projektstart, das berücksichtigt, wie viel Veränderung der IT-Organisation und den Fachbereichen zugemutet werden kann, sei essenziell für den Erfolg, sagte einer der Teilnehmenden. Es erfordert die Fähigkeit zu priorisieren und ein iteratives Vorgehen, bei dem zunächst geschäftskritische Must-haves und Quick Wins umgesetzt werden. Weniger wichtige Nice-to-haves folgen später. Wer dagegen in der Konzeptionsphase bereits den großen Wurf anstrebt, wird voraussichtlich scheitern. Als Beispiel wurde der direkte Umstieg auf ein SAP-S/4HANA-Kernsystem genannt, das nach dem Clean-Core-Ansatz von nicht mehr lauffähigen Programmen und obsoleten Erweiterungen bereinigt ist.

Genauso wichtig ist ein Change-Management, das Mitarbeitende von Beginn an einbezieht, die nötige Akzeptanz schafft und vom Top-Management aktiv unterstützt wird, sowie eine verbindliche Governance mit klaren Zielvorgaben. Unverzichtbar ist auch die Einbindung der Fachbereiche. Sie stellt die größte Herausforderung dar, da Unternehmen befürchten, dass durch die SAP-S/4HANA-Transformation zu viele personelle Ressourcen gebunden werden, die dann für Kernaufgaben fehlen. Kommt es vor, dass IT und Fachbereiche als Antipoden agieren, sollte ein Change-Coach als Vermittler eingesetzt werden.

Hybride Betriebsmodelle setzen sich langfristig durch

Bereits vor dem Projektstart muss abschließend geklärt sein, welches Betriebsmodell für SAP S/4HANA am besten zu einem Unternehmen und seinen Zielen passt, auch mit Blick auf regulatorische Anforderungen. Das ist häufig nicht der Fall, sodass das Projektteam unnötig Zeit damit verbringt, das passende Betriebsmodell zu ermitteln. Das bremst Transformationsvorhaben aus.

Nach Ansicht eines Teilnehmenden wird sich langfristig ein hybrides Betriebsmodell durchsetzen, bei dem der SAP-Kunde entscheidet, welche Elemente der SAP-S/4HANA-Landschaft in einer Hyperscaler-Cloud, einer souveränen Cloud und/oder On-Premises laufen. Eine weitere, weitgehend unbekannte Möglichkeit ist der Betrieb im Rahmen der Customer-Data-Center-Option (CDC) von SAP Cloud ERP Private (früher: SAP S/4HANA Cloud Private Edition), die aus Gründen wie Datenschutz, Leistung und Souveränität eine interessante Alternative sein kann.

Mehrere Experten stellen darüber hinaus fest, dass die vollwertige SaaS-Lösung SAP Cloud ERP Public (früher: SAP S/4HANA Cloud Public Edition) inzwischen verstärkt eingesetzt wird. Sie stellt vorkonfigurierte Kern-ERP-Funktionen (Best Practices) bereit und lässt sich relativ schnell einführen, ermöglicht aber kaum individuelle Anpassungen. Diese Abstriche nehmen Unternehmen in Kauf, um von regelmäßigen, automatischen Upgrades und technologischen Innovationen zu profitieren.

Kritisiert wurde allerdings, dass die Cloud-Diskussion häufig unter begrifflichen Unschärfen leidet. So macht der Betrieb von SAP S/4HANA in einer Hyperscaler- oder SAP-Cloud die Lösung noch lange nicht zum Software-as-a-Service-Angebot. Solche Ungenauigkeiten irritierten SAP-Kunden und bremsten die Entscheidungsfindung. Letztlich sind beim Cloud-Betrieb auch die Kosten entscheidend. Zwar wollen viele Unternehmen anfangs maximale Sicherheit mit Private Network und Confidential Computing, wählen dann aber günstigere Commercial-Cloud-Angebote. Ausnahmen bilden regulierte Branchen und der öffentliche Sektor.

Ob hybrides Betriebsmodell oder Kostenfrage, am Ende entscheidet über den Projekterfolg nicht allein die Technologie, sondern auch, wie diszipliniert Scope und Wandel im Unternehmen gesteuert werden.

Teilnehmer der Round-Table “SAP S4HANA 2027”

Harald Becker / Hewlett-Packard GmbH

Sonja Brüggemann / Lufthansa Industry Solutions GmbH & Co. KG

Microsoft Deutschland GmbH

VOGUS – Wolfgang Voglhuber / Natuvion GmbH

smartShift Technologies GmbH

Outsourcing worked – until it didn’t.

After Akirolabs achieved early market validation and onboarded its first enterprise customers, outsourcing began to create strategic limitations around scalability, intellectual property (IP) ownership, security and delivery execution.

The challenges started after the first enterprise customers confirmed product-market fit. At that point, delivery speed became directly tied to business growth. Product quality expectations increased. Infrastructure and security requirements became stricter. Investors started asking difficult but fair questions about IP ownership, operational dependencies and long-term scalability.

Most importantly, engineering execution was no longer just an operational function – it became part of the company’s strategic advantage. That was the moment when the founders decided the company needed dedicated technology leadership to address these challenges. This is how I joined the company at the beginning of 2023. As VP of Engineering and a bit later as CTO, I led the transformation (usually known as insourcing, repatriating or backsourcing) from an outsourced model to an internal engineering organization while maintaining product delivery continuity and preparing the company for the next growth stage. The process took roughly a year and involved not only technical migration, but also organizational design, hiring, process development, infrastructure modernization and cultural transformation – everything from the ground up.

Building an internal engineering organization while still delivering

One of the biggest misconceptions about insourcing is that it is primarily a technical project. It is a leadership and execution challenge.

When I joined the company, there was effectively no internal engineering structure, limited visibility into the existing system and no clear long-term technical strategy. My first months were dedicated to understanding reality and I began with a comprehensive assessment of the codebase, operational risks, documentation quality and knowledge dependencies to determine the most viable transition strategy.

Very early in the process, I faced a critical strategic decision: whether to gradually assume ownership of the existing platform or rebuild it internally. To make that decision, I evaluated four distinct transition models ranging from limited management insourcing to a complete internal rebuild.

After assessing the technical, operational and long-term business implications of each approach, I selected the most demanding option: rebuilding the product internally while maintaining uninterrupted delivery for existing customers. Although riskier in the short term, a full rebuild offered the clearest route to complete IP ownership, architectural flexibility and long-term scalability.

At the time, this decision ran counter to the approach typically taken by startups in similar situations. Most organizations gradually assume ownership of an existing codebase to minimize short-term risk and preserve delivery capacity. My assessment was that the accumulated architectural debt, fragmented knowledge distribution and long-term maintenance risks would ultimately make a phased takeover more expensive and less scalable than a controlled rebuild. The strategy required significantly higher execution discipline, but it allowed us to establish complete ownership of the platform, eliminate inherited constraints and create an architecture capable of supporting enterprise-scale growth.

The next challenge was hiring.

In Germany, hiring can easily take four to six months – mostly due to a typical 3-month notice period, which is incompatible with startup timelines. We solved this by building a hybrid organization structure early: a lean internal core team combined with carefully selected contractors. Instead of hiring only narrow specialists, we prioritized experienced generalists capable of operating across architecture, infrastructure, security and compliance discussions. Later, we evolved toward a product engineering model, where engineers owned broader product outcomes rather than narrowly defined technical functions.

During the first three months, we established a core engineering team of four senior engineers. Over the following nine months, the organization expanded to roughly fifteen engineers while I strategically designed and executed the transformation of the platform’s architecture to meet the rigorous deployment and compliance standards of our first enterprise clients, including Raiffeisen Bank International and Bertelsmann. This structural overhaul allowed the company to meet the deployment, security and compliance requirements of enterprise customers that had previously been inaccessible under the outsourced model. At that point, we had already achieved complete coverage across backend, frontend, DevOps, QA and security.

I also intentionally kept processes lightweight during the transition. Instead of introducing heavyweight frameworks, we focused on clarity of priorities, fast decision-making and execution discipline. We used Kanban over Scrum, eliminated unnecessary meetings, shortened the remaining ones and emphasized engineering culture over process overhead.

Another major challenge was project estimation. Because dual-track development was unavoidable until the in-house platform reached production readiness, estimation accuracy had a direct impact on budget efficiency. Despite all challenges, my initial estimate ultimately proved remarkably close to the final delivery date, differing by only about a week. Accurate forecasting under conditions of parallel development streams, ongoing customer commitments and active team formation became a critical leadership challenge. Maintaining this level of predictability throughout the transition helped align engineering execution with business planning, hiring decisions and investor expectations.

The engineering transformation enabled capabilities that contributed to Akirolabs being recognized as an IDC Innovator in Procurement in 2023, named amongst the Top 27 AI Startups in Germany in 2024, Sifted’s 100 Fastest-Growing Startups in DACH & CEE 2025 and inclusion in 2024-2026 in ProcureTech100 annual recognition of procurement technology providers shaping the future of digital procurement.

Managing risk without slowing down the business

The hardest part of insourcing is not writing code, selecting the technology stack, designing architecture or configuring infrastructure. It is avoiding disruption while the company is changing underneath the product. I successfully orchestrated the concurrent overhaul of product architecture, cross-functional engineering recruitment, infrastructure modernization and live customer operations under exceptionally tight margins.

To reduce delivery risk, we approached the transition in layers.

First, we focused on infrastructure reliability and operational readiness before feature expansion. Cloud architecture, recovery testing, permission segregation and incident management processes were implemented early, not after launch. We also introduced multiple testing stages and dedicated QA functions after learning the hard way that a “developers-only” quality control approach does not scale for complex web platforms and business domains.

Second, we established a structured knowledge-transfer process to rapidly onboard engineers and reduce external dependencies.

Third, we became extremely disciplined about scope management. One of the most common reasons insourcing initiatives fail is uncontrolled change during the rebuild phase. Every new feature request increases uncertainty non-linearly. We learned to separate strategic improvements from distractions and protect the core delivery roadmap aggressively. Throughout the transition, we successfully maintained uninterrupted customer operations by utilizing planned maintenance windows, achieved a near-zero-downtime migration and permanently doubled product velocity immediately following the migration.

Beyond the technical migration itself, the transition established a repeatable operating model for scaling technology organizations beyond the product-market-fit stage. The framework combined organizational redesign, controlled knowledge repatriation, architecture modernization and enterprise-grade operational practices while maintaining uninterrupted customer delivery throughout the transformation. While the implementation was specific to Akirolabs, the underlying principles are broadly applicable to organizations seeking to transition from outsourced development to internal product ownership without disrupting business operations.

By the time the new platform reached production readiness, I had established not only a functioning engineering organization, but also a stable operational model: internal ownership, production-grade infrastructure, security processes, scalable hiring practices and clear technology and product roadmaps.

A positive side effect of the transition was the creation of internal UI/UX and Data Science capabilities, which later became strategically important for AI product initiatives and created a foundation for the third version of the product, which we released in mid-2025.

My technical restructuring and migration to a secure proprietary platform reduced architectural risk, established full in-house ownership and helped strengthen investor confidence during the company’s successful €5M fundraising round in 2024.

The transition created a stronger foundation for scale and supported the company’s continued expansion among enterprise organizations operating at Fortune 500 scale, including Ahold Delhaize, Workday, IFF, Deutsche Bahn and others.

Lessons learned for CTOs considering insourcing

Looking back, several decisions made the transition successful, and several mistakes made it harder than necessary.

The first lesson is simple: decisiveness in strategic transition is paramount to maintaining business momentum. Rapidly evaluating insourcing frameworks and defining clear boundaries with the external partner allowed us to mitigate operational downtime and execute a highly efficient migration ahead of critical market deadlines.

Second, hire more senior people and do it as early as possible. Strong technical leaders multiply execution capacity far beyond their individual contribution. In our case, the quality of the first hires influenced architecture quality, hiring standards, delivery discipline and engineering culture for the entire organization.

Finally, culture matters more than frameworks. Processes can be added later. Ownership mentality cannot.

The biggest long-term advantage of bringing development in-house was not simply faster execution, not better code quality or operational cost optimization by over 30% after the transition which we also achieved. It was an alignment. Product strategy, engineering decisions, customer priorities and business goals became part of the same conversation instead of being separated by organizational boundaries. For technology companies operating in highly competitive markets, that alignment becomes a compounding advantage over time.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Many enterprises are investing tens of millions in modernizing their SAP landscapes, but are often underestimating a crucial factor for success, the training of their own developers, according to the German-Speaking SAP User Group, DSAG.

The user association urges CIOs to treat the continuing education of SAP developers not as a voluntary training measure but as a strategic investment program in a new report on upskilling [PDF, in German]. Well-trained developers are essential for building stable, maintainable in-house projects without accumulating technical debt, but without continuing education during the upgrade to S/4HANA, the potential of the new technologies will remain untapped, it warned.

Outdated expertise becomes a project risk

As the authors explain, while many ABAP developers have decades of experience with SAP R/3 or ECC and possess extensive process knowledge, development paradigms have fundamentally changed with S/4HANA, Clean Core, and ABAP Cloud.

In the long term, this threatens to lead to poor architectural decisions, time-consuming workarounds, and in-house developments that will need to be maintained with every release, according to DSAG. Many business consultants, too, are still relying too heavily on classic GUI transactions and not taking modern Fiori technologies sufficiently into account.

The result is what the SAP user group refers to as “skills debt.” This debt remains invisible at first but later becomes apparent in the form of longer projects, rising maintenance costs, and a growing dependence on external service providers.

Skill building must start before the project

The DSAG authors view the timing of training as particularly critical. Those who wait until an ongoing S/4HANA migration project is underway to begin building expertise significantly increase the project risk. A lack of knowledge about CDS, RAP, or Fiori leads to architectural decisions that must later be corrected at great expense. At the same time, the necessary learning effort can hardly be managed alongside day-to-day business operations.

But even after the migration is complete, SAP developers must continue their training, according to DSAG. The authors warn that anyone who continues to work as they did on ECC will miss out on the opportunities offered by current SAP technologies — even if everything still works technically. At the same time, they can immediately apply what they’ve learned, which helps solidify their new knowledge.

AI no replacement for developer expertise

While AI tools can generate and explain code, this requires that developers be able to evaluate the results from a technical perspective, and according to DSAG the same applies to development in the SAP environment: “Only those who understand what constitutes good SAP code can use AI as an accelerator,” the authors write. Otherwise, AI acts as a risk amplifier and, in the worst case, merely accelerates the accumulation of technical debt.

The prerequisites for successful AI deployment are solid software engineering knowledge, automated testing, and an understanding of modern SAP development.

DSAG’s five recommendations

DSAG recommends that CIOs firmly integrate continuing education into their transformation strategy with five measures:

• defining mandatory learning paths for different roles, such as ABAP, CAP, or integration developers, as well as business consultants,
• providing suitable sandbox and test environments,
• mandatorily including training time in capacity planning,
• coordinating training schedules with migration and modernization projects, and
• using existing DSAG guidelines as a reference framework for development.

Every enterprise AI conversation seems to begin with the same question: Which model should we use?

I understand why. Models are visible. They have names, benchmarks, release notes, pricing pages and impressive demos. They are easy to compare in a leadership meeting. One model promises better reasoning. Another offers a larger context window. Another appears faster, cheaper or more specialized.

But after years of working around enterprise platforms, integration layers, cloud migration, middleware, production operations and mission-critical systems, I see the AI conversation differently.

The model matters. But it is not where most enterprises will struggle next.

The next AI bottleneck is the infrastructure behind the model.

I do not mean only GPUs, cloud capacity or data storage. I mean the full enterprise operating layer that allows AI to work safely in the real world: data pipelines, identity, APIs, messaging, observability, security controls, deployment automation, cost governance, auditability, support ownership and recovery design.

That layer is what determines whether AI remains an exciting experiment or becomes a trusted business capability.

Pilots hide the hard part

Most organizations can build an impressive AI pilot. A small team can connect a model to a dataset, create a workflow and show a use case that works well in a controlled setting.

The harder part starts when that pilot moves into a real production process.

That is when practical questions show up. Who owns the data quality? What systems can the AI access? How do we trace which prompt, policy or retrieval flow produced a specific answer? What happens when an API slows down, a queue backs up or a downstream system is unavailable?

To me, these are not model problems. They are infrastructure problems.

This is where many enterprises are now headed. The first phase of AI was experimentation. The next phase is operationalization, and that is where the real gap becomes clear.

McKinsey has made a similar point in its work on agentic AI, noting that the next phase of value depends less on isolated tools and more on redesigning workflows, operating models and enterprise execution around agents.

AI pilots can survive on enthusiasm. Production AI requires architecture.

AI is becoming an integration problem

The more I look at enterprise AI, the more it feels like an integration challenge.

In large organizations, I have seen how messaging platforms, integration gateways, deployment pipelines, monitoring tools and cloud infrastructure can decide whether a digital capability succeeds or fails. AI will be no different. Even the strongest model will struggle if the data, middleware, identity layer and operational controls around it are weak.

AI does not work in isolation. It needs context from systems of record, clean data from different business areas, secure access to APIs, event streams, workflows, knowledge repositories, monitoring tools and legacy systems.

That is why the CIO question is changing.

It is no longer just, “Which AI tool should we buy?”

It is becoming, “Can we safely operationalize intelligence across the business?”

This is where agentic AI matters. Autonomous AI only creates real value when the architecture around it can make its actions safe, traceable and useful.

A model can generate an answer. Infrastructure determines whether that answer is secure, timely, explainable, governed and connected to the right workflow.

For example, an AI assistant that summarizes customer or order information may look like a model use case. But underneath, it depends on access control, fresh data, reliable APIs, logging, encryption, monitoring and policy enforcement.

If the answer is wrong, people may blame the model. But the real failure may have started with stale data, weak integration, poor access design, missing observability or an unreliable downstream system.

That is why CIOs should not judge AI only by model capability. The enterprise system around the model matters just as much.

Latency will become a trust issue

In traditional technology operations, latency is often treated as a performance metric. In AI-enabled workflows, latency becomes a trust issue.

When an employee asks an AI assistant for help and the response takes too long, the employee stops using it. When a customer-facing workflow becomes slow, the customer abandons it. When an AI agent waits on multiple backend calls, the entire business process feels unreliable.

This becomes even more important as organizations move from simple chat interfaces to agentic workflows. A single AI-driven action may include identity checks, context retrieval, policy validation, model reasoning, API calls, business-rule execution, logging and human approval.

Each step adds latency. Each dependency adds a possible failure point.

A model may be fast in a benchmark but slow inside an enterprise process. That difference matters.

This is where platform engineering becomes essential. Enterprises need reusable patterns for AI workloads: approved connectors, secure retrieval methods, queue-based decoupling, caching strategies, deployment pipelines, monitoring dashboards and standard rollback procedures.

Without those patterns, every AI initiative becomes a custom build. Custom builds may work for pilots, but they do not scale across a large enterprise.

Observability has to expand

Traditional monitoring tells us whether infrastructure is healthy. Is the server up? Is CPU high? Is memory exhausted? Is the application returning errors?

AI needs that, but it also needs more.

We need to know what data was retrieved, which model was used, which prompt version was active, which user initiated the request, which policy was applied, how long each step took and whether the output passed validation.

We also need to detect new forms of risk: unusual usage patterns, repeated failed tool calls, unexpected cost spikes, sensitive data exposure, weak retrieval results or an AI workflow attempting actions outside its intended boundary.

In production AI, observability is not only about uptime. It is about confidence.

If a business leader, auditor, regulator or security team asks why an AI system made a recommendation, the answer cannot be, “The model said so.” The enterprise needs traceability. It needs evidence. It needs operational context that engineers, risk teams and business owners can understand.

This is one of the biggest gaps I see in AI strategy. Many organizations are investing in models and use cases, but not enough in the control plane required to manage them.

Data readiness is still underestimated

AI has exposed an uncomfortable truth: many enterprises are not as data ready as they think.

Data is often duplicated across platforms, described differently by each team, governed inconsistently and refreshed on different schedules. Access rules may be clear in one system but unclear in another. Even basic business definitions can change from department to department.

AI does not fix that automatically. In many cases, it makes the problem more visible.

A bad report may be questioned. A bad AI answer may sound confident enough to be trusted.

That is a real risk.

Being data-ready for AI is not just about connecting a vector database or indexing documents. It requires clear ownership, lineage, classification, quality checks, retention rules, access boundaries and a shared understanding of which data should be used for which purpose.

The same principle applies to resilient cloud-native design. In my IEEE TechRxiv paper, “Enabling Fault-Tolerant Multicast in Cloud-Native Architectures” I explored how reliability, observability and fault tolerance become foundational requirements when critical workloads stretch across hybrid and multi-cloud environments.

CIOs already understand this because they have lived through enterprise resource planning programs, cloud migration, integration modernization, cybersecurity transformation and analytics initiatives. The lesson is familiar: technology cannot outrun data discipline forever.

Security cannot be added later

As AI moves from answering questions to acting, security becomes much more important.

An assistant that summarizes information carries one level of risk. An agent that can open a ticket, update a record, trigger a workflow, approve a request or contact a customer carries a very different one.

The more AI can do, the more identity, authorization, least privilege, separation of duties and human approval matter.

Enterprises should be careful not to grant AI broad access just to speed up a pilot. That may seem harmless in development, but it can become dangerous at scale.

AI access should be treated like any other privileged enterprise capability: limited, logged, reviewed and easy to revoke.

The NIST AI Risk Management Framework is a useful reference point here because it frames AI risk as something organizations must govern, map, measure and manage continuously rather than something handled only at the end of deployment.

Security teams should be involved early, not at the end. The goal is not to slow innovation. The goal is to build a platform where safe innovation becomes repeatable.

The CIO has to define the operating model

AI is creating pressure from every direction. Boards want productivity. Business teams want automation. Employees want better tools. Vendors are pushing new features. Security teams are watching risk. Finance teams are watching cost. Customers expect faster, smarter experiences.

The CIO sits in the middle of all of it.

That is why the CIO’s role cannot stop at choosing tools or approving pilots. The CIO has to define how AI will actually operate across the enterprise.

That means answering practical questions. Which architecture is approved? Which data sources can be trusted? How are AI workflows deployed, monitored, supported and governed? How are costs controlled? How do teams reuse common patterns instead of rebuilding the same foundation each time?

This work may not be as exciting as a model demo, but it is what separates sustainable AI from short-term experimentation.

The winning organizations will not be the ones with the most pilots. They will be the ones with the strongest AI operating layer.

They will build reusable platform patterns, strengthen data governance, design access properly, monitor AI behavior end to end and measure success by business improvement, not only model performance.

The model still matters. But the enterprise behind the model matters more.

A powerful model on weak infrastructure will eventually disappoint the business. A capable model on strong infrastructure can deliver real value because it can be trusted, secured, scaled and improved.

That is the shift CIOs need to lead.

The next AI bottleneck is not the model. It is whether the enterprise behind the model is ready.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Convenience store and gas station chain Sheetz announced it is replacing VMware across its network of more than 830 retail locations with StorMagic’s SvHCI hyperconverged infrastructure platform, marking one of the larger publicly announced migrations away from VMware.

The rollout is already well underway. According to StorMagic, Sheetz has completed migrations at more than 600 stores and is averaging roughly 200 store conversions per month. At that rate, the company is on track to finish the project in about four months.

The migration is being carried out entirely remotely, eliminating the need for hardware upgrades or on-site IT visits. This lets the chain continue using its existing Dell PowerEdge R440 and R450 servers.

The two companies have a relationship dating back to 2020, when Sheetz first deployed StorMagic’s SvSAN software as the hyperconverged storage layer with VMware across hundreds of store locations to virtualize critical in-store application. The setup supported mission-critical applications such as payment processing, loyalty programs, kitchen management and store operations.

The new deployment replaces VMware entirely with StorMagic’s integrated SvHCI virtualization stack, simplifying infrastructure while reducing software complexity and operating costs.

By employing existing hardware and managing migrations remotely, Sheetz expects to minimize disruption while standardizing virtualization across its nationwide footprint. StorMagic said the completed platform will provide a highly available infrastructure for business-critical in-store applications while extending the useful life of existing server hardware.

“Our initial rollout proved StorMagic could deliver the resilience and centralized management needed across a large, distributed retail environment,” said Gary Sliver, director of platform engineering at Sheetz in a statement.

“StorMagic worked to understand our needs and requirements, to include a 24/7/365 operating environment, and ultimately delivered a product and plan that is allowing us to migrate hundreds of locations from VMware quickly and with minimal downtime, without requiring hardware replacements or having to send technicians to every site. This project is proof that large-scale edge migrations don’t have to be disruptive, drawn-out or scary affairs.”

Viele Unternehmen investieren derzeit mehrstellige Millionenbeträge in die Modernisierung ihrer SAP-Landschaften. Doch nach Einschätzung der Deutschsprachigen SAP-Anwendergruppe (DSAG) wird dabei ein entscheidender Erfolgsfaktor häufig unterschätzt: die Qualifizierung der eigenen Entwickler.

In einer neuen Handlungsempfehlung fordert der Anwenderverband CIOs auf, die Weiterbildung von SAP-Entwicklern nicht als freiwillige Schulungsmaßnahme, sondern als strategisches Investitionsprogramm zu behandeln. Gut ausgebildete Entwickler seien die Voraussetzung für stabile, wartbare Eigenentwicklungen ohne wachsende technische Schulden. Ohne Fortbildung beim Upgrade auf S/4HANA blieben die Potenziale der neuen Technologien ungenutzt.

Veraltetes Know-how wird zum Projektrisiko

Wie die Autoren ausführen, verfügen zwar viele ABAP-Entwickler über jahrzehntelange Erfahrung mit SAP R/3 oder ECC und besäßen umfangreiches Prozesswissen. Mit S/4HANA, Clean Core und ABAP Cloud hätten sich die Entwicklungsparadigmen jedoch grundlegend verändert.

Langfristig drohe dies zu schlechten Architekturentscheidungen, aufwendigen Workarounds und Eigenentwicklungen, die bei jedem Release nachgepflegt werden müssten, zu führen, so die DSAG. Auch viele Business Consultants orientierten sich noch zu stark an klassischen GUI-Transaktionen und berücksichtigten moderne Fiori-Technologien zu wenig.

Die Folge seien sogenannte “Bildungsschulden”, meint die SAP-Anwendervereinigung. Diese blieben zunächst unsichtbar, machten sich später jedoch in Form längerer Projekte, steigender Wartungskosten und einer wachsenden Abhängigkeit von externen Dienstleistern bemerkbar.

Kompetenzaufbau darf nicht erst im Projekt beginnen

Besonders kritisch sehen die DSAG-Autoren den Zeitpunkt der Weiterbildung. Wer erst während eines laufenden S/4HANA-Migrationsprojekts mit dem Kompetenzaufbau beginne, erhöhe das Projektrisiko erheblich. Fehlendes Wissen über CDS, RAP oder Fiori führe zu Architekturentscheidungen, die später teuer korrigiert werden müssten. Gleichzeitig lasse sich der notwendige Lernaufwand kaum parallel zum Tagesgeschäft bewältigen.

Aber auch nach abgeschlossener Migration müssen sich die SAP-Entwickler laut DSAG weiter fortbilden. Wer danach so weiterarbeite wie auf ECC, verpasse die Möglichkeiten aktueller SAP-Technologien – auch wenn technisch alles noch funktioniere, warnen die Autoren. Gleichzeitig könnten sie das Gelernte gleich anwenden, womit sich das neue Wissen verfestigt.

KI ersetzt keine Entwicklerkompetenz

Laut DSAG gilt auch für die Entwicklung im SAP-Umfeld: KI-Werkzeuge können zwar Code erzeugen und erklären. Voraussetzung sei dabei jedoch, dass Entwickler die Ergebnisse auch fachlich bewerten könnten. „Nur wer versteht, was guter SAP-Code ist, kann KI als Beschleuniger einsetzen“, so die Autoren. Andernfalls fungiere KI als Risikoverstärker und beschleunige im schlimmsten Fall lediglich die Entstehung technischer Schulden.

Voraussetzung für den erfolgreichen KI-Einsatz seien deshalb solide Software-Engineering-Kenntnisse, automatisierte Tests und ein Verständnis moderner SAP-Entwicklung.

Die fünf Empfehlungen der DSAG

Die DSAG empfiehlt CIOs deshalb, Weiterbildung fest in ihre Transformationsstrategie zu integrieren. Konkret nennt der Verband fünf Maßnahmen, nämlich:

• verbindliche Lernpfade für unterschiedliche Rollen wie ABAP-, CAP- oder Integrationsentwickler sowie Business Consultants zu definieren,
• geeignete Sandbox- und Testumgebungen bereitzustellen,
• Fortbildungszeiten verbindlich in die Kapazitätsplanung aufzunehmen,
• Schulungen zeitlich mit Migrations- und Modernisierungsprojekten zu verzahnen, sowie
• bestehende DSAG-Leitfäden als Referenzrahmen für die Entwicklung zu nutzen.

Looking ahead just a short time, Apple could hold a powerful position in AI where it most makes sense: deployment.

Not only will the company offer up its own AI models for the kind of tasks millions use ChatGPT to do today, but it will provide more sophisticated on-device agentic models to help users get things done through Siri AI.

Apple also offers limited capacity for more complex tasks through Private Cloud Compute, and, in partnership with the likes of Google in the US and Alibaba in China, the company is giving users a trusted conduit through which to access even more sophisticated AI services. 

Deeply deployable

Critics can say it took Apple a long time to get to this point, but they also seem to think the company has finally got the mix right with its series 27 operating systems. Arriving late to a party doesn’t mean you won’t shine once you get there.

Apple is also coming up the inside lane around frontier AI, with iterative OS and hardware enhancements that mean its devices become increasingly effective for Edge AI use cases, on device — no cloud service required.

The company appears to be digging down into those use cases. Mark Gurman at Bloomberg recently predicted that future M7 Ultra Macs will support as much as 1.5TB RAM, making these systems more than capable of running full weight frontier models in people’s offices, colleges, and homes. 

While that does assume the AI-flationary memory market can supply that much RAM at prices humans can afford, it is also true that people are already running AI clusters using off-the-shelf Mac minis networked over Thunderbolt cables. It’s no stretch to believe this will continue to be the case, and that it will even broaden as the power/performance offered at the high end grows.

What’s wrong with good enough?

When combined with open AI stacks, particularly newly emerging varieties, Apple’s platforms should become leading contenders for private AI services and edge AI. Many business users will leap at the chance to offer their workers powerful, self-hosted, private AI services using one or more daisy-chained Mac Studios or Mac minis. The recent craze in deployment of both Macs to support OpenClaw instances shows they already are.

Ultimately, these different slices of momentum mean I agree with investor Jason Calacanis that Apple is in position to apply a great deal of pressure on OpenAI and Claude just by putting models on their devices. 

It’s also worth thinking about how people use AI today. How many of the queries made in the world right now constitute relatively simple tasks that could be transacted by on-device AI, such as the emerging new version of Apple Intelligence or even smaller LLM models running on device? You can even run PrismML’s 1-bit, 27-billion parameter Bonsai on an iPad using the Locally app, and that’s in the here and now.

What happens? Pretty soon you’ll find people recognize that they can already run the vast majority of their AI-augmented workflows using services they have on their existing device or can access on their on-prem Mac set-ups. And, of course, as people get used to running small tasks locally and larger tasks on premises, the actual space in which they need to turn to cloud-based frontier models will erode. That’s even as companies like PrismML work towards slimming down full-weight models so they don’t need to run on a server at all.

“It’s going to be wild when people have unlimited tokens on their desks,” said Calacanis in a podcast round table discussion.

Who has the most to lose?

The current incarnations of AI felt like they came from nowhere. Most people weren’t aware of the technology until returning to work after the 2022 holiday season. Since then, the industry has proliferated with dozens of competing models, most recently including powerful but affordable frontier models such as Qwen and Kimi.ai.

These models aren’t necessarily all as good as one another, but in many cases for much of what we do, we’ll find them to be good enough. That’s an existential crisis for some, as industry observers now think the inevitable pricing pressure means some services might have over-invested in capacity before finding any way to turn a profit.

Those profit-seeking services are the ones with the most to lose as Apple extends its hardware advantage, democratizing AI access for all while providing platforms suitable for edge AI, on-premises AI, private AI, and even AI access using third-party services. (The need for the latter will shrink as the capabilities of the former get better.)

Cupertino rising

What does this all mean? While the industry remains young, it is already fragmenting. And striding through the dust of that process comes Apple, equipped with the hardware, software, and approach to build its business even as the enterprise of first mover AI services erodes.

You can follow me on social media! Join me on BlueSky,  LinkedIn, Mastodon and subscribe to my daily Apple-related news summaries at The Core.

For diversified enterprises, few operating model questions are as persistent or polarizing as centralization versus decentralization. Decentralization promises speed, ownership, and local responsiveness. Centralization promises efficiency, standardization, and leverage. Both can be right. Both can be wrong. The challenge is that many organizations end up with both models operating at once, without enough clarity about why.

The result of fragmented systems, duplicated capabilities, inconsistent data, rising IT spend, and a complexity tax that compounds over time is familiar to many CIOs. What starts as autonomy can become architectural sprawl. What starts as enterprise leverage can become bureaucracy. And as companies modernize core platforms, integrate data, and scale capabilities like AI, the tension becomes harder to ignore.

Paul Krebs has lived that tension from multiple vantage points. Most recently as CIO and chief transformation officer at Koch Industries, and previously a technology and transformation leader at The Coca-Cola Company, he’s worked in environments where business units value autonomy, enterprise scale matters, and the wrong operating model can slow progress just as easily as the wrong technology architecture.

His conclusion isn’t that CIOs should pick a side, but they need a more intentional form of centralization, one that starts with business architecture, clarifies decision rights, and continually revisits where capabilities should sit as the organization matures.

Centralization: a design choice, not a doctrine

In diversified organizations, decentralization often starts as the default because it aligns with how the business creates value. Local businesses understand their customers, markets, regulatory environments, and operating realities, and giving them decision rights can increase speed and accountability.

In Krebs’ experience, the default model often leaned toward decentralization, he says, with the belief that optimizing for customers and markets would allow different businesses to be as responsive as possible to the specific customers and markets they served. But that logic isn’t complete. Leaders also need to ask whether there’s a compelling case where a more centralized approach can generate additional value, accelerate progress, or optimize investments.

Digital transformation created one of those moments. Krebs recalls around 2016 when Koch challenged its businesses to build multi-year digital transformation roadmaps. The ambition was there, but the capabilities to execute at the necessary pace weren’t evenly distributed. In response, the organization invested more aggressively from the center, building shared services and centers of expertise in areas such as business transformation, enterprise applications, and data and analytics.

The purpose was acceleration, not control. Centralizing those capabilities helped accelerate learnings, capability building, and their ability to deploy new solutions at scale. But the move wasn’t treated as permanent. “There was always a belief that the centralization push should be re-looked at on a regular basis, not thought of as a forever decision,” he says.

Know what belongs at the center

Over time, Krebs learned that  the capabilities most likely to remain centralized were those where scale, consistency, and risk management mattered more than local differentiation. Infrastructure, collaboration platforms, cybersecurity, cloud management, FinOps, and the help desk were natural candidates to remain shared services.

Other areas were more nuanced. Some application capabilities moved back into the businesses as local maturity increased. Many data and insights capabilities also moved closer to the business once teams had built enough muscle to own them. Meanwhile, certain emerging capabilities such as spatial technologies like AR/VR remained centralized because it didn’t yet make sense for each business to build them independently. Many companies have lived this journey as well, for example, with gen AI, which often started with a center of excellence, and then evolved into a more decentralized approach, enabling teams across the business to innovate quickly.

That distinction avoids the trap of treating the enterprise as one uniform operating model. “Both models can be successful, and both have advantages,” he says. “That’s what makes the balance so difficult.”

Centralization provides a clearer path to execution at scale and cleaner decision rights, but it requires change management and careful attention to bureaucracy. Decentralization provides ownership and speed, but it can also over index toward preference versus real differentiation, he adds, while making architecture harder to scale later.

Don’t confuse standardization with centralization

One of the most important distinctions Krebs makes is between centralization and standardization. Many organizations treat them as interchangeable, but they’re not.

“You can have a centralized team that can manage the nuances of different requirements,” Krebs says. “You can also have a centralized standard platform that can be used in a decentralized manner.”

That distinction opens up more operating model choices. A company may centralize a platform but decentralize how business teams configure or use it. It may standardize process patterns while keeping execution close to the region or business unit. It may also centralize architectural governance while allowing local teams to move quickly within defined guardrails.

This is especially important in global organizations, where regional needs are real but not always unique. Krebs advises leaders to examine whether local requirements can be made more generic and reusable. The risk is solving each local requirement as a one-off, so the better path is to understand the underlying requirement, build it in a way that can scale, and still allow local teams to execute within the standard model.

Let business architecture lead technology architecture

Few topics expose the centralization tension more clearly than ERP consolidation. Many diversified companies, particularly those shaped by acquisition, end up with dozens or hundreds of ERP instances. Some leaders push for massive consolidation. Others prefer to build integration layers on top of the existing environment.

Krebs’s starting point is neither technology nor cost. It’s business architecture. “The easiest and most effective path is when the IT or systems architecture follows and aligns to the business architecture,” he says.

If the business is truly going to operate processes separately, separate systems may be appropriate. But if the organization has numerous teams, processes, and tools, leaders need to ask whether there’s enough differentiation and value to justify that complexity.

The same logic applies to M&A. Companies can get into trouble when integration synergies are held hostage by ERP migration timelines. Instead, Krebs advises starting with the business integration strategy. Understand where the synergies are, how the business architecture should come together, and then decide whether the IT architecture needs to be fully integrated, or whether a data layer, reporting platform, or other integration approach can deliver value faster.

Make the cost of complexity visible

CIOs in decentralized companies often face a frustrating dynamic. The business wants autonomy and speed, but the same leadership team still questions why IT spend is high relative to benchmarks. Krebs says the answer starts with cost alignment and visibility.

In environments with a mix of centralized and decentralized services, Krebs saw centralized capabilities like infrastructure, help desk, and security perform well on benchmarks. More decentralized areas, such as BI, reporting, and commercial applications, often had more redundancy and higher cost.

The point isn’t to blame the business but make the economics of complexity visible. CIOs need to show how flexibility in one area may require multiple systems, data stores, or teams elsewhere. “I understand we want flexibility here,” Krebs says. “But leaders must see when that flexibility may cost the company money, and be clear on whether the value justifies it.”

That shifts the conversation from IT cost to business service economics. A single aggregate IT spend number is rarely useful in a decentralized environment. More helpful is a capability-based view that shows which areas are scaled efficiently, which are fragmented, and where the business architecture is driving the technology cost structure.

Revisit the model as maturity changes

For a new CIO entering a decentralized environment, Krebs cautions against immediately declaring that too many things need to be centralized. The better starting point is curiosity. “I would begin with just trying to understand why they’ve made the decisions they have,” he says.

From there, CIOs can engage leaders in a conversation about the target operating model, connecting business architecture to technology, data, and organizational capabilities. Once the direction is clear, he advises CIOs to work with the willing. Find the parts of the organization that already see the need for change, prove the model there, and scale from demonstrated success.

Regardless of execution, though, the right model changes over time. A low-maturity capability may benefit from centralization because the organization needs to build talent, avoid reinventing the wheel, and accelerate learning. As maturity grows, decentralization may make more sense because business teams need flexibility to adapt quickly. Once maturity is high and patterns stabilize, the organization may be ready to centralize again to leverage scale.

“Once I’ve decided I’m going to start with centralized or decentralized, you don’t necessarily need to stay in that model,” Krebs says. “You need to be continually revisiting the operating model as your organization matures and evolves.”

That may be the heart of smart centralization. It rejects the false permanence of operating model decisions, and recognizes that autonomy and scale are both valuable, but in different places, at different times, for different reasons.

For three decades, enterprise software has been a buy-it decision. Packaged software from SAP, Oracle and Salesforce covered roughly 80% of requirements at a fraction of the cost of building. The economics were obvious, and for traditional applications, they still are.

AI is introducing a wrinkle that is forcing even the most committed enterprise software customers to rethink their options. AI is a layer that sits across your data, your processes, and your decisions. Where that layer runs and who controls it is an architecture question, and most of the enterprise community is still treating it as a procurement one.

The appeal of vendor-embedded AI is clear: automated operational decisions, smarter supplier and merchandising choices, and friction-free workflows built into the systems enterprises already rely on. The catch is that these capabilities almost universally depend on your data living in the vendor’s cloud environment. For most large enterprises, it sits on-premises, in hyperscale cloud infrastructure they manage themselves, or in private data centers. That gap between where your data is and where your vendor’s AI assumes it should be creates a fundamental strategic fork in the road.

Build vs. buy is a category error

The framing I keep hearing is “build vs. buy your AI strategy.” It implies that some organizations are out there training foundation models from scratch. Nobody serious is doing that. The real choice sits across three distinct approaches, and conflating them leads to poor decisions:

• Buy embedded. Use the AI capabilities your vendor ships natively inside their platform: the assistant baked into your ERP, your CRM, your HCM suite. Lowest integration cost, fastest time to value, tightest fit with the application data.
• Buy platform. Adopt the vendor’s AI infrastructure layer and build your own assistants and agents on top of it. More flexible, but you remain inside the vendor’s architectural boundary and subject to their governance model.
• Compose. Connect a third-party model (Claude, GPT, Gemini, an open-weight model running in your own environment) directly to your existing landscape. Maximum control, maximum integration burden, and full responsibility for what comes out the other end.

These are not equivalent options at different price points. They make different assumptions about where your data lives, who governs the AI, and how much architectural change you’ll absorb to get there. Vendor pitches sometimes blur the distinction on purpose. Enterprise leaders can’t afford to.

The vendor AI stack has an assumption baked in

Every embedded AI capability ships with an unstated architectural prerequisite: your data must be where the AI can see it, in the shape it expects, under the governance the vendor enforces.

For organizations with clean, modern cloud estates, that is often a reasonable trade. For the long tail of large enterprises running heavily customized environments on private or hybrid infrastructure, that trade becomes a precondition, one you must meet before the AI conversation can even begin. Whether meeting it makes sense depends on your starting point, your sector’s regulatory posture, and your appetite for migration risk. None of those are uniform across organizations.

That’s the part that gets glossed over in vendor keynotes. The AI demo on stage assumes a destination architecture the audience hasn’t necessarily reached yet. Large enterprise customers are carrying an unusually heavy technology burden right now. Many are simultaneously managing platform modernization programs that have been building for over a decade, alongside pressure to migrate to vendor-managed cloud infrastructure. Sitting above both is a boardroom-level directive to demonstrate meaningful AI progress fast. The vendor path to AI and the boardroom path to AI can diverge sharply, and enterprises need to make selective, strategic decisions about where to adopt AI first to maximize value and minimize risk.

Sovereignty isn’t a slogan, it’s an architecture constraint

The conversation about sovereignty has been hijacked by both sides. One camp treats every SaaS adoption as a sovereignty violation. The other dismisses every sovereignty concern as Luddite resistance. Neither is useful.

What’s happening in real customer conversations – particularly in DACH, public sector, and financial services – is more specific. Organizations are drawing a distinction between running their applications in a vendor’s cloud (which is broadly fine, well understood, decades of precedent) and enriching their data and processes inside a vendor’s AI model (which has less precedent, is harder to reverse, and carries material implications for competitive position).

Enriching your data inside a vendor’s AI model is the genuinely new question, and organizations that conflate it with their existing cloud posture tend to defend the wrong perimeter.

Despite spending around $100 million annually with Amazon, Disney built its own internal AI system to house its corporate intelligence rather than rely on a hyperscaler’s AI offering. The decision came down to control. When your data represents decades of creative and commercial IP, you think carefully about where it lives and who can learn from it. Disney has become more open to SaaS over time. The AI sovereignty question is a separate debate from the SaaS debate and conflating the two leads organizations to the wrong conclusions.

At the other end of the spectrum, enterprises in heavily regulated environments treat data sovereignty as an absolute non-negotiable. Any AI model must run within their controlled environment, especially where sensitive data cannot touch the public internet. GDPR obligations reinforce this instinct across the European market, requiring organizations to maintain clear accountability for how personal data is processed inside AI systems, including vendor-managed ones.

AI-enriched data, meaning models that have learned the shape of your business processes, your supplier negotiations, your customer behavior, carries a different half-life and a different strategic value than the operational data underneath it. That deserves its own architectural decision, separate from your broader cloud strategy.

What this means in practice

Most large enterprise estates will end up with a mix of all three approaches, and where you draw the lines matters more than your overall posture.

Embedded AI capabilities are the right answer for in-application productivity: the assistant inside your ERP workflows, the agent inside your procurement or HR suite. That is where vendor embedding genuinely shines, and attempting to compose your own equivalent is typically a poor use of engineering resources.

Compose belongs elsewhere: in cross-application orchestration, in custom assistants over operational and observability data, and in agents that need to reach across multiple vendor systems and infrastructure layers in ways no single vendor stack will never natively support. Research from McKinsey suggests the most significant near-term productivity gains from enterprise AI will come precisely from these cross-system workflows, rather than from within individual applications. The most interesting enterprise AI work over the next eighteen months lives here, and it doesn’t require waiting for a migration to complete first.

That compose path isn’t free, and it’s important to be honest about the costs. Governance, audit trails, and accountability for hallucinated outputs become your problem, not the vendor’s. Prompt drift and evaluation discipline are real engineering costs that never appear in the proof-of-concept. Those costs scale with the complexity of your landscape and the number of systems your agents touch. Budget for them before deployment, not after your first production incident. None of that is a reason to avoid the path. It’s a reason to staff for it, honestly.

The real question

The build-vs-buy frame survives because it gives executives a binary choice along a familiar axis. AI sits somewhere else entirely.

The question worth putting on the table at your next architecture review is simpler:

Which decisions do we want our vendors’ AI to make, and which do we want to keep on our side of the boundary?

Answer that, and the right build/buy/compose mix flows from it. Skip it, and you will end up with the architecture your vendors prefer – which may or may not be the one your business needs.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The Linux Foundation has launched the x402 Foundation, a new industry body that will oversee the x402 payment protocol, an open standard designed to let AI agents, applications, and APIs pay for digital services over HTTP.

The x402 protocol, originally developed by Coinbase, embeds payment capabilities directly into web interactions, allowing AI agents, APIs, and applications to send and receive payments as part of standard HTTP requests rather than through separate checkout or billing systems, according to the Linux Foundation. The protocol supports multiple payment types, from traditional cards to stablecoins.

“Under the neutral governance of the Linux Foundation, the x402 Foundation will allow developers, financial institutions, cloud providers, and other community members to collaboratively shape the protocol’s development,” the Linux Foundation said in a statement. “This open structure ensures that payments remain highly secure and adaptable, supporting multiple payment types, from traditional cards to stablecoins, without vendor lock-in.”

Forty organizations have joined the x402 Foundation since the Linux Foundation announced plans for the project in April, the statement added.

Members include Amazon Web Services (AWS), Google, Visa, Mastercard, Stripe, American Express, Cloudflare, Coinbase, Fiserv, Ripple, and Shopify, representing cloud providers, payment companies, and financial services firms.

Foundation targets a gap in agent-to-agent commerce

The announcement comes as software vendors add AI agents to business applications and developer platforms. Many of these agents are designed to call APIs, access third-party services, and complete tasks on behalf of users, creating demand for ways to pay for digital services without relying on separate payment systems.

Jim Zemlin, CEO of the Linux Foundation, said AI agents and automated systems are becoming active participants in the global economy but have lacked a native, secure way to transact.

“By bringing together leading companies across finance, technology and more, we’re ensuring that the payment layer of the internet remains neutral, highly interoperable and ready to support digital commerce,” he said in the statement.

The protocol addresses what several founding members described as a structural gap in how the web handles machine-initiated transactions.

How the protocol works

The x402 protocol is based on the HTTP 402 “Payment Required” status code, which was originally defined for internet payments but has seen limited use.

The protocol is intended for transactions involving paid APIs, AI services, cloud computing resources, digital content, and other online services that require payment. The Linux Foundation said it also supports machine-to-machine payments between software applications and can work with multiple payment methods, including traditional payment cards and stablecoins.

Today, developers typically monetize APIs and online services through subscriptions, prepaid credits, API keys, or account-based billing systems. The Linux Foundation said x402 is designed to standardize payment directly within HTTP interactions, allowing applications and AI agents to complete transactions without separate payment flows or custom billing integrations.

Governance structure spans payments, cloud and blockchain sectors

Under the Linux Foundation’s neutral governance model, the x402 Foundation will let developers, financial institutions, cloud providers, and other members collaboratively shape the protocol’s development.

“This open structure ensures that payments remain highly secure and adaptable, supporting multiple payment types, from traditional cards to stablecoins, without vendor lock-in,” the statement added.

Technology vendors have introduced AI agents that can search for information, generate code, analyze documents, and interact with external applications. Many of those systems also rely on APIs and cloud-based services to complete tasks.

According to the Linux Foundation, x402 is designed to provide a standard way for those applications and agents to pay for services during a transaction rather than relying on separate purchasing or billing processes. The foundation said developers can integrate payment capabilities into applications using open web standards across different payment providers and software platforms.

Growing ecosystem

The launch comes as technology vendors begin adding payment capabilities to AI agent platforms.

In May, AWS introduced Amazon Bedrock AgentCore Payments in preview, enabling AI agents to autonomously pay for APIs, Model Context Protocol (MCP) servers, web content, and other agents. AWS had then said the service uses the x402 protocol to negotiate HTTP 402 payment requests while handling wallet authentication, spending controls, and transaction logging.

The Linux Foundation said the x402 Foundation will serve as the neutral home for the protocol as organizations contribute technical specifications, implementation guidance, and future extensions. The Linux Foundation and Coinbase did not respond to requests for additional comment by publication time.

The article originally appeared on InfoWorld.

The Linux Foundation has launched the x402 Foundation, a new industry body that will oversee the x402 payment protocol, an open standard designed to let AI agents, applications, and APIs pay for digital services over HTTP.

The x402 protocol, originally developed by Coinbase, embeds payment capabilities directly into web interactions, allowing AI agents, APIs, and applications to send and receive payments as part of standard HTTP requests rather than through separate checkout or billing systems, according to the Linux Foundation. The protocol supports multiple payment types, from traditional cards to stablecoins.

“Under the neutral governance of the Linux Foundation, the x402 Foundation will allow developers, financial institutions, cloud providers, and other community members to collaboratively shape the protocol’s development,” the Linux Foundation said in a statement. “This open structure ensures that payments remain highly secure and adaptable, supporting multiple payment types, from traditional cards to stablecoins, without vendor lock-in.”

Forty organizations have joined the x402 Foundation since the Linux Foundation announced plans for the project in April, the statement added.

Members include Amazon Web Services (AWS), Google, Visa, Mastercard, Stripe, American Express, Cloudflare, Coinbase, Fiserv, Ripple, and Shopify, representing cloud providers, payment companies, and financial services firms.

Foundation targets a gap in agent-to-agent commerce

The announcement comes as software vendors add AI agents to business applications and developer platforms. Many of these agents are designed to call APIs, access third-party services, and complete tasks on behalf of users, creating demand for ways to pay for digital services without relying on separate payment systems.

Jim Zemlin, CEO of the Linux Foundation, said AI agents and automated systems are becoming active participants in the global economy but have lacked a native, secure way to transact.

“By bringing together leading companies across finance, technology and more, we’re ensuring that the payment layer of the internet remains neutral, highly interoperable and ready to support digital commerce,” he said in the statement.

The protocol addresses what several founding members described as a structural gap in how the web handles machine-initiated transactions.

How the protocol works

The x402 protocol is based on the HTTP 402 “Payment Required” status code, which was originally defined for internet payments but has seen limited use.

The protocol is intended for transactions involving paid APIs, AI services, cloud computing resources, digital content, and other online services that require payment. The Linux Foundation said it also supports machine-to-machine payments between software applications and can work with multiple payment methods, including traditional payment cards and stablecoins.

Today, developers typically monetize APIs and online services through subscriptions, prepaid credits, API keys, or account-based billing systems. The Linux Foundation said x402 is designed to standardize payment directly within HTTP interactions, allowing applications and AI agents to complete transactions without separate payment flows or custom billing integrations.

Governance structure spans payments, cloud and blockchain sectors

Under the Linux Foundation’s neutral governance model, the x402 Foundation will let developers, financial institutions, cloud providers, and other members collaboratively shape the protocol’s development.

“This open structure ensures that payments remain highly secure and adaptable, supporting multiple payment types, from traditional cards to stablecoins, without vendor lock-in,” the statement added.

Technology vendors have introduced AI agents that can search for information, generate code, analyze documents, and interact with external applications. Many of those systems also rely on APIs and cloud-based services to complete tasks.

According to the Linux Foundation, x402 is designed to provide a standard way for those applications and agents to pay for services during a transaction rather than relying on separate purchasing or billing processes. The foundation said developers can integrate payment capabilities into applications using open web standards across different payment providers and software platforms.

Growing ecosystem

The launch comes as technology vendors begin adding payment capabilities to AI agent platforms.

In May, AWS introduced Amazon Bedrock AgentCore Payments in preview, enabling AI agents to autonomously pay for APIs, Model Context Protocol (MCP) servers, web content, and other agents. AWS had then said the service uses the x402 protocol to negotiate HTTP 402 payment requests while handling wallet authentication, spending controls, and transaction logging.

The Linux Foundation said the x402 Foundation will serve as the neutral home for the protocol as organizations contribute technical specifications, implementation guidance, and future extensions. The Linux Foundation and Coinbase did not respond to requests for additional comment by publication time.

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

OpenAI just released ⁠GPT-5.6 Sol, Terra, and Luna. Sol is the flagship. Terra offers much of its intelligence for less money. Luna is cheaper still. Anthropic released ⁠Claude Sonnet 5 at the end of June and Opus 4.8 the month prior, with a little Fable 5 emerging in between. Meanwhile, Google, which seemed to be winning the model wars a few months ago, is now getting shade from Gergely Orosz, who ⁠argues that Gemini has slipped outside the top tier for software development and has been out of the major model release game for eons (May 19).

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

I use ChatGPT and Claude constantly and still have no principled idea which model to choose most of the time. I tend to click whatever looks like the biggest, most expensive option because I don’t know what I’m giving up by choosing something smaller. “Instant” sounds dangerously unserious. “Thinking” sounds expensive but powerful.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Before getting carried away, however, it’s worth considering whether any of this model churn actually matters. After all, a model doesn’t rot. The model an enterprise put into production in March performs just as well in July as it did when the company selected it. “Obsolete” generally means that something better now exists, not that the deployed model suddenly stopped summarizing insurance claims or classifying support tickets. (In other words, once you have something working, the idea that “but maybe Opus 200.2 is better!” is really a FOMO problem, not a performance issue.)

Most enterprise workloads don’t live at the frontier anyway. Extraction, summarization, classification, document comparison, and customer-service assistance often work perfectly well with smaller, cheaper models. OpenAI’s own pitch for the trio of GPT-5.6 models isn’t simply that Sol is better. It’s that ⁠Terra and Luna deliver different combinations of intelligence, latency, and cost. Luna, the cheapest tier, nearly matches the previous generation’s peak performance at less than half the estimated cost, according to OpenAI.

The practical question, of course, is where to start. An enterprise can’t test every model, every reasoning setting, and every price tier before doing any work. So here’s my advice (which I don’t follow in my own work, but I’m not defining enterprise strategy and can be a little price-insensitive). Start with the cheapest credible model that appears capable of the task. Give it a representative set of real examples and, before you start testing, define what counts as good enough. If it passes, stop. If it fails, move up a tier or try a model with strengths better suited to the work.

That sounds almost offensively simple, but it reverses the way many people, including me, use these products. We start with the biggest model because we’re afraid of what we might lose. Enterprises should start lower and require evidence before paying for more intelligence.

There are exceptions, of course. For genuinely difficult work, such as autonomous coding, complex research, or high-stakes reasoning, beginning with a frontier model may save time. But even then, the goal should be to establish a quality ceiling, then test whether a cheaper model can meet it. It’s changing the question from “which model is best?” to “what is the least expensive model that reliably clears the bar for this job?”

For many workloads, that price improvement matters more than a few extra benchmark points. ⁠As I argued back in 2023, following AI hype doesn’t help anyone. If your model strategy depends on whichever benchmark screenshot is circulating on X this week, you don’t have a strategy. Not a viable one, anyway. Pick a model and ignore the noise.

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Frontier improvements aren’t always incremental, making it advantageous to consider an upgrade. Coding is the obvious example. There’s a significant difference between a model that suggests the next few lines of code and one that can inspect a repository, plan a change, use tools, run tests, discover its own mistakes, and keep working for an extended period. That isn’t merely a nicer autocomplete experience. It can reorganize a development workflow.

This is why enterprises can’t simply standardize on an 18-month-old model and declare victory. In some areas, particularly software development and other agentic work, better models can unlock compounding productivity. A model that reliably completes 80% of a bounded task rather than 50% may justify an entirely different division of labor between humans and machines.

Still, that upgrade isn’t free.

Models differ in how they interpret instructions, call tools, manage context, refuse requests, and fail. Prompts and scaffolding tuned for one model can regress when moved to another. Or costs can explode. As one of my Oracle colleagues discovered just this week, running the same tasks in GPT 5.6 was orders of magnitude more expensive than 5.5. The API change may be trivial, but the revalidation and implications are not.

This leaves enterprises caught between two bad options. They can freeze and potentially miss out on meaningful improvements or chase every release and repeatedly test production systems on faith. What to do?

Stop making model bets

The answer is to stop making LLM bets and start making job-to-be-done bets. Stop asking which model is fastest. Instead, figure out what work you are trying to improve. What does a good result look like? How much latency and cost can the workflow tolerate? How wrong can it be before a human must intervene? Once those questions have answers, model selection becomes less opaque.

A difficult code migration may justify GPT-5.6 Sol or Claude Sonnet 5. A repetitive classification task may work just as well with Luna or another smaller model. A regulated workflow may require a model or deployment option that offers particular data controls. Sometimes the correct model is no LLM at all, like when I’m writing this post. Sorry, AI vendors! (At least you won’t get blamed for my mistakes.)

This is where evaluations become the center of enterprise AI strategy. ⁠As I’ve said before, most companies don’t have an AI quality problem so much as an AI measurement problem. Hence, a private evaluation suite built from real company work is the only leaderboard that matters. Does the new model materially improve quality? If so, use it! Does it reduce cost or latency? Again, that’s your free pass to adoption. Does the improvement justify the expense and effort of revalidation? If yes, continue.

Make model releases boring

As important as the model is, keep in mind that AI success always comes back to your company’s data, your company’s workflows, your company’s integrations, etc. That’s the ⁠dull reality behind sexy AI. Retrieval, memory, governance, data quality, observability, and feedback loops aren’t as exciting as a new model launch, but they’re what ultimately make AI truly work.

Again, when it’s time to consider something new, the principle should be to default to the least expensive model that reliably passes your evaluations. Only escalate harder tasks to more capable models when measurement shows that the premium pays. Tip: Make this invisible to employees so that the system routes to the best model for a particular prompt. As dbt Labs’ Jon Lewis expresses it, “The best model is ‘Auto’ and I won’t hear anyone say otherwise.” OpenAI’s own ⁠migration guidance recommends testing models on representative tasks, including trying a lower reasoning level rather than automatically cranking everything to the maximum.

As for me, I’ll probably keep clicking the shiniest option. I don’t have a formal evaluation suite for InfoWorld columns, and the marginal cost is a subscription I already pay. Enterprises don’t get that excuse.

The model of the forward deployed engineer is sweeping through enterprise IT like a gold rush, and I’m concerned that many companies don’t understand what they’re signing up for.

Let’s start with the headline numbers. AWS announced a $1 billion investment in a new Forward Deployed Engineering organization. Google Cloud committed $750 million to expand similar programs. Microsoft has been running Azure-focused embedded engineering teams for years, including partnerships with Accenture to scale forward deployed engineering practices. All three are pitching the same story: We’ll send engineers to work directly with your teams, help you deploy AI, and accelerate your digital transformation. You get top-tier technical talent for free, and we get to partner with you on your journey.

It sounds reasonable on the surface. It sounds collaborative, even generous. But I’ve been in this industry long enough to know that when a multi-billion-dollar company offers you something for free, they’re sure to get much more than they give.

What you actually get

The forward deployed engineer model isn’t new. The consulting industry has been doing some version of it for decades. What makes this different is the scale and the direct financial incentive behind it.

These engineers work for the cloud provider. They’re not your employees. They’re not independent consultants. They’re technically excellent professionals who are being paid to solve your immediate problems while simultaneously building relationships and architectures that favor their employer’s ecosystem. Think about it from their perspective. Those forward engineers are evaluated on whether customers succeed with their employer’s platform. They’re rewarded when enterprises adopt more services from that platform. Their career advancement depends on making AWS, Google Cloud, or Microsoft Azure the obvious choice for all of your technical decisions.

This isn’t a criticism of the individual engineers. Many of them are genuinely talented and genuinely want to help. But they’re operating within a system that rewards specific outcomes, and those outcomes align with the vendor’s financial interests, not necessarily yours.

The problem no one talks about

Here’s what I see happening at enterprises right now. A company decides they need help deploying AI. A cloud provider offers to embed engineers at no additional cost. Those engineers work alongside internal teams, make architectural recommendations, and help build out systems. Six months later, the company has a production AI system running on a single cloud platform, built by people with deep expertise in that specific platform.

The problem? Nobody evaluated whether that platform was actually the best choice for the business. Nobody looked at alternatives. Nobody asked whether a multicloud architecture or best-of-breed approach might deliver better results at lower cost.

The engineers embedded in these programs are not going to recommend that you split your workloads across providers. They’re not going to suggest you use open source tools where they make sense. They’re not going to point you toward a competitor when their employer’s solution will work well enough. That’s not how these programs are designed to function. What you’re getting is optimized architecture for a single cloud brand, not optimized architecture for your business.

The financial reality will hit

The bills are going to come due, and they’re going to be painful. I’ve watched this pattern play out before. When enterprises lock into a single cloud provider through these embedded engineering programs, they often discover two or three years later that they’re paying premiums that their more independent-thinking competitors avoided.

The reasons are straightforward. When you’re architecting systems around a single platform, you naturally fall into usage patterns that favor that platform’s pricing structures. You use their managed databases instead of portable alternatives. You adopt their AI services instead of evaluating third-party options. You build workflows that only work within their ecosystem. And when it comes time to renegotiate or benchmark against alternatives, you find that migrating would cost more than accepting whatever pricing they offer.

I’ve spent the past decade helping companies untangle from these situations. I’ve seen organizations with cloud bills 15 to 20 times higher than they should be, unable to migrate because their entire AI infrastructure is built on proprietary services that only work on one platform. The forward deployed engineer programs are accelerating this problem. They’re making it easier to get into these situations and harder to get out.

Think before you commit

Before you accept one of these programs, consider these three recommendations.

First, require independent architecture oversight from day one. Hire or engage architects who work for your company, not for your cloud provider. They should evaluate every recommendation made by embedded engineers against business requirements and compare options across providers. This isn’t about being suspicious of the engineers. It’s about ensuring that decisions are made with your interests in mind.

Second, demand a clear exit strategy before you begin. Ask the cloud provider to document which proprietary services you’re using, what migration paths exist, and what the cost would be to move to an alternative platform. If they can’t provide that information, or if the migration costs seem impossibly high, that’s a sign that you’re building technical debt that will be very expensive to service later.

Third, benchmark your costs continuously. Set up internal processes to compare your cloud spending against industry benchmarks and against what your competitors might be paying for similar workloads. Don’t wait until your contract renewal to discover that you’re paying premium prices. Monitor expenses from the beginning, and be willing to challenge your cloud provider if you’re not getting value that justifies the cost.

The bottom line

The forward deployed engineers are solving real problems. Enterprises genuinely struggle with AI deployment, and having experienced engineers available to help is valuable. I’m not suggesting these programs are fundamentally bad. However, they’re being marketed as neutral partnerships when they’re actually strategic sales programs designed to lock enterprises into specific platforms. The helpful engineers showing up at your office are building dependencies that will be very difficult to break. The “free” technical assistance is being funded by margins on services you’ll be buying for years.

Go in with your eyes open. Use these programs but add your own independent oversight. Build architectures that you could leave if you needed to. And don’t let the immediate satisfaction of having problems solved today blind you to the financial consequences that will arrive tomorrow.

These days, application developers can take their pick from a vast menu of architectural solutions. We can choose from the well-understood to the experimental, and from blended solutions in between. Several powerful middle-ground technologies that emerged during the cloud revolution have really come of age. Here we’ll take a look at putting together three of the most impressive: GitHub, Vercel, and Firestore.

Each of these is an important tool in its own right that can be used to attack specific problems. In combination, they not only meet the needs of several important application scenarios, but they have a superpower—the ability to dramatically shorten the distance between development and deployment.

There is nothing quite as gratifying as putting your hands on just the right mix of tools for a given need.

A ‘no-ops’ stack built for speed

If your primary goal is sheer development velocity, you would be hard-pressed to top this architecture. This “no-ops” stack collapses the distance between your local IDE and a globally distributed production environment. You are essentially trading the overhead of managing VMs and load balancers for the sheer speed of committing code and watching it deploy automatically.

While each component is highly flexible, adopting them requires a specific, event-driven mindset. There are a few finicky bits to manage, mostly around routing environment variables securely and designing around stateless back-end functions. But the constraints are obvious and well-documented.

Before we look more closely, let’s quickly identify the kinds of apps that are a perfect fit here, along with those that are workable and those that really merit a different approach.

• The sweet spot (deploy and go): AI-mediated applications, asynchronous game back ends, and real-time collaborative B2B dashboards. This architecture perfectly absorbs the unpredictable latency of LLM APIs and instantly syncs state across multiple clients without requiring you to build custom WebSocket infrastructure.
• The middle ground (workable, with trade-offs): Headless e-commerce, moderate IoT telemetry, and apps requiring scheduled batch processing. You will encounter friction if your catalog relies on deeply relational SQL constraints, or if your background reporting jobs take longer than a few minutes and hit serverless execution limits.
• The danger zone (look elsewhere): High-frequency trading, fast-paced action multiplayer games, heavy data ETL pipelines, and core financial ledgers. Serverless architectures cannot natively hold open the persistent WebSockets required for twitch-reflex data, and heavy compute tasks will abruptly time out.

We should mention that these categories are not mutually exclusive. Many enterprise applications, such as a full-scale e-commerce platform, straddle these lines. You might use Vercel and Firestore to build a lightning-fast, reactive storefront that handles ephemeral user state like shopping carts, while simultaneously “stitching in” a managed SQL database like Supabase or PlanetScale. This hybrid approach allows you to maintain the relational integrity required for back-office inventory and financial ledgers and pair it with the front-end velocity this stack provides.

GitHub: the bedrock

I don’t need to introduce you to GitHub. It is a central element of the development landscape. I still remember CVS and SVN with a certain nostalgia, but the enhancements of Git speak for themselves. When combined with the orchestration powers of GitHub, it is no wonder that virtually the whole industry has adopted this type of platform.

Git plus GitHub gives you an enormous amount of power already, in terms of how you can organize and automate your projects. But there is a next-level experience in combining GitHub and Vercel. For JavaScript-based projects, you can take simple GitHub pushes and turn them into instantly deployed clients and serverless functions. It is one of the cleanest and least fiddly ways to move from raw code on your local machine to a globally deployed, full-stack architecture.

Vercel: the nexus

Vercel is more than just a deployment host. It is a control plane that ties this high-velocity, no-ops architecture together. Alongside GitHub and Firestore, Vercel’s deeper strength is its ability to act as an orchestration layer between your reactive front end and external stateful services.

Vercel has a great amount of facility in fine-tuning what branches go to what environment and helpful features like instant rollback. You can just log into Vercel’s dashboard for your project and see the history of deployments and any errors and logs. It’s a simple menu choice to roll back to a historical version or compare one version against another.

When you “stitch in” third-party services (such as a managed SQL database like Supabase or a payment processor like Stripe), Vercel’s serverless functions become the lightweight interface, and Vercel’s the adapters handle the communication. You offload the integration logic (the service layer) to Vercel’s global Edge Network, keeping your UI and back end clean, responsive, and decoupled. 

In short, Vercel allows you to get the speed of the “no-ops” development life cycle without sacrificing the complex transactional integrity required for some applications like enterprise inventory systems.

Firestore: the datastore

Firestore is an extremely lightweight, NoSQL, cloud datastore. It has a great deal of add-on power, but its core value proposition is that it accepts virtually any data you stuff into it and it provides event-driven subscriptions to data changes.

These two capabilities together make Firestore about as straightforward a solution to a managed back end as you can imagine. You subscribe to collections or even fields and then you simply stick “unstructured” data (read: JSON with variable fields) in and the client waits for the changes it is interested in.

This is so streamlined that one can just point the browser (or native mobile app) directly at Firestore and listen for events. Which immediately raises the question of identity, for auth and for data visibility, but hold on—Firestore’s third superpower is that it has an authentication module that actually works. What I mean is, it is actually pretty simple and yet confidently secures your app.

Sometimes auth solutions seem either too simple (and yet opaque) or too mired in the nitty gritty. Firestore auth will let you do some basic configuration and start using a reasonable auth almost immediately. 

Not to belabor the point, but having a realistic and attainable auth solution elevates your stack to a production grade—one that can handle many real-world applications. Firestore auth plays nicely with other important APIs, like Stripe. Typically, auth is a major feature that feels like off-roading in a Honda Civic, but Firestore’s approach to auth, added to this particular stack, feels like a normal speed bump. It’s just another component you plug in, rather than a tentacled alien you weave into the your code.

The limits of the velocity stack

This architecture combines components that are optimized for flexibility. That same character also introduces distinct limitations. Understanding these is essential before committing production workloads.

The serverless life cycle

Serverless functions are spun up to handle requests. They close out soon afterward and lose any state. For that reason, they cannot natively hold open persistent WebSockets. If your system requires continuous, sub-millisecond, bidirectional streams—like a real-time multiplayer action game or a high-frequency trading dashboard—pure serverless will fight you all the way. You are forced to introduce a third-party managed WebSocket service to route messages back to your stateless endpoints via HTTP webhooks.

The execution time ceiling

Vercel (like all serverless platforms) enforces strict timeouts on operations. While enterprise tiers might grant you up to 15 minutes, standard functions often time out after 10 to 60 seconds. Long-running tasks like video transcoding, database scripts, or orchestrating multi-step AI agent workflows, which might take 20 minutes to resolve, will run up against these limits. Heavy-lifting tasks must be offloaded to a dedicated, long-running service like Google Cloud Run, or broken into smaller, asynchronous chunks via message queues.

The cold start reality

While the industry has made massive strides in minimizing initialization times—particularly with lightweight edge networks—traditional Node.js-based serverless functions still experience cold starts. If a function has not been invoked recently, or if traffic spikes require a new instance to spin up concurrently, the first request will take a noticeable latency hit as the container provisions and the code loads.

API instead of RAM

In a traditional server environment, you can store transient data in global RAM, allowing subsequent requests to access shared context instantly. In the serverless model, every request might hit a fresh container. Therefore, all shared context must be externalized. Although Firestore serves brilliantly as the state manager, relying on a database for high-frequency, sub-millisecond, ephemeral caching introduces network latency and per-operation costs. That said, using a shared RAM state on a server is non-trivial also, unless you are using a single app server and VM (because high-availability or fail-over requirements will lessen the RAM win on a traditional server).

Tuning for velocity and control

Every architectural decision is a trade-off. There are no cost-free choices. By adopting the GitHub, Vercel, and Firestore stack, you are explicitly maximizing feature velocity over fine-grained control.

You lose the ability to tweak the underlying operating system, hold open persistent sockets, or run hour-long back-end scripts. In exchange, you gain an architecture that scales from zero to global distribution instantly, requires virtually no devops maintenance, and perfectly absorbs the asynchronous, event-driven realities of modern application development.

For the right application—whether it is a fast-moving prototype or an enterprise AI copilot—this stack doesn’t just save time; it fundamentally changes how quickly a small team (or a single person) can impact the market. You stop worrying about build chains, load balancers, and server patches, and you focus on the central mission: shipping features.

Deluxe may have prevailed against the odds when it successfully migrated from a 50-plus-year-old mainframe recently.

The company was able to move from it to a cloud environment in about 12 months without a major hitch, and while AI did some of the heavy lifting. The save will amount to about $4.9 million a year by retiring old hardware and software, cutting labor costs, and consolidating IT resources.

Deluxe, based in Minneapolis and traditionally known as a check printer, has transformed itself into a payments IT provider in recent years. But it desperately needed to end its reliance on its ancient mainframe, says Yogaraj Jayaprakasam, the company’s chief technology and digital officer, pictured.

So AI played a huge role in the IT modernization project, he says, using it to rewrite the old mainframe code, generate documentation, and regenerate code test cases. The company also used an AI-powered test automation suite, as well as AI tools to help move assets to the new cloud environment.

While AI can’t do everything during mainframe migration, it can make the move easier, Jayaprakasam says. “The biggest lessons learned is AI is one of the missing tools in your transformation tool set,” he adds.

Failing projects

Deluxe’s mainframe migration earned it a 2026 CIO 100 Award for IT innovation and leadership, but it also seems to have bucked a recent trend. Many mainframe migration projects haven’t gone as planned, and Gartner recently predicted that more than 70% of mainframe exit projects that started in 2026 will fail to produce intended benefits because of an overreliance on gen AI.

Mainframe transformation projects tend to work better when they’re part of a larger business transformation rather than a one-off project using gen AI to do most of the work, says Gartner analyst Alessandro Galimberti.

“Generative AI and agentic AI are extremely powerful, but they also have their own limits,” he says. “With all these kinds of tools trying to convert code or somehow fit into a non-mainframe workload, we don’t really see a track record of success.”

Gartner also sees a declining interest in mainframe migration projects, Galimberti says. With mainframes getting support from several IT vendors, and with a general lack of migration success, many companies are choosing to keep many workloads on their existing big iron.

But mainframes also have a proven track record of very high uptime and backward capability, Galimberti says.

“If I’m a bank, a financial institution, or a transportation company, I need to run applications that are the core of my business,” he adds. “I need reliability, transactional integrity, and security, and these applications have a low change rate over the years because they map very stable business processes.”

The Gartner prediction makes sense to John McKenny, senior VP and GM of Intelligent Z optimization and transformation for mainframe support vendor BMC Software.

“With organizations thinking about mainframe exits, the expected benefits they’re looking for are usually pretty straightforward,” he says. “They think, ‘It’s going to be lower cost, I’m going to get equal or better capabilities, I should be more agile.’  The reality is those outcomes rarely show up at scale.”

Mainframe migration is possible, but the successful projects tend to be small scale, McKenny adds. He was on a recent call about a failed migration project in Europe, with a large bank cancelling the project at the end of 2025 and recommitting to the mainframe as a strategic platform.

“I’ve never seen a large-scale mainframe migration project finish under budget, ever,” he says. “Most of the projects I hear about fail outright.”

Trying again

Like some organizations that Gartner has observed, Deluxe tried to move away from its mainframe several years ago, but the project failed, Jayaprakasam says. Yet the company took the steps it needed this time to ensure the new migration succeeded.

While a mainframe migration isn’t for every organization, the latest move made sense for Deluxe, he says.

The mainframe, after all, was the backbone for a large portion of the company’s annual revenue, and interfaces with several top banks across North America. The modernization effort rebuilt core business processes and data, moving them from the mainframe to a modern cloud-native technology stack, including Salesforce, Mulesoft, and SAP S4/HANA.

While AI played a big part, there’s danger in overestimating the power of AI during a migration project, Jayaprakasam says, and organizations need to follow best practices for IT migration.

“If you minimize the importance of communication, risk planning, and business alignment because you have AI, you tend to fail,” he says. “But as long as you play all those cards and recognize AI was the missing piece to the puzzle, then you have a much better chance of winning.”

Deluxe also used a cross-functional tiger team to look at the various options available to accelerate reverse engineering, including AI tools from OpenAI, Anthropic, as well as GitHub Copilot throughout the project.

In addition, AI was useful to dig through the mainframe code and understand what needed to be updated, Jayaprakasam says. Organizations sitting on decades-old code often no longer have people who understand it.

“I always tell people that the code remembers what the organization forgot, because with people going and changing, people don’t remember what we wrote in the code, but the code remembers,” he adds. “The amazing tool that was missing before is we didn’t have an interpreter who understood what the code remembered. Now with AI, you have the interpreter.”

Django is a one-size-fits-all Python web framework that was inspired by Ruby on Rails and uses many of the same metaphors to make web development fast and easy. Fully loaded and flexible, Django has become one of Python’s most widely used web frameworks.

Now in version 6.0, Django includes virtually everything you need to build a web application of any size, and its popularity makes it easy to find examples and help for various scenarios. Plus, Django provides tools to allow your application to evolve and add features gracefully, and to migrate its data schema if there is one.

Django also has a reputation for being complex, with many components and a good deal of “under the hood” configuration required. In truth, you can use Django to get a simple Python application up and running in relatively short order, then expand its functionality as needed.

This article guides you through creating a basic application using Django 6.0. We’ll also touch on the most crucial features for web developers in the Django 6 release.

Installing Django

Assuming you have Python 3.12 or higher installed, the first step to installing Django is to create a virtual environment. Installing Django in the venv keeps Django and its associated libraries separate from your base Python installation, which is always a good practice.

Next, install Django in your chosen virtual environment via Python’s pip utility:

pip install django

This installs the core Django libraries and the django-admin command-line utility used to manage Django projects.

Creating a new Django project

Django instances are organized into two tiers: projects and apps.

• A project is an instance of Django with its own database configuration, settings, and apps. It’s best to think of a project as a place to store all the site-level configurations you’ll use.
• An app is a subdivision of a project, with its own route and rendering logic. Multiple apps can be placed in a single Django project.

To create a new Django project from scratch, activate the virtual environment where you have Django installed. Then enter the directory where you want to store the project and type:

django-admin startproject 

The is the name of both the project and the subdirectory where the project will be stored. Be sure to pick a name that isn’t likely to collide with a name used by Python or Django internally. A name like myproj works well.

The newly created directory should contain a manage.py file, which is used to control the app’s behavior from the command line, along with another subdirectory (also with the project name) that contains the following files:

• An __init__.py file, which is used by Python to designate a subdirectory as a code module.
• settings.py, which holds the settings used for the project. Many of the most common settings will be pre-populated for you.
• urls.py, which lists the routes or URLs available to your Django project, or that the project will return responses for.
• wsgi.py, which is used by WSGI-compatible web servers, such as Apache HTTP or Nginx, to serve your project’s apps.
• asgi.py, which is used by ASGI-compatible web servers to serve your project’s apps. ASGI is a relatively new standard for asynchronous servers and applications, and requires a server that supports it, like uvicorn. Django only recently added native support for asynchronous applications, which will also need to be hosted on an async-compatible server to be fully effective.

Next, test the project to ensure it’s functioning. From the command line in the directory containing your project’s manage.py file, enter:

python manage.py runserver

This should start a development web server available at http://127.0.0.1:8000/. Visit that link and you should see a simple welcome page that tells you the installation was successful.

Note that the development web server should not be used to serve a Django project to the public. It’s solely for local testing and is not designed to scale for public-facing applications.

Creating a Django application

Next, we’ll create an application inside of this project. Navigate to the same directory as manage.py and issue the following command:

python manage.py startapp myapp

This creates a subdirectory for an application named myapp that contains the following:

• A migrations directory: Contains code used to migrate the site between versions of its data schema. Django projects typically have a database, so the schema for the database—including changes to the schema—is managed as part of the project.
• admin.py: Contains objects used by Django’s built-in administration tools. If your app has an admin interface or privileged users, you will configure the related objects here.
• apps.py: Provides configuration information about the app to the project at large, by way of an AppConfig object.
• models.py: Contains objects that define data structures, used by your app to interface with databases.
• tests.py: Contains any tests created by you and used to ensure that your site’s functions and modules are working as intended.
• views.py: Contains functions that render and return responses.

To start working with the application, you need to first register it with the project. Edit myproj/settings.py as follows, adding a line to the top of the INSTALLED_APPS list:

INSTALLED_APPS = [
    "myapp.apps.MyappConfig",
    "django.contrib.admin",
    ...

If you look in myproj/myapp/apps.py, you’ll see a pre-generated object named MyappConfig, which we’ve referenced here.

Adding routes and views to your Django application

Django applications follow a basic pattern for processing requests:

• When an incoming request is received, Django parses the URL for a route to apply it to.
• Routes are defined in urls.py, with each route linked to a view, meaning a function that returns data to be sent back to the client. Views can be located anywhere in a Django project, but they’re best organized into their own modules.
• Views can contain the results of a template, which is code that formats requested data according to a certain design.

To get an idea of how all these pieces fit together, let’s modify the default route of our sample application to return a custom message.

Routes are defined in urls.py, in a list named urlpatterns. If you open the sample urls.py, you’ll see urlpatterns already predefined:

urlpatterns = [
    path('admin/', admin.site.urls),
]

The path function (a Django built-in) takes a route and a view function as arguments and generates a reference to a URL path. By default, Django creates an admin path that is used for site administration, but we need to create our own routes.

Add another entry, so that the whole file looks like this:

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path('admin/', admin.site.urls),
    path('myapp/', include('myapp.urls'))
]

The include function tells Django to look for more route pattern information in the file myapp.urls. All routes found in that file will be attached to the top-level route myapp (e.g., http://127.0.0.1:8080/myapp).

Next, create a new urls.py in myapp and add the following:

from django.urls import path
from . import views

urlpatterns = [
    path('', views.index)
]

Django prepends a slash to the beginning of each URL, so to specify the root of the site (/), we just supply a blank string as the URL.

Now, edit the file myapp/views.py so it looks like this:

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world!")

django.http.HttpResponse is a Django built-in that generates an HTTP response from a supplied string. Note that request, which contains the information for an incoming HTTP request, must be passed as the first parameter to a view function.

Stop and restart the development server, and navigate to http://127.0.0.1:8000/myapp/. You should see “”Hello, world!” appear in the browser.

Adding routes with variables in Django

Django can accept routes that incorporate variables as part of their syntax. Let’s say you wanted to accept URLs that had the format year/. You could accomplish that by adding the following entry to urlpatterns:

path(‘year/’, views.year)

The view function views.year would then be invoked through routes like year/1996, year/2010, and so on, with the variable year passed as a parameter to views.year.

To try this out for yourself, add the above urlpatterns entry to myapp/urls.py, then add this function to myapp/views.py:

def year(request, year):
    return HttpResponse('Year: {}'.format(year))
    

If you navigate to /myapp/year/2010 on your site, you should see Year: 2010 displayed in response. Note that routes like /myapp/year/rutabaga will yield an error because the int: constraint on the variable year allows only an integer in that position. Many other formatting options are available for routes.

Django templates and template partials

You can use Django’s built-in template language to generate web pages from data.

Templates used by Django apps are stored in a directory that is central to the project: /templates//. For our myapp project, the directory would be myapp/templates/myapp/. This directory structure may seem awkward, but allowing Django to look for templates in multiple places avoids name collisions between templates with the same name across multiple apps.

In your myapp/templates/myapp/ directory, create a file named year.html with the following content:

Year: {{year}}

Any value within double curly braces in a template is treated as a variable. Everything else is treated literally.

Modify myapp/views.py to look like this:

from django.shortcuts import render
from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world!")

def year(request, year):
    data = {'year':year}
    return render(request, 'myapp/year.html', data)

The render function—a Django “shortcut” (a combination of multiple built-ins for convenience)—takes the existing request object, looks for the template myapp/year.html in the list of available template locations, and passes the dictionary data to it as context for the template. The template uses the dictionary as a namespace for variables used in the template. In this case, the variable {{year}} in the template is replaced with the value for the key year in the dictionary data (that is, data["year"]).

The amount of processing you can do on data within Django templates is intentionally limited. Django’s philosophy is to enforce the separation of presentation and business logic whenever possible. Thus, you can loop through an iterable object, and you can perform if/then/else tests, but modifying the data within a template is discouraged.

For instance, you could encode a simple “if” test this way:

{% if year > 2000 %}
21st century year: {{year}}
{% else %}
Pre-21st century year: {{year}}
{% endif %}

The {% and %} markers delimit blocks of code that can be executed in Django’s template language.

If you want to use a more sophisticated template processing language, you can swap in something like Jinja2 or Mako. Django includes back-end integration for Jinja2, but you can use any template language that returns a string—for instance, by returning that string in an HttpResponse object, as in the case of our “Hello, world!” route.

In versions 6 and up, Django supports template partials, a way to create portions of a template that can be defined once and reused throughout a template. This lets you precompute a given value once over the course of a given template—such as a fancy display version of a user name—and re-use it without having to recompute it each time it’s displayed.

Doing more with Django

What you’ve seen here covers only the most basic elements of a Django application. Django includes a great many other components for use in web projects. Here’s a quick overview:

• Databases and data models: Django’s built-in ORM lets you define data structures and relationships between them, as well as migration paths between versions of those structures.
• Forms: Django provides a consistent way for views to supply input forms to a user, retrieve data, normalize the results, and provide consistent error reporting. Django 6 added support for Content Security Policy, a way to prevent submitted forms from being vulnerable to content injection or cross-site scripting (XSS) attacks.
• Security and utilities: Django includes many built-in functions for caching, logging, session handling, handling static files, and normalizing URLs. It also bundles tools for common security needs like using cryptographic certificates or guarding against cross-site forgery protection or clickjacking.
• Tasks: Django 6 added a native mechanisms for creating and managing long-running background tasks, without holding up a response to the user. Note that Django only provides ways to set up and keep track of tasks; it doesn’t include the actual execution mechanism. The only included back ends for tasks are for testing, so you will either need to add a third-party solution or write your own using Django’s back-end task code as a base.

When it comes to working with data in a tabular form, most people reach for a spreadsheet. That’s not a bad choice: Microsoft Excel and similar programs are familiar and loaded with functionality for massaging tables of data. But what if you want more control, precision, and power than Excel alone delivers?

In that case, the open source Pandas library for Python might be what you are looking for. Pandas augments Python with new data types for loading data fast from tabular sources, and for manipulating, aligning, merging, and doing other processing at scale.

Your first Pandas data set

Pandas is not part of the Python standard library. It’s a third-party project, so you’ll need to install it in your Python runtime with pip install pandas. Once installed, you can import it into Python with import pandas.

Pandas gives you two new data types: Series and DataFrame. The DataFrame represents your entire spreadsheet or rectangular data, whereas the Series is a single column of the DataFrame. In Python terms, you can think of the Pandas DataFrame as a dictionary or collection of Series objects. You’ll also find later that you can use dictionary- and list-like methods for finding elements in a DataFrame.

You typically work with Pandas by importing data from some other format. A common external tabular data format is CSV, a text file with values separated by commas. If you have a CSV handy, you can use it. For this article, we’ll be using an excerpt from the Gapminder data set prepared by Jennifer Bryan from the University of British Columbia.

To begin using Pandas, we first import the library. Note that it’s a common practice to alias the Pandas library as pd to save some typing:

import pandas as pd

To start working with the sample data in CSV format, we can load it in as a dataframe using the pd.read_csv function:

df = pd.read_csv("./gapminder/inst/extdata/gapminder.tsv", sep='t')

The sep parameter lets us specify that the file is tab-delimited rather than comma-delimited.

Once you’ve loaded the data, you can use the .head() method on the dataframe to peek at its formatting and ensure it’s loaded correctly. .head() is a convenience method used to display the first few rows of a dataframe for quick inspection. The results for the Gapminder data should look like this:

print(df.head())
       country continent  year  lifeExp       pop   gdpPercap
0  Afghanistan      Asia  1952   28.801   8425333  779.445314
1  Afghanistan      Asia  1957   30.332   9240934  820.853030
2  Afghanistan      Asia  1962   31.997  10267083  853.100710
3  Afghanistan      Asia  1967   34.020  11537966  836.197138
4  Afghanistan      Asia  1972   36.088  13079460  739.981106

Dataframe objects have a shape attribute that reports the number of rows and columns in the dataframe:

print(df.shape)
(1704, 6) # rows, cols

To list the names of the columns themselves, use .columns:

print(df.columns)
Index(['country', 'continent', 'year', 'lifeExp',
'pop', 'gdpPercap'], dtype='object')

Dataframes in Pandas work much the same way as they do in other languages, such as Julia and R. Each column, or Series, must be the same type, whereas each row can contain mixed types. For instance, in the current example, the country column will always be a string, and the year column is always an integer. We can verify this by using .dtypes to list the data type of each column:

print(df.dtypes)
country object
continent object
year int64
lifeExp float64
pop int64
gdpPercap float64
dtype: object

For an even more explicit breakdown of your dataframe’s types, you can use .info():

df.info() # information is written to console, so no print required

RangeIndex: 1704 entries, 0 to 1703
Data columns (total 6 columns):
 #   Column     Non-Null Count  Dtype
---  ------     --------------  -----
 0   country    1704 non-null   object
 1   continent  1704 non-null   object
 2   year       1704 non-null   int64
 3   lifeExp    1704 non-null   float64
 4   pop        1704 non-null   int64
 5   gdpPercap  1704 non-null   float64
dtypes: float64(2), int64(2), object(2)
memory usage: 80.0+ KB

Each Pandas data type maps to a native Python data type:

• object is handled as a Python str type. (More on this below.)
• int64 is handled as a Python int. Note that not all Python ints can be converted to int64 types; anything larger than (2 ** 63)-1 will not convert to int64.
• float64 is handled as a Python float (which is a 64-bit float natively).
• datetime64 is handled as a Python datetime.datetime object. Note that Pandas does not automatically try to convert something that looks like a date into date values; you must tell Pandas you want the conversion done for a specific column.

Any data that’s not a native Pandas type—essentially, anything that’s not a number—is stored as a generic NumPy type named object. If you have an object column in a dataframe, it’s worth making sure that data is not being used as part of any computational work, as you’ll get none of the performance benefits of using a numerical type (int64, float64, etc.).

Traditionally, strings have been represented as an object. As of Pandas 2.3 or higher, there’s an option to use a new dedicated str type, which has better Panda-native behaviors (such as a more explicit type for the data and more efficient storage). To enable this behavior, you’d use the command pd.options.future.infer_string = True at the top of your code.

Pandas columns, rows, and cells

Now that you’re able to load a simple data file, you want to be able to inspect its contents. You could print the contents of the dataframe, but most dataframes are too big to inspect by printing.

A better approach is to look at subsets of the data, as we did with df.head(), but with more control. Pandas lets you use Python’s existing syntax for indexing and creating slices to make excerpts from dataframes.

Extracting Pandas columns

To examine columns in a Pandas dataframe, you can extract them by their names, positions, or by ranges. For instance, if you want a specific column from your data, you can request it by name using square brackets:

# extract the column "country" into its own dataframe
country_df = df["country"]

# show the first five rows
print(country_df.head())
| 0 Afghanistan
| 1 Afghanistan
| 2 Afghanistan
| 3 Afghanistan
| 4 Afghanistan
Name: country, dtype: object

# show the last five rows
print(country_df.tail())
| 1699  Zimbabwe
| 1700  Zimbabwe
| 1701  Zimbabwe
| 1702  Zimbabwe
| 1703  Zimbabwe
| Name: country, dtype: object

If you want to extract multiple columns, pass a list of the column names:

# Looking at country, continent, and year
subset = df[['country', 'continent', 'year']]

print(subset.head())
       country continent  year
| 0  Afghanistan    Asia  1952
| 1  Afghanistan    Asia  1957
| 2  Afghanistan    Asia  1962
| 3  Afghanistan    Asia  1967
| 4  Afghanistan    Asia  1972

print(subset.tail())
         country continent    year
| 1699  Zimbabwe    Africa    1987
| 1700  Zimbabwe    Africa    1992
| 1701  Zimbabwe    Africa    1997
| 1702  Zimbabwe    Africa    2002
| 1703  Zimbabwe    Africa    2007

Subsetting rows

If you want to extract rows from a dataframe, you can use one of two methods.

.iloc[] is the simplest method. It extracts rows based on their position, starting at 0. For fetching the first row in the above dataframe example, you’d use df.iloc[0].

If you want to fetch a range of rows, you can use .iloc[] with Python’s slicing syntax. For instance, for the first 10 rows, you’d use df.iloc[0:10]. And if you wanted to obtain the last 10 rows in reverse order, you’d use df.iloc[::-1].

If you want to extract specific rows, you can use a list of the row IDs; for example, df.iloc[[0,1,2,5,7,10,12]]. (Note the double brackets—that means you’re providing a list as the first argument.)

Another way to extract rows is with .loc[]. This extracts a subset based on labels for rows. By default, rows are labeled with an incrementing integer value starting with 0. But data can also be labeled manually by setting the dataframe’s .index property.

For instance, if we wanted to re-index the above dataframe so that each row had an index using multiples of 100, we could use df.index = range(0, len(df)*100, 100). Then, if we used, df.loc[100], we’d get the second row.

Subsetting columns

If you want to retrieve only a certain subset of columns along with your row slices, you do this by passing a list of columns as a second argument:

df.loc[[rows], [columns]]

For instance, with the above dataset, if we want to get only the country and year columns for all rows, we’d do this:

df.loc[:, ["country","year"]]

The : in the first position means “all rows” (it’s Python’s slicing syntax). The list of columns follows after the comma.

You can also specify columns by position when using .iloc:

df.iloc[:, [0,2]]

Or, to get just the first three columns:

df.iloc[:, 0:3]

All of these approaches can be combined, as long as you remember loc is used for labels and column names, and iloc is used for numeric indexes. The following tells Pandas to extract the first 100 rows by their numeric labels, and then from that to extract the first three columns by their indexes:

df.loc[0:100].iloc[:, 0:3]

It’s generally least confusing to use actual column names when subsetting data. It makes the code easier to read, and you don’t have to refer back to the dataset to figure out which column corresponds to what index. It also protects you from mistakes if columns are re-ordered.

Grouped and aggregated calculations

Spreadsheets and number-crunching libraries all come with methods for generating statistics about data. Consider the Gapminder data again:

print(df.head(n=10))
|    country      continent  year  lifeExp  pop       gdpPercap
| 0  Afghanistan  Asia       1952  28.801    8425333  779.445314
| 1  Afghanistan  Asia       1957  30.332    9240934  820.853030
| 2  Afghanistan  Asia       1962  31.997   10267083  853.100710
| 3  Afghanistan  Asia       1967  34.020   11537966  836.197138
| 4  Afghanistan  Asia       1972  36.088   13079460  739.981106
| 5  Afghanistan  Asia       1977  38.438   14880372  786.113360
| 6  Afghanistan  Asia       1982  39.854   12881816  978.011439
| 7  Afghanistan  Asia       1987  40.822   13867957  852.395945
| 8  Afghanistan  Asia       1992  41.674   16317921  649.341395
| 9  Afghanistan  Asia       1997  41.763   22227415  635.341351

Here are some examples of questions we could ask about this data:

1. What’s the average life expectancy for each year in this data?
2. What if I want averages across the years and the continents?
3. How do I count how many countries in this data are in each continent?

The way to answer these questions with Pandas is to perform a grouped or aggregated calculation. We can split the data along certain lines, apply some calculation to each split segment, and then re-combine the results into a new dataframe.

Grouped means counts

The first method we’d use for this is Pandas’s df.groupby() operation. We provide a column we want to split the data by:

df.groupby("year")

This allows us to treat all rows with the same year value together, as a distinct object from the dataframe itself.

From there, we can use the “life expectancy” column and calculate its per-year mean:

print(df.groupby('year')['lifeExp'].mean())
year
1952 49.057620
1957 51.507401
1962 53.609249
1967 55.678290
1972 57.647386
1977 59.570157
1982 61.533197
1987 63.212613
1992 64.160338
1997 65.014676
2002 65.694923
2007 67.007423

This gives us the mean life expectancy for all populations, by year. We could perform the same kinds of calculations for population and GDP by year:

print(df.groupby('year')['pop'].mean())
print(df.groupby('year')['gdpPercap'].mean())

So far, so good. But what if we want to group our data by more than one column? We can do this by passing columns in lists:

print(df.groupby(['year', 'continent'])
  [['lifeExp', 'gdpPercap']].mean())
                  lifeExp     gdpPercap
year continent
1952 Africa     39.135500   1252.572466
     Americas   53.279840   4079.062552
     Asia       46.314394   5195.484004
     Europe     64.408500   5661.057435
     Oceania    69.255000  10298.085650
1957 Africa     41.266346   1385.236062
     Americas   55.960280   4616.043733
     Asia       49.318544   5787.732940
     Europe     66.703067   6963.012816
     Oceania    70.295000  11598.522455
1962 Africa     43.319442   1598.078825
     Americas   58.398760   4901.541870
     Asia       51.563223   5729.369625
     Europe     68.539233   8365.486814
     Oceania    71.085000  12696.452430

This .groupby() operation takes our data and groups it first by year, and then by continent. Then, it generates mean values from the life-expectancy and GDP columns. This way, you can create groups in your data and rank how they are to be presented and calculated.

If you want to “flatten” the results into a single, incrementally indexed frame, you can use the .reset_index() method on the results:

gb = df.groupby(['year', 'continent'])
[['lifeExp', 'gdpPercap']].mean()
flat = gb.reset_index() 
print(flat.head())
|     year  continent  lifeExp    gdpPercap
| 0   1952  Africa     39.135500   1252.572466
| 1   1952  Americas   53.279840   4079.062552
| 2   1952  Asia       46.314394   5195.484004
| 3   1952  Europe     64.408500   5661.057435
| 4   1952  Oceana     69.255000  10298.085650

Grouped frequency counts

Something else we often do with data is compute frequencies. The nunique and value_counts methods can be used to get unique values in a series, and their frequencies. For instance, here’s how to find out how many countries we have in each continent:

print(df.groupby('continent')['country'].nunique()) 
continent
Africa    52
Americas  25
Asia      33
Europe    30
Oceana     2

Basic plotting with Pandas and Matplotlib

Most of the time, when you want to visualize data, you’ll use another library such as Matplotlib to generate those graphics. However, you can use Matplotlib directly (along with some other plotting libraries) to generate visualizations from within Pandas.

To use the simple Matplotlib extension for Pandas, first make sure you’ve installed Matplotlib with pip install matplotlib.

Now let’s look at the yearly life expectancies for the world population again:

global_yearly_life_expectancy = df.groupby('year')['lifeExp'].mean() 
print(global_yearly_life_expectancy) 
| year
| 1952  49.057620
| 1957  51.507401
| 1962  53.609249
| 1967  55.678290
| 1972  57.647386
| 1977  59.570157
| 1982  61.533197
| 1987  63.212613
| 1992  64.160338
| 1997  65.014676
| 2002  65.694923
| 2007  67.007423
| Name: lifeExp, dtype: float64

To create a basic plot from this, use:

import matplotlib.pyplot as plt
global_yearly_life_expectancy = df.groupby('year')['lifeExp'].mean() 
c = global_yearly_life_expectancy.plot().get_figure()
plt.savefig("output.png")

The plot will be saved to a file in the current working directory as output.png. The axes and other labeling on the plot can all be set manually, but for quick exports this method works fine.

Conclusion

Python and Pandas offer many features you can’t get from spreadsheets. For one, they let you automate your work with data and make the results reproducible. Rather than write spreadsheet macros, which are clunky and limited, you can use Pandas to analyze, segment, and transform data—and use Python’s expressive power and package ecosystem (for instance, for graphing or rendering data to other formats) to do even more than you could with Pandas alone.

Jurassic Park wasn’t really about dinosaurs.

It was about arrogant people building systems they believed were controllable.

“Life finds a way” is probably the most famous line from the entire franchise. Ian Malcolm’s warning that no matter how sophisticated the technology becomes, no matter how expensive the fences are, and no matter how confident the operators feel, nature eventually escapes containment.

And in every movie, it does.

The dinosaurs always get out. The systems fail. Eventually, the humans lose control.

What makes Jurassic Park fascinating is that despite advanced monitoring, complex containment systems and sophisticated operational controls, the outcome never really changes. At its core, the story is about people mistaking visibility for control.

Cybersecurity has the same problem.

For years, security teams have operated under the assumption that with enough tooling, governance, process, maturity and spend, we can build environments that are effectively secure. Maybe not perfect, but secure enough that compromise becomes rare and manageable.

But attackers find a way.

Given enough time, skill or motivation, they eventually identify the weakness nobody considered. The overlooked privilege. The dependency nobody mapped. The misconfiguration hiding behind layers of dashboards, process, and compliance reporting.

We are already seeing this play out. Nation-state attacks are becoming increasingly sophisticated, while AI-driven exploit discovery is beginning to compress vulnerability research from weeks into minutes.

The raptors are learning faster now.

Mistaking visibility for control

That does not mean prevention no longer matters. The fences in Jurassic Park still slowed the dinosaurs down. They created friction. They reduced exposure. Modern security controls do the same thing.

But the failure in Jurassic Park was never simply that the fences broke.

It was that the entire system assumed the fences represented certainty.

Cybersecurity often makes the same mistake.

The industry has become incredibly good at demonstrating preparedness in controlled environments. Dashboards. Compliance reports. Tabletop exercises. RTO metrics. Recovery attestations.

Jurassic Park had dashboards too.

The problem is that visibility is often mistaken for survivability. Organizations can prove they monitored the environment, documented the process, and ran the exercise, while still having very little confidence that the business could continue operating during a genuine systemic failure.

Most organizations still operate with an implicit belief that compromise is exceptional rather than inevitable. Disaster recovery plans, business continuity workshops, and annual tabletop exercises are treated as evidence of resilience. In reality, many of them are carefully controlled simulations of a world that no longer exists.

Traditional disaster recovery was designed for an era where infrastructure changed slowly, applications were relatively static, and dependencies were limited enough that recovery assumptions could remain valid for months or even years.

That world is gone. AI killed it.

Environments now evolve constantly. Cloud infrastructure changes daily. AI-assisted development accelerates release cycles. Applications rely on sprawling third-party ecosystems. APIs connect systems in ways many organizations do not fully understand. Entire workloads appear and disappear dynamically.

The environment you tested last quarter may no longer exist today.

And yet many resilience programs still operate as if annual or quarterly testing provides meaningful confidence.

Most companies do not really test resilience.

They test optimism.

The backup fallacy

And nowhere is this overconfidence more obvious than backups.

Somewhere along the way, organizations confused “having backups” with “being resilient.” Those are not remotely the same thing.

A backup simply proves you stored a copy of something at a specific point in time. It does not prove you can survive.

Most recovery models were designed in the late 90s and early 2000s for relatively static systems and predictable infrastructure. The core philosophy has barely evolved since then, even as environments have become increasingly distributed, ephemeral, and interconnected.

Restoring data is not the same as restoring operations.

Restoring infrastructure is not the same as restoring business functionality. Modern application are complex and rely on ephemeral elements, third party components and applications as well as complex data flows not just data sets.

Very few organizations continuously validate whether they can recover full feature-function applications, maintain operational workflows, preserve data integrity, reconnect dependencies, restore permissions correctly, or continue operating under active attack conditions.

We built incredibly sophisticated telemetry for understanding how we die.

We built almost none for proving we can survive.

That gap is becoming impossible to ignore.

The recent rise of continuous resilience testing and recovery validation is not accidental. It reflects a growing realization that recovery assumptions themselves may no longer be trustworthy.

Static resilience models are struggling to survive dynamic infrastructure.

This is where resilience starts becoming an engineering problem rather than a compliance exercise.

When restoration assumptions fail

Because the real question is no longer, “How quickly can we restore the application?”

The real question is, “What happens if we cannot restore it?”

Jurassic Park repeatedly explored exactly this scenario. The real panic never started when the fences failed. It started when the operators realized they could not regain control quickly enough.

Businesses now face the same risk.

What happens if AWS experiences a prolonged outage? What happens if Azure Identity Services fail globally? What happens if Stripe, Salesforce, Slack, or Microsoft 365 disappear for days rather than hours?

Many organizations do not actually have business continuity strategies for those situations.

They have restoration assumptions.

Twenty years ago, most organizations directly owned large portions of their operational stack. Today, companies increasingly rent critical business capability from a relatively small number of providers.

Identity. Infrastructure. Communications. Payments. Collaboration. Customer operations.

The efficiency gains are enormous.

So is the concentration risk.

Resilience as an engineering discipline

Historically, business continuity planning assumed localized disruption. A building burned down. A regional data center failed. A storm impacted an office. The internet itself was not the dependency.

Today, entire businesses are built on tightly interconnected SaaS and cloud ecosystems where operational survivability depends on third parties remaining continuously available.

We optimized organizations for efficiency, automation, integration, and scale.

Not necessarily survivability.

That is why resilience needs to evolve beyond annual tabletop exercises and static recovery plans.

True resilience is not a binder sitting on a shelf. It is not a workshop performed once a year. It is not a recovery document written against an environment that changed six months ago.

It is a continuous understanding of the environment itself.

It requires live telemetry, operational visibility, dependency awareness, continuous validation, and the ability to adapt under changing conditions.

Adapting to chaos

The survivors in Jurassic Park only succeeded once they stopped pretending the environment was fully controllable and instead adapted to the reality in front of them.

Cybersecurity needs to make the same shift.

Attackers will keep adapting.

AI will accelerate faster than most governance models can handle.

Complexity will continue to outpace our assumptions about control.

The organizations that survive will not necessarily be the ones with the tallest fences. They will be the ones who understand their environments deeply enough to continue operating when control is lost.

The goal was never to eliminate chaos.

It was to survive long enough to adapt to it.

Because resilience is not about preventing chaos.

It is about operating through it.

Because eventually, one way or another, life finds a way.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Every day this past week I did something I suspect millions of other people also did: I stared at an LLM model picker and wondered which one I was supposed to want.

OpenAI just released ⁠GPT-5.6 Sol, Terra, and Luna. Sol is the flagship. Terra offers much of its intelligence for less money. Luna is cheaper still. Anthropic released ⁠Claude Sonnet 5 at the end of June and Opus 4.8 the month prior, with a little Fable 5 emerging in between. Meanwhile, Google, which seemed to be winning the model wars a few months ago, is now getting shade from Gergely Orosz, who ⁠argues that Gemini has slipped outside the top tier for software development and has been out of the major model release game for eons (May 19).

Perhaps Orosz is right. Perhaps he’ll be wrong again in six weeks. Honestly, it’s exhausting.

I use ChatGPT and Claude constantly and still have no principled idea which model to choose most of the time. I tend to click whatever looks like the biggest, most expensive option because I don’t know what I’m giving up by choosing something smaller. “Instant” sounds dangerously unserious. “Thinking” sounds expensive but powerful.

A quick survey of my LinkedIn crowd suggests others also feel my “WHICH MODEL???” pain. More importantly, I suspect most enterprises do, too.

A model doesn’t rot

Before getting carried away, however, it’s worth considering whether any of this model churn actually matters. After all, a model doesn’t rot. The model an enterprise put into production in March performs just as well in July as it did when the company selected it. “Obsolete” generally means that something better now exists, not that the deployed model suddenly stopped summarizing insurance claims or classifying support tickets. (In other words, once you have something working, the idea that “but maybe Opus 200.2 is better!” is really a FOMO problem, not a performance issue.)

Most enterprise workloads don’t live at the frontier anyway. Extraction, summarization, classification, document comparison, and customer-service assistance often work perfectly well with smaller, cheaper models. OpenAI’s own pitch for the trio of GPT-5.6 models isn’t simply that Sol is better. It’s that ⁠Terra and Luna deliver different combinations of intelligence, latency, and cost. Luna, the cheapest tier, nearly matches the previous generation’s peak performance at less than half the estimated cost, according to OpenAI.

The practical question, of course, is where to start. An enterprise can’t test every model, every reasoning setting, and every price tier before doing any work. So here’s my advice (which I don’t follow in my own work, but I’m not defining enterprise strategy and can be a little price-insensitive). Start with the cheapest credible model that appears capable of the task. Give it a representative set of real examples and, before you start testing, define what counts as good enough. If it passes, stop. If it fails, move up a tier or try a model with strengths better suited to the work.

That sounds almost offensively simple, but it reverses the way many people, including me, use these products. We start with the biggest model because we’re afraid of what we might lose. Enterprises should start lower and require evidence before paying for more intelligence.

There are exceptions, of course. For genuinely difficult work, such as autonomous coding, complex research, or high-stakes reasoning, beginning with a frontier model may save time. But even then, the goal should be to establish a quality ceiling, then test whether a cheaper model can meet it. It’s changing the question from “which model is best?” to “what is the least expensive model that reliably clears the bar for this job?”

For many workloads, that price improvement matters more than a few extra benchmark points. ⁠As I argued back in 2023, following AI hype doesn’t help anyone. If your model strategy depends on whichever benchmark screenshot is circulating on X this week, you don’t have a strategy. Not a viable one, anyway. Pick a model and ignore the noise.

Except, of course, when that noise suggests a serious signal.

Sometimes better really is better

Frontier improvements aren’t always incremental, making it advantageous to consider an upgrade. Coding is the obvious example. There’s a significant difference between a model that suggests the next few lines of code and one that can inspect a repository, plan a change, use tools, run tests, discover its own mistakes, and keep working for an extended period. That isn’t merely a nicer autocomplete experience. It can reorganize a development workflow.

This is why enterprises can’t simply standardize on an 18-month-old model and declare victory. In some areas, particularly software development and other agentic work, better models can unlock compounding productivity. A model that reliably completes 80% of a bounded task rather than 50% may justify an entirely different division of labor between humans and machines.

Still, that upgrade isn’t free.

Models differ in how they interpret instructions, call tools, manage context, refuse requests, and fail. Prompts and scaffolding tuned for one model can regress when moved to another. Or costs can explode. As one of my Oracle colleagues discovered just this week, running the same tasks in GPT 5.6 was orders of magnitude more expensive than 5.5. The API change may be trivial, but the revalidation and implications are not.

This leaves enterprises caught between two bad options. They can freeze and potentially miss out on meaningful improvements or chase every release and repeatedly test production systems on faith. What to do?

Stop making model bets

The answer is to stop making LLM bets and start making job-to-be-done bets. Stop asking which model is fastest. Instead, figure out what work you are trying to improve. What does a good result look like? How much latency and cost can the workflow tolerate? How wrong can it be before a human must intervene? Once those questions have answers, model selection becomes less opaque.

A difficult code migration may justify GPT-5.6 Sol or Claude Sonnet 5. A repetitive classification task may work just as well with Luna or another smaller model. A regulated workflow may require a model or deployment option that offers particular data controls. Sometimes the correct model is no LLM at all, like when I’m writing this post. Sorry, AI vendors! (At least you won’t get blamed for my mistakes.)

This is where evaluations become the center of enterprise AI strategy. ⁠As I’ve said before, most companies don’t have an AI quality problem so much as an AI measurement problem. Hence, a private evaluation suite built from real company work is the only leaderboard that matters. Does the new model materially improve quality? If so, use it! Does it reduce cost or latency? Again, that’s your free pass to adoption. Does the improvement justify the expense and effort of revalidation? If yes, continue.

Make model releases boring

As important as the model is, keep in mind that AI success always comes back to your company’s data, your company’s workflows, your company’s integrations, etc. That’s the ⁠dull reality behind sexy AI. Retrieval, memory, governance, data quality, observability, and feedback loops aren’t as exciting as a new model launch, but they’re what ultimately make AI truly work.

Again, when it’s time to consider something new, the principle should be to default to the least expensive model that reliably passes your evaluations. Only escalate harder tasks to more capable models when measurement shows that the premium pays. Tip: Make this invisible to employees so that the system routes to the best model for a particular prompt. As dbt Labs’ Jon Lewis expresses it, “The best model is ‘Auto’ and I won’t hear anyone say otherwise.” OpenAI’s own ⁠migration guidance recommends testing models on representative tasks, including trying a lower reasoning level rather than automatically cranking everything to the maximum.

As for me, I’ll probably keep clicking the shiniest option. I don’t have a formal evaluation suite for InfoWorld columns, and the marginal cost is a subscription I already pay. Enterprises don’t get that excuse.

A new era of customer engagement is taking shape. AI agents are quickly becoming integral to the way businesses serve, support, and sell to customers — able to respond, reason, and take action in ways that go far beyond scripted automation.

Many customer journeys, however, are still built on systems that don’t talk to each other. Customer data lives in one place, channel history in another, and AI agents often operate with only part of the picture. Customers feel the pain when they switch between channels like voice and messaging, get transferred, and have to repeat themselves yet again. It doesn’t matter that they’ve been loyal to a brand for years, every interaction feels like a cold start. That is the conversation gap.

It’s clear that AI isn’t the problem, infrastructure is. Closing the gap requires new building blocks that focus on continuity, so context can carry forward across systems, channels, human agents, and AI agents.

To bridge the gap, at SIGNAL 2026, we are introducing a new conversation layer for the Twilio Platform.

Twilio Conversation Orchestrator, Twilio Conversation Memory, and Twilio Conversation Intelligence are now generally available. Together, they help businesses coordinate interactions, preserve context, and connect human and AI agents so every conversation is more continuous and useful.

In addition to the new Conversations layer, we’re also announcing platform updates that make it easier to build, manage, and scale customer engagement on Twilio — from a reimagined Twilio Console to expanded channels and new voice AI capabilities.

New building blocks for connected conversations

The conversation gap does more than create inconsistent customer experiences. It hurts conversion and retention, increases operational costs, adds integration complexity, and makes agents less productive. The new platform capabilities we’re introducing are designed to fix that by coordinating interactions, maintaining context, and surfacing signals as conversations happen.

Conversation Orchestrator

Conversation Orchestrator helps businesses coordinate interactions across Twilio channels without complex custom logic. Teams can configure it in Console or configure their implementation with the API. It connects interactions into a single thread and manages handoffs between human agents and automated systems.

Conversation Memory

Conversation Memory creates a living, identity-resolved profile by connecting customer data with conversation history and customer traits. That means each interaction starts with the right context. It’s built specifically for LLMs to reduce latency and token usage by surfacing the most relevant details when they matter.

A new Enterprise Knowledge API (now generally available) also allows teams to deliver more relevant experiences and ground interactions in trusted business knowledge such as FAQs, policies, and product documentation.

Conversation Intelligence

Conversation Intelligence provides real-time understanding of live interactions. Using prebuilt and custom LLM-based operators, it can detect changes in sentiment, flag potential escalations, and trigger action during a conversation, not only after it ends.

That gives teams the ability to respond sooner, support agents more effectively, and improve customer outcomes while the conversation is still in progress.

Together, these products help businesses create customer experiences that feel more connected across channels.

Open by design

Twilio remains neutral by design. We start with the premise that you know your business. We aren’t here to prescribe a model, framework, or data strategy. We provide the infrastructure that helps you build customer engagement in the way that works best for your business. You pick the model and agent runtime. You own the data.

That doesn’t mean you need to start from scratch, either. We partnered with Microsoft, AWS, and others to create blueprints that support faster development. We are also introducing an open-source developer toolkit, Twilio Agent Connect (now generally available), that lets your teams connect agents built on any LLM or framework directly to Twilio’s infrastructure.

For developers, this means more flexibility. For businesses, it means less lock-in and the ability to get value from existing investments. For partners, it means more ways to build with Twilio.

A new front door

We are also introducing a reimagined Twilio Console, because as customer engagement grows more complex, managing the infrastructure behind it should feel effortless.

The new Console is a single mission control center that brings your communications, identity, and data into one experience: one login, consistent logs across every surface, an intelligent Console Assistant, transparent billing insights, and streamlined compliance workflows that no longer slow you down.

Over the coming months, we’ll roll out this new Console experience to customers automatically. You can also opt in to gain early access.

More channels, more control, smarter conversations

In addition to these launches, we are announcing several updates that expand customer reach, support enterprise requirements, and make it simpler to build on Twilio.

• Apple Messages for Business (Private beta) and Twilio Email (GA) give teams new ways to reach customers on the channels they already use.
• Data Residency for SMS (EU) (Public beta) enables teams to manage personal data locally to support regional data requirements.
• Conversation Relay enhancements add PCI compliance, HIPAA eligibility, Insights, and support for Deepgram Flux for smarter turn detection — helping AI agents better understand when a person has finished speaking.
• Stripe Projects integration enables developers and AI agents to seamlessly provision Twilio within Stripe Projects in a single, programmable CLI workflow.

Built with our customers

Bringing these new products to life required a close partnership with many beta customers and partners. This helped us understand real-world signals and needs to help make the capabilities robust from the start.

Among dozens of others, Centerfield, Constellation Dealerships, Car Finance 247, and Meera.ai leveraged Twilio to solve their own customer engagement challenges. These teams showed what is possible when businesses carry context forward, act on live conversation signals, and connect AI agents with human teams in the moments that matter.

Car Finance 247, a leading UK online car finance broker, is using Twilio to help recover stalled loan applications. When customers miss a field, need to correct information, or still need to confirm terms and conditions, AI-powered outreach across voice, SMS, and RCS, Conversation Memory tracks the application state. Conversation Orchestrator manages the outreach journey, and Flex helps bring in a human agent as needed. As Reg Rix, Co-Founder and CEO, shared:

“Because the platform remembers where each customer left off, we can pick up right where they stopped, helping them cross the finish line in a way that is modern, responsive, and genuinely helpful.”

Centerfield, a technology company powering AI-driven commerce, helps brands connect with consumers across digital and phone-based journeys. With Twilio, the team is connecting real-time conversation data with customer context to guide agents and AI systems in the moment, standardise what works, and improve performance at scale. As Aniketh Parmar, Chief Technology Officer, said:

“Performance comes down to how well every interaction moves a customer forward. We’re capturing each conversation in real time and applying what we already know about the customer to guide our agents and AI systems in the moment. With the Twilio Platform, including Conversation Orchestrator, Conversation Memory, and Conversation Intelligence, we can see what’s driving conversations so we can standardise what works, eliminate what doesn’t, and continuously improve outcomes at scale.”

Constellation Dealerships is using Twilio’s agent infrastructure to accelerate AI-powered engagement across its dealer network, moving from evaluation to measurable outcomes in days. As Richard Pineault, Director of R&D, shared:

“The value of this partnership is evident—our team progressed from evaluating Twilio’s agent infrastructure to realising measurable outcomes within days. This rapid speed-to-value exemplifies the agility and innovation required to propel the dealership industry into the future.”

Meera.ai is building on Twilio to modernise outbound engagement, replacing repeated manual follow-ups with always-on conversations across voice, SMS, and messaging. Vivek Zaveri, Chief Executive Officer, said:

“Meera.ai has partnered with Twilio since our inception to champion a conversation-first future for commerce. As the industry shifts toward real-time LLM-enabled interactions, Twilio’s Platform and the new Conversations products will help us reach customers in the moment.”

Together, these customers and partners show that the Twilio Platform can help businesses recover stalled journeys, improve live interactions, accelerate time to value, and create more connected experiences across AI agents, human teams, and every customer channel.

The next era of customer engagement starts here

As AI agents own more of customer engagement, businesses need infrastructure that keeps conversations connected across channels, systems, and teams. That means preserving context, coordinating handoffs, and acting on what is happening in real time.

That is what we are building with this next generation of the Twilio Platform: a new layer that connects channels, context, intelligence, and human and AI agents, helping businesses make every digital interaction more connected, more useful, and more amazing.

For 17 years, Twilio has helped builders create better ways for businesses to connect with their customers. In this next era, that connection matters more than ever.

Explore the new Conversations layer, try the products, and let’s build what comes next, together.

IBM is looking to expand the reach of its foundational mainframe portfolio by adding new single frame and rack mounted versions of its Z and LinuxONE systems.

The IBM z17 portfolio adds a single frame and rack mount versions that bring mainframe capabilities into smaller, customizable footprints. The LinuxONE Rockhopper family gets a single frame and rack mount models, plus a new Express rack mount offering, that target new and smaller clients, according to Tina Tarquinio, chief product officer, IBM Z & LinuxONE.

Specifically, the new hardware includes:

• z17 single frame is a fully packaged box in an IBM rack with intelligent power distribution units, delivered as a complete enclosed unit ready to deploy at the edge or other strategically important customer sites.
• z17 rack mount lets customers install IBM Z components directly into their own industry-standard rack, with built-in flexibility for co-location with other technologies.
• LinuxONE Rockhopper 5 is a multi-drawer LinuxONE system for high-density workloads, with on-chip AI acceleration, confidential computing, and postquantum cryptography available in both single frame and rack mount configurations.
• Rockhopper 5 rack mount and Express offerings deliver enterprise-grade Linux, confidential computing, and on-chip AI acceleration in a compact 18U configuration. Designed for organizations supporting a smaller set of workloads, the offering provides a cost-efficient entry point that can scale as business grows, while prioritizing security, resiliency, and performance.

IBM

The new IBM z17 and IBM LinuxONE 5 Rockhopper configurations support up to 82 cores and 18 TB of memory across two processor drawers, representing about a 20% increase in core count and 12% increase in memory capacity over current systems, IBM stated. Single processor capacity of an IBM z17 ME2 provides full speed IBM z/OS configurations including 10% greater throughput per core than IBM z16 A02 with some variation based on workload and configuration, according to Tarquinio.

Both systems feature a 5.5 GHz IBM Telum II processor and a built-in AI accelerator that IBM says will let customers run more than 450 billion inferencing operations in a day with one millisecond response time. In addition, the 32-core Spyre AI accelerator is designed to handle all manner of AI workloads.

The idea is to bring the core strengths of IBM Z to a broader range of deployment models while offering the security, resilience, and performance enterprises depend on, Tarquinio said. 

“As always, we’re continuing to innovate to deliver more with less, including up to 20% more capacity than IBM z16 to help process transactions faster and support growing AI-driven workloads,” Tarquinio said.  “Even the newest and smallest member of the IBM z17 family delivers the performance, efficiency, and scalability organizations need as they balance growth ambitions with real-world resource constraints.”

The Linux-based system, Rockhopper 5 is for organizations that have moved past the evaluation question and are ready to consolidate a substantial portion of their x86 estate, said Marcel Mitran, IBM Fellow and CTO of IBM LinuxONE. 

Rockhopper 5 is designed to bring a smaller physical footprint and a software licensing model that reflects actual workload boundaries rather than physical server counts, Mitran said.

The LinuxONE 5 Express is a preconfigured system designed to get organizations running on LinuxONE quickly, with a defined bill of materials and a predictable starting cost, on the same architecture that the largest enterprises in the world depend on, Mitran said.

“It is built for organizations that want to consolidate a modest x86 estate, evaluate LinuxONE for the first time, or deploy a specific workload such as digital assets, AI-infused transaction processing, or confidential computing, without committing to the footprint of the larger model,” Mitran said.

Some of the mainframes’ software features were also bulked up. For example, IBM said that Post Quantum Cryptography security is now standard on the z17 and LinuxONE Rockhopper 5 systems letting customers start to utilize cryptography to protect core resources for the future.

The idea is to help customers protect long-lived, mission-critical data while reducing the cost and complexity of future cryptographic migration, IBM stated. 

In that vein, IBM said it was bringing Crypto Discovery & Inventory, which lets security teams see what has been encrypted across the enterprise. In addition, IBM announced an Infrastructure Management for Z and LinuxONE package that would let customers administer, monitor, automate, and provision IBM Z and LinuxONE systems from a central location.

IBM said it wants to reduce operational complexity for customers by making automating day-to-day operations to ultimately lower administrative costs and concerns. With the new flexible form factors, IBM continues to target hybrid and AI infrastructure buildouts with the Big Iron. In the AI world, the z17 is being utilized for AI inferencing, transactions, training, and key security applications such as fraud detection and insurance claims.

“Enterprise infrastructure is entering a new phase. Organizations need platforms that can support AI-driven growth while navigating resource constraints, evolving business requirements, and increasingly complex hybrid environments,” Tarquinio said. “They are being asked to deploy new AI capabilities while learning new skills, controlling operational costs, and maximizing the value of existing applications and infrastructure.”

A recent IBM Institute study on mainframe usage stated that embedding mainframe to support AI in executing transactions is not temporary: 75% of executives expect mainframe-based applications to remain central to digital transformation, and 60% say mainframe-based platforms are essential to enabling AI innovation.

”Mainframe-anchored systems of record are becoming systems of intelligent execution—not as general‑purpose AI platforms, but as environments where AI acts directly within transactions and in support of them,” the study reported.

Gartner wrote in its “The State of the IBM Mainframe in 2026” report that IBM’s willingness to make significant investments ensure the mainframe modernizes to remain a vital and thriving component of enterprise IT.  

“Most mainframe customers are now prioritizing the reduction of technical debt and adopting platform innovations to future-proof their mainframe environments for the coming decade,” Gartner wrote.

The new z17 single frame and rack mount configurations, LinuxONE Rockhopper 5, and LinuxONE 5 Express will all be available August 12, 2026. IBM Infrastructure Management for IBM Z and IBM LinuxONE will be available August 14.

Michael Taylor has spent 25 seasons with the Mercedes-AMG Petronas F1 team, working every IT role from trackside support to engineering systems to business transformation. Today, as IT director, he leads an 18-person team responsible for one of the most data-intensive operations in the world.

When a car rolls out of the garage, it carries 300 sensors. When it’s running, it generates more than a million data points per second. Every component, system, and lap produces telemetry that engineers use to find fractions of a second — the difference between winning and losing.

“Formula One has been data-centric for many years,” Taylor says. “The key metric in our sport is the stopwatch, and that’s been true since the World Championship began in the 1950s. But now we instrument everything. If you measure it, you can improve it.”

The challenge isn’t collecting data — Formula One has been streaming live telemetry since the 1980s. It’s making decisions at speed while maintaining the governance that keeps a complex, high-stakes operation running.

For CIOs navigating the pressure to move fast on AI while managing risk, security, and data quality, Taylor’s hard-won lessons from the pit lane offer a useful framework: how to balance speed and control, when to keep humans in the loop, and why “good enough” governance beats perfect governance that never ships.

Innovation vs. stability: ‘A constant battle’

In most enterprises, the tension between innovation and control plays out over quarters or years. In F1, it happens weekly.

“It’s really tough,” Taylor admits. “And something we don’t always get right. This is where we rely on people. Industry experience is really important when making decisions around change.”

The team operates in two distinct modes. Between races, they’re at the factory in Brackley, UK. The site, which is headquarters for the design, manufacturing, and operation of their championship-winning Formula One cars, includes a 60,000-square-meter technology campus. It’s all project and program management, with room for experimentation. But as race weekend approaches, everything shifts to execution.

“We have that kind of normal mode when we’re not racing. We’re back at the factory designing and building and improving,” Taylor explains. “But as we get closer to race weekend, we switch to executing that in the most effective way. We have to not make changes that will impact engineers.”

This duality shapes every technology decision. The same agility that drives innovation during the week must yield to stability when results are on the line. Taylor calls it a “constant battle.”

Modernizing at racing speed

Mercedes-AMG Petronas had run SAP since 1999. The platform underpins the team’s entire design-to-track process — from design release through planning, procurement, manufacturing, testing, and development, all the way to reassembling the car trackside.

“All of those steps are core processes,” Taylor says.

So, when it came time to modernize, the team approached it like a pit stop: planned to the second, executed with precision. They chose RISE with SAP — the vendor’s bundled cloud ERP and migration package — agreeing to the journey in December 2024 and targeting a go-live in August 2025, aligned with the sport’s mandatory two-week shutdown.

“It’s the perfect window to make changes,” Taylor says. “We have to plan everything to perfection so it goes smoothly when we start racing again.”

They finished eight weeks ahead of schedule.

“We are control freaks because of the sport and its time-bound nature,” Taylor says. His team prefers to own and manage systems in-house rather than rely on large systems integrators who “dip their toes in and disappear,” Taylor says. With just 18 people on the IT team, they tap SAP’s expertise for specific problems, then take back the reins. “Once done, we continue to own and manage,” Taylor explains, “and SAP does what they do best.”

The secure path must be the easiest path

Intellectual property in F1 racing has a short shelf life. Once a new component is on the car and photographed in the pit lane, competitors can see it. But that doesn’t diminish the value of what’s behind it.

“The real advantage is not just the part,” Taylor says. “It’s the thinking, the modeling, the simulation, the failure modes, the trade-offs, and the development direction behind it.”

Protecting that requires an offensive security posture. Taylor’s head of information security reports directly to him, and the team actively probes its own defenses.

“Act like, think like, work like a hacker,” Taylor says. “We’re thinking about how we can counter threats without impact on end-users.”

In an engineering-permissive culture where people are empowered to move fast, heavy-handed security backfires. Taylor learned early that perfection is the enemy of progress.

“If security gets in the way of the business, the business will find ways to work around it,” he says. “The job is not to slow the organization down; it’s to make the secure path the easiest path.”

Humans in the loop

With AI evolving weekly, Taylor’s team is running pilots across the organization: machine learning for simulation, agentic workflows in production planning, copilots helping developers write code. But he’s resisting the urge to rush.

“We’re still finding our way,” he says. “There’s no one-size-fits-all. We’re playing with everything available, but in six to ten months we’ll make decisions about what to scale.”

Despite the hype around autonomous AI, Taylor remains committed to human oversight.

“I’m still very much ‘humans should be in the loop,’” he says. “When our workforce is harmonized with AI, that’s where we’ll see real benefit — where it complements our people.”

AI has also raised the bar for data governance. “Good enough now includes stronger visibility, cleaner permissions, and clearer ownership,” Taylor says. “You have to be more deliberate about what data AI is allowed to access.”

Start with consequence

Taylor’s advice to CIOs in other industries wrestling with similar questions is deceptively simple: “Start with consequence, not technology.”

In financial services, it might be customer harm or a regulatory breach. In healthcare, patient safety or loss of public trust. In F1, the consequence of a security failure is loss of competitive advantage.

“Once you understand the consequence, you can decide what needs the strongest control, what needs monitoring, what needs retention, and what simply needs better hygiene,” Taylor says.

It’s a lesson learned over 25 seasons at the edge of what’s technically possible — where decisions happen in milliseconds, and the margin between success and failure is measured in fractions of a second.

It has been a year or so since Microsoft announced its plans to move TypeScript to a new, native runtime based on the Go language. Those first releases were unfinished (you had to compile them yourself) but showed promise, getting close to the expected 10x speed-up. That year has been one of steady progress, with Microsoft recently announcing the delivery of a release candidate build.

This release candidate is ready for use. It installs from npm like previous versions, and like earlier builds it works in much the same way as previous versions of TypeScript, checking types in your code, compiling it to run on ECMAScript-compliant JavaScript engines, and running just about anywhere. In addition, a native preview of the TypeScript language server for Visual Studio Code is available to help you write new TypeScript code and guide you through updating existing applications to the new language features.

All you need to do is enable the TypeScript 7 extension through the Visual Studio command palette and start coding. There’s a lot of work going on to get the new tooling ready for the final release of TypeScript 7, and new versions of the language server are being released almost daily. It’s certainly popular, too, with nearly half a million downloads at the time of writing.

What makes TypeScript 7 so much faster?

So how is this new TypeScript so much faster? Key to the improvements is a shift to a new native compiler built in Go. This has allowed the team to change how it operates, adding parallelization where possible. In some cases, this isn’t easy, such as when type checking large codebases split across many files.

Here TypeScript spawns a small number of checker workers that run across your codebase. They work independently, so can duplicate the work — though the output will be the same. You can choose your own number of checkers, but the more you use, the more memory and CPU will be required.

Large monorepos with many projects require a similar approach with independent builder workers. You’ll need to balance this with the number of checkers in use, as this can cause significant resource issues.

There are some significant language and configuration changes from TypeScript 5 (TypeScript 6 has the same changes, which makes it a useful tool for experimenting with migrations). It’s well worth reading the release candidate documentation to understand how these will affect your code, as well as using the TypeScript 7 extension for Visual Studio Code to identify where you need to make changes.

Working with users to build language tools

One important aspect to the development of TypeScript 7 has been collaboration with existing users of the language and its tooling, as well as using the existing suite of TypeScript test tools that have been used to evaluate other versions. As this update is primarily a port of existing code, rather than a bottom-up rewrite, the underlying language semantics and structure are the same as those used in the original JavaScript codebase, ensuring that code will quickly port from old to new versions.

A major internal collaborator was the Visual Studio Code team, who have been using TypeScript to develop the familiar cross-platform development tool. It’s an important partnership between tool and language, as VS Code is a key TypeScript development tool, hosting TypeScript’s language server and using its compiler to provide debugging and code completion features.

The VS Code team published a long blog post detailing how it has been working with the Go-based TypeScript. The team is both helping to develop the language and beginning the process of moving its codebase to the newer, faster, native platform.

How the VS Code team migrated is a useful case study, one that can help you move your TypeScript development more efficiently and with minimal risk. The team began working with extensions, using daily builds of TypeScript to ensure that bugs and issues could be reported as they occurred and would only have a limited impact as fixes could be rolled out quickly. At the same time, the VS Code team began using a preview version of the TypeScript 7 extension for VS Code, which was being built around the new compiler in parallel with its development.

Bridging development with TypeScript 6

The development of TypeScript 6 as a bridge between TypeScript 5 and TypeScript 7 allowed the VS Code team to transition to code that targeted a newer version of ECMAScript and provided more powerful checks. By moving code from TypeScript 5 to TypeScript 6, developers could validate it with what would become TypeScript 7 language features and get speed and performance boosts while doing so (though nowhere near what TypeScript 7 promised). By completing this first migration of the VS Code codebase, it was possible for developers to be confident that they were ready to shift to the Go-based version when it shipped.

The parallel development of the new language server and extension ensured that by late 2025 it was possible for VS Code development to shift to TypeScript 7, with TypeScript 6 used as a fallback if there were any issues. Those cases could then be reported back to the TypeScript team and used to prioritize development.

As the platform evolved, the use cases for the VS Code team changed. By early 2026 TypeScript 7 was stable and nearly feature-complete, so the team began to use it to build all of their own built-in extensions. This allowed them to rethink their toolchain, changing the bundler from webpack to the one built into esbuild, giving them another speed up. Once that process was tested and working, they could switch all development to TypeScript 7.

Having such a big project take on TypeScript 7 early reaped big rewards, as the resulting virtuous cycle allowed both VS Code and TypeScript to move forward together, fixing issues as they arose and providing valuable feedback. The results speak for themselves. Type checking the entire VS Code codebase is now 7x faster, with most extensions checked in under a second. The only exception was GitHub Copilot, which is almost as big as the editor itself, which type checked in 2.5 seconds.

Compilation has been sped up, dropping from 80 seconds to around 20 seconds. This may not seem a lot, but when you’re compiling and rebuilding and debugging, each change in your code now takes a lot less time. That improves developer productivity and ensures they stay in flow, rather than switching away to check email or Teams each time they start a new build. The same goes for using the language server, where loading the entire project (necessary for error detection and refactoring) now takes 10 seconds rather than a minute.

Lots of little time savings like this add up across a big project and a large team, helping developers stay focused and able to solve problems more effectively. The VS Code blog post notes that it cuts down on coffee runs, which take longer than the load or build that inspire a quick cuppa!

Getting ready for TypeScript 7 in your build pipeline

Microsoft is quick to point out that, while the TypeScript 7.0 release will be production ready, TypeScript 7 won’t have a full programmatic API until the release of TypeScript 7.1. As this won’t be for some time, Microsoft is providing a way to run TypeScript 7 side-by-side with TypeScript 6.

Installing the @typescript/typescript6 compatibility package alongside TypeScript 7 adds a new executable, tsc6, that allows you to modify code that uses the TypeScript 5 API to run using TypeScript 6, by renaming the calls to tsc in your scripts to tsc6. This should allow you to keep building to the latest releases at the same time as starting to experiment with using the new runtime.

It’s not a perfect fix. You do need to do some work to implement npm aliases that allow linters and other low-level tools to work with both versions. You can also provide two different dependencies in your package.json to allow TypeScript 6 (tsc6) and TypeScript 7 (tsc) to run side-by-side. The result is a way to help migrate TypeScript code to the newer platform, delivering more efficient code that runs on a more modern ECMAScript in the meantime.

TypeScript 7 will be a big upgrade, though it has taken surprisingly little time to deliver. With users like the Visual Studio Code team already building on the new release, it’s clear that beginning your own migration should be easier than you might have thought.

The final release is due sometime in July 2026. If you haven’t started looking at TypeScript 7, now is the time to start.

The first time I used Kubernetes in an enterprise setting, I understood the hype. It gives every team the same way to package, deploy and run their apps. No more custom scripts or unique deployment hacks, just one control plane to rule them all. And really, that’s why it’s so popular with big companies: Kubernetes is an open-source system for automating deployment, scaling and management of containerized applications. It says so right on the box, and that’s what people want. But here’s the truth: Kubernetes doesn’t erase operational headaches. It just moves them around.

When your Kubernetes install is small, it feels like rocket fuel for engineers. At enterprise scale, though, suddenly it’s about governance, not just engineering. The game is no longer “Can we get this container running?” It’s “How do hundreds of engineers roll out their stuff safely, consistently, securely and without breaking the bank or burning out the platform team?”

This is where the fun really starts.

YAML isn’t the enemy

Folks new to Kubernetes obsesses over manifests, Helm charts, namespaces, ingress rules, deployments, all that stuff. But they’re not the hardest part once you start scaling. The real beast is standardization.

Every big company I’ve seen ends up with teams going their own way. One group writes beautiful deployment templates. Someone else copies and pastes from a two-year-old manifest. Some folks set resource requirements properly. Others skip them entirely. One team sticks to a strong naming convention, and someone else throws together random namespaces and service accounts that make sense only to them. Individually, this more or less works. At scale, when the whole platform has to operate like one system, it’s a mess.

That’s why I’ll say it: you don’t just need a Kubernetes cluster. You need a paved road. This would involve ensuring that there are approved templates, good deployment patterns, observability, security controls as defaults, good issue escalation processes and accountability.

There is no need for developers to be Kubernetes experts just to release their services. The best enterprise Kubernetes setups work like real products. They let application teams self-serve but never let anyone veer off road without good reason.

RBAC: necessary, but never enough

Security is paramount. Kubernetes supports role-based access control (RBAC), so on paper you can control who does what. In practice, in a big company, RBAC gets confusing fast.

The issue isn’t that engineers ignore security. It’s that permissions grow over time. You need a quick fix during an incident, so you give a service account more access. Maybe a team needs cluster-wide rights for a migration. That “just for now” permission sticks around because no one cleans it up. Month by month, the gap widens between what a workload should do and what it’s actually allowed to do. The only thing that works long-term: treat RBAC as a living thing, not a one-time checklist. Review it. Test it. Stick to least privilege. Service accounts get only what they need. Cluster-admin rights? Rare. Expiring exceptions. Set permissions as code so changes aren’t invisible.

Same story with workload security. Kubernetes brings you Pod Security Standards. There is baseline, restricted and privileged profiles, so everyone speaks the same language. But simply setting a standard isn’t enough. We’d also need things like admission controls, image scanning, runtime monitoring and audit trails.

Honestly, the NSA/CISA Kubernetes Hardening Guidance is still gold. Scan containers and pods. Run workloads as locked down as possible. Use strong authentication. Separate networks. Set up solid logging. These ideas sound obvious until you see what happens when your organization scales without good ops.

Network policies: where “it should work” meets reality

Kubernetes networking can trip up even the best teams. Engineers often think different namespaces mean automatic isolation between apps. Not true.

Kubernetes network policies decide which pods can talk to which, but the policies only matter if your networking plugin actually enforces them. I’ve seen a lot of teams write network controls that look great in YAML but don’t work, because the underlying network just ignores them. Security validation beats documentation every time. If two namespaces shouldn’t talk, test it. If a workload only needs access to a specific backend, check it. If only specific ingress is allowed, make sure nothing else gets through.

At scale, your Kubernetes security has to prove itself. “We have a policy” means nothing unless the platform can show the policy actually works.

Resource management becomes all about money

One of the biggest challenge is resource allocation. Kubernetes lets you set CPU and memory limits, and sure, there are official docs. But getting these numbers right is tough.

Set them too low, and your workload might get throttled or evicted under load. Set them too high, and you’re paying for unused infrastructure. That barely registers on a small cluster, but when you’re running thousands of pods? That’s cloud bills gone wild.

This is where Kubernetes ops and FinOps meet. Platform teams have to know who’s burning through which resources, what’s over-provisioned or flying blind, and where the real money goes. ResourceQuota helps keep things in check, but quotas alone don’t hold people accountable.

The culture shift is moving from “the cluster has spare capacity” to “every service has an owner, a cost profile and a plan for staying lean.” Teams should understand their infrastructure bill. Platform teams need dashboards that point out waste. Engineering leaders need to care about efficiency, not just hear from finance when things go off the rails.

Autoscaling isn’t a magic trick

The Horizontal Pod Autoscaler is handy. It adjusts your workloads automatically to match demand. But don’t overestimate it. Most real-world services don’t scale simply by CPU or memory. Sometimes a service hits latency limits before CPU usage spikes. Workers chewing through queues? You care more about backlog size. Machine learning? Maybe it’s all about GPU use or loading time. Customer-facing apps? You want to be scaled up before traffic hits, not scramble after users start complaining.

So autoscaling isn’t just a box you check. It’s a feedback loop, and it only works if you use the right signals. Sometimes CPU is enough. Sometimes you need to scale on queue length, request rate, latency or something totally custom.

Then there’s node autoscaling to provision infrastructure in response to demand. On paper, it just works. In real life, it runs into startup delays, availability zones, quotas, cloud provider quirks and pod disruption budgets. Scale pods faster than nodes? Users still see delays.

Test autoscaling like you test your app. Load-test it, break it, see what happens after an incident. Otherwise, you’ll find the limits when it hurts most.

Observability doesn’t matter unless it answers questions

Kubernetes has mountains of data. Things like  logs, metrics, traces, events, audits, deployment history, container restarts, control plane noise, you name it. The real challenge isn’t collecting info, but actually it’s making sense of it. The CNCF and others have best practices for logging and telemetry, like centralizing logs and not leaking secrets. Those matter, but at the end of the day, engineers need answers, not just data. When something breaks, no one’s asking, “Is Kubernetes alive?” They want to know what changed. Did something roll out? Did a pod crash? Did autoscaling fire too late? Was a node unhealthy, a secret rotated, a network policy too tight, a downstream DB choking?

Observability should line up with real operational questions and not just ticking boxes for logs, or metrics. Dashboards need to match service ownership. Alerts need to mean something to end users. Telemetry should connect to deployments and incidents. Measure how quickly engineers spot the root cause, not just that you have the data somewhere.

CNCF talks about newer models of unified telemetry and proactive troubleshooting for a reason. All the dashboards in the world don’t help when your team has to play detective during an outage.

Upgrades: Don’t wing it

Kubernetes upgrades catch people out. The CNCF Maturity Model says: Kubernetes drops three big releases a year, so maintenance is part of life—not a once-in-a-blue-moon project.

Upgrading at enterprise scale can involve everything: workloads, admission controllers, CI/CD, service mesh, ingress, storage drivers, monitoring, security, custom controllers. Version skew policies keep you between the lines, but that’s just the beginning. The real question is: can you test your whole stack?

Good upgrade programs need a repeatable process, staging environments that actually look like production, and clear communication so teams know what to expect. The worst upgrade process is the one that relies on heroes to pull it off at the last second. A strong platform turns upgrades into routine.

Reliability: Kubernetes helps, but it doesn’t guarantee it

Yes, Kubernetes restarts crashed containers, reschedules pods and does rolling deployments. But it doesn’t make a bad app reliable.

A poorly coded app will fail on Kubernetes just like anywhere else. Bad readiness or liveness probes? Your app gets traffic too soon. No graceful shutdown? Requests drop during deploy. Forgot pod disruption budgets? The app goes down during node maintenance. A flaky dependency? It will cascade through your services even if all your pods look healthy.

The mature approach is setting service-level objectives and making reliability a product of both platform and engineering. Cluster health isn’t user experience. That green status page can hide a lot of pain.

The platform team is a product team

Here’s the biggest lesson I’ve picked up is that running Kubernetes at enterprise scale isn’t really about the tech. One cluster? Maybe one expert can handle that. But for a full enterprise platform, you need a product mindset. The platform team serves customers such as engineers, security, compliance, finance and business. Everyone wants something a bit different.

Developers want speed and reliability. Security wants oversight. Finance wants transparency. Compliance wants proof. Ops wants predictability. The business wants all of those.

The platform team has to pull those threads together with APIs, docs, dashboards, paved roads, support and feedback. That also means saying “no” to the unique snowflake patterns that create chaos later. Kubernetes is powerful. But it doesn’t replace organizational discipline. That’s still on the shoulders of engineering leaders. The real challenge at enterprise scale isn’t memorizing every API object. It’s building a system where any team can ship safely without needing to be Kubernetes experts themselves.

When you reach that point, Kubernetes stops being just a cluster. It becomes your platform.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The strangest thing about cloud strategy is how confident it looks in PowerPoint and how nervous it feels in real life.

I’ve sat in rooms where the cloud slide looked clean enough to frame. Public cloud here. Private cloud there. Hybrid for the awkward middle child. Multi-cloud for resilience, bargaining power and the faint hope that no single vendor would ever own our sleep.

Then AI arrived.

At first, it looked like another conversation about workload. Bigger compute. More storage. Faster experiments. Some awkward cost questions. Nothing we couldn’t absorb with a thicker roadmap.

Then the bills landed. The data moved in odd ways. Teams built things before governance could find its shoes. Vendors became more central than anyone had admitted.

The old cloud strategy didn’t collapse. It blushed. AI exposed the assumptions beneath it.

Now, quantum changes something deeper. It asks whether the decisions behind the workload can survive time, secrecy, suppliers, weak evidence and uncertainty.

That’s a much less comfortable meeting.

Cloud strategy was built for workloads we thought we understood

For years, cloud strategy was a sensible debate about location, cost, control and speed. Public cloud for scale. Private cloud for sensitive workloads. Hybrid cloud for compromise. Multi-cloud for resilience, negotiation or, if we’re being honest, organizational politics with a nice diagram.

The logic was sound. Move faster. Cut heavy infrastructure spend. Improve recovery. Give developers what they need before they grow old waiting for a server. It worked because the work behaved in familiar ways. Systems had owners. Costs had patterns. Data had borders, or at least we pretended it did.

The question was simple: Where should this workload live? That question still matters. But it no longer carries enough weight.

AI changed that. AI changed the pattern, not just the platform AI didn’t politely join the cloud strategy. It wandered through the house, opened every cupboard and asked why the plumbing sounded tired.

The first shock was demand.

Traditional systems consume resources in ways you can usually model. AI workloads behave differently. Training, testing, inference and data processing can spike, pause, restart and spread before anyone has agreed on who owns the meter.

Cloud cost control used to ask a billing question, “How much will we use?” AI asks an operating question: “Who is allowed to create demand, at what scale, for what purpose and with whose approval?”

The second shock was data.

AI does more than store data. It chews it, reshapes it, remembers parts of it, produces new versions of it and leaves traces in places people forget to check. Prompts, logs, embeddings, model outputs, copied files and forgotten notebooks can become quiet risk pockets.

A cloud strategy that only asks where data sits misses how data behaves.

The third shock was supplier dependency.

Many firms thought they had a cloud strategy. AI revealed they had a supplier dependency strategy wearing a cloud badge. GPUs, model platforms, managed services, specialist APIs and third-party tools became central to delivery.

AI compressed the distance between idea and exposure. A team could test, connect and release faster than governance could form a working group. I say that with affection. I’ve seen working groups age in dog years.

Cloud strategy had become a test of decision speed, risk appetite, financial discipline and data control. It now goes beyond architecture.

Then quantum changed the clock.

Quantum changes the time horizon

Quantum risk often gets dumped into the cryptography drawer. That is understandable. It is also dangerous.

The leadership issue adds time to the future of quantum computers.

Some data stolen today may still matter years from now. Some secrets age badly. Trade secrets, legal records, health data, source code, identity data and sensitive contracts don’t all expire at the same speed. Some decay like fruit. Some sit like plutonium.

That is why “harvest now, decrypt later” matters. An attacker may collect encrypted data today and wait for better tools tomorrow. You don’t need to panic. You do need to ask which data has a long secrecy life.

If your most sensitive long-lived data spans cloud platforms, SaaS services, backups, archives, collaboration tools and supplier systems, where exactly is your quantum exposure? Which encryption protects it? Who manages the keys? Which supplier has a plan? Which one has a brochure?

A brochure is a scented candle for anxious executives.

Migration also takes time. Cryptography hides everywhere. In applications. In identity systems. In network devices. In APIs. In firmware. In backup tools. In old systems, nobody wants to touch.

Quantum readiness goes beyond a weekend patch. It is discovery, classification, design, testing, contracts, funding, sequencing and proof.

The risky sentence is, “We’ll revisit this when things become clearer.”

By then, the cheap decisions may have left the building.

The real issue is decision infrastructure

AI exposed assumptions about speed, cost, data and suppliers. Quantum exposes timing, ownership, evidence and memory. Together, they point to a quieter weakness: decision infrastructure.

By decision infrastructure, I mean the system by which leaders frame risk, assign ownership, make trade-offs, record choices, track evidence and revisit assumptions when facts change. That sounds dull. Good. Dull is where serious governance lives. The glamorous stuff gets applause. The dull stuff prevents regret.

Many organizations saw the risk and still failed because too many people saw different pieces of it, and nobody owned the decision. The cloud team sees architecture. Security sees exposure. Legal sees liability. Procurement sees contract gaps. Finance sees cost drift.

The board sees amber. Amber is often where hard decisions go to nap.

This is why AI and quantum belong in the same leadership conversation. AI asks whether your cloud strategy can keep pace. Quantum asks whether it can cope with time. Both punish vague ownership.

Who owns long-term cryptographic exposure? Who can force a supplier conversation? Who accepts residual risk if migration cannot happen fast enough? Who records why a decision was made and when it must be reviewed?

Suppose those questions feel awkward, good. Awkward questions earn their rent.

The questions leaders should ask now

The board needs better questions.

Start with exposure. What protects your most sensitive systems and data? Where do you rely on supplier-managed encryption? Which systems are old, critical, poorly documented and painful to change?

Exposure is a map of assets, data, dependencies and time.

Then ask about ownership. Who owns quantum readiness across cloud, cyber, legal, procurement, privacy, resilience and the business? Who can make trade-off decisions when risk reduction competes with cost and delivery? Which risks are stuck because everyone is involved and nobody is accountable?

Awareness without ownership is just anxiety with better stationery.

Then ask about evidence. Can you show progress by system, supplier, business service and data class? Would your evidence survive a board review, a regulator’s questioning or a post-incident investigation?

Evidence built under pressure is expensive. It is also sweaty. Build the proof trail before the room gets hot.

Finally, ask about timing. Which choices must be made now because migration will take years? What event would trigger faster action? When will the board revisit the risk?

Which delay would you regret if the timeline moves faster than expected?

That last question matters. Regret is often the most honest risk metric in the room.

What a quantum-aware cloud strategy looks like

A quantum-aware cloud strategy is not a glossy side document owned by three cryptographers and a nervous intern.

It is a cloud strategy with better questions built into it:

1. Build cryptographic visibility. Start with the services that matter most. Find the encryption, certificates, protocols, keys, libraries and suppliers that protect them. Perfection can wait. Blindness cannot.
2. Classify data by secrecy life. Not just sensitivity. Time. How long must this information stay protected? A short-lived report and a long-life trade secret do not belong in the same queue.
3. Press suppliers for evidence. Ask what they are doing, what you must do and how they will prove progress. Confidence is lovely. Evidence pays the rent.
4. Rank migration by risk. Start where business value, long-life data, weak visibility and migration pain meet. Treating everything as equal is how serious work becomes theatre.
5. Change board reporting. Don’t report quantum as a foggy science project. Report decisions required, risks accepted, blockers, supplier gaps and review dates. Boards govern choices. Give them choices.
6. Build a review rhythm. Standards, tools, suppliers, threats and regulations will continue to evolve. A stale roadmap is just a risk register wearing a lab coat.

No panic. Panic burns energy and produces bad slides. The aim is readiness with owners, evidence and judgment.

The cloud question grew up

Cloud strategy began as an architecture question.

AI turned it into an operating question. Quantum turns it into a leadership question.

That is the shift.

To handle this well, organizations will need to build decision muscle early. They will know what matters, who owns it, what evidence exists, which suppliers are ready and when the next decision must be made.

But beneath cloud, AI and quantum sits the discipline leaders often avoid until pressure arrives, wearing a suit: decision quality.

AI changed the cloud bill. Quantum changes the clock.

And the clock is where risk hides.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

IBM is looking to expand the reach of its foundational mainframe portfolio by adding new single frame and rack mounted versions of its Z and LinuxONE systems.

The IBM z17 portfolio adds a single frame and rack mount versions that bring mainframe capabilities into smaller, customizable footprints. The LinuxONE Rockhopper family gets a single frame and rack mount models, plus a new Express rack mount offering, that target new and smaller clients, according to Tina Tarquinio, chief product officer, IBM Z & LinuxONE.

Specifically, the new hardware includes:

• z17 single frame is a fully packaged box in an IBM rack with intelligent power distribution units, delivered as a complete enclosed unit ready to deploy at the edge or other strategically important customer sites.
• z17 rack mount lets customers install IBM Z components directly into their own industry-standard rack, with built-in flexibility for co-location with other technologies.
• LinuxONE Rockhopper 5 is a multi-drawer LinuxONE system for high-density workloads, with on-chip AI acceleration, confidential computing, and postquantum cryptography available in both single frame and rack mount configurations.
• Rockhopper 5 rack mount and Express offerings deliver enterprise-grade Linux, confidential computing, and on-chip AI acceleration in a compact 18U configuration. Designed for organizations supporting a smaller set of workloads, the offering provides a cost-efficient entry point that can scale as business grows, while prioritizing security, resiliency, and performance.

IBM

The new IBM z17 and IBM LinuxONE 5 Rockhopper configurations support up to 82 cores and 18 TB of memory across two processor drawers, representing about a 20% increase in core count and 12% increase in memory capacity over current systems, IBM stated. Single processor capacity of an IBM z17 ME2 provides full speed IBM z/OS configurations including 10% greater throughput per core than IBM z16 A02 with some variation based on workload and configuration, according to Tarquinio.

Both systems feature a 5.5 GHz IBM Telum II processor and a built-in AI accelerator that IBM says will let customers run more than 450 billion inferencing operations in a day with one millisecond response time. In addition, the 32-core Spyre AI accelerator is designed to handle all manner of AI workloads.

The idea is to bring the core strengths of IBM Z to a broader range of deployment models while offering the security, resilience, and performance enterprises depend on, Tarquinio said. 

“As always, we’re continuing to innovate to deliver more with less, including up to 20% more capacity than IBM z16 to help process transactions faster and support growing AI-driven workloads,” Tarquinio said.  “Even the newest and smallest member of the IBM z17 family delivers the performance, efficiency, and scalability organizations need as they balance growth ambitions with real-world resource constraints.”

For the Linux-based system, Rockhopper 5 is for organizations that have moved past the evaluation question and are ready to consolidate a substantial portion of their x86 estate, said Marcel Mitran, IBM Fellow and CTO of IBM LinuxONE. 

Rockhopper 5 is designed to bring a smaller physical footprint and a software licensing model that reflects actual workload boundaries rather than physical server counts, Mitran said.

The LinuxONE 5 Express is a preconfigured system designed to get organizations running on LinuxONE quickly, with a defined bill of materials and a predictable starting cost, on the same architecture that the largest enterprises in the world depend on, Mitran said.

“It is built for organizations that want to consolidate a modest x86 estate, evaluate LinuxONE for the first time, or deploy a specific workload such as digital assets, AI-infused transaction processing, or confidential computing, without committing to the footprint of the larger model,” Mitran said.

Some of the mainframes’ software features were also bulked up. For example, IBM said that Post Quantum Cryptography security is now standard on the z17 and LinuxONE Rockhopper 5 systems letting customers start to utilize cryptography to protect core resources for the future.

The idea is to help customers protect long-lived, mission-critical data while reducing the cost and complexity of future cryptographic migration, IBM stated. 

In that vein, IBM said it was bringing Crypto Discovery & Inventory, which lets security teams see what has been encrypted across the enterprise. In addition, IBM announced an Infrastructure Management for Z and LinuxONE package that would let customers administer, monitor, automate, and provision IBM Z and LinuxONE systems from a central location.

IBM said it wants to reduce operational complexity for customers by making automating day-to-day operations to ultimately lower administrative costs and concerns. With the new flexible form factors, IBM continues to target hybrid and AI infrastructure buildouts with the Big Iron. In the AI world, the z17 is being utilized for AI inferencing, transactions, training, and key security applications such as fraud detection and insurance claims.

“Enterprise infrastructure is entering a new phase. Organizations need platforms that can support AI-driven growth while navigating resource constraints, evolving business requirements, and increasingly complex hybrid environments,” Tarquinio said. “They are being asked to deploy new AI capabilities while learning new skills, controlling operational costs, and maximizing the value of existing applications and infrastructure.”

A recent IBM Institute study on mainframe usage stated that embedding mainframe to support AI in executing transactions is not temporary: 75% of executives expect mainframe-based applications to remain central to digital transformation, and 60% say mainframe-based platforms are essential to enabling AI innovation.

”Mainframe-anchored systems of record are becoming systems of intelligent execution—not as general‑purpose AI platforms, but as environments where AI acts directly within transactions and in support of them,” the study reported.

Gartner wrote in its “The State of the IBM Mainframe in 2026” report that IBM’s willingness to make significant investments ensure the mainframe modernizes to remain a vital and thriving component of enterprise IT.  

“Most mainframe customers are now prioritizing the reduction of technical debt and adopting platform innovations to future-proof their mainframe environments for the coming decade,” Gartner wrote.

The new z17 single frame and rack mount configurations, LinuxONE Rockhopper 5, and LinuxONE 5 Express will all be available August 12, 2026. IBM Infrastructure Management for IBM Z and IBM LinuxONE will be available August 14.