<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture on Murat Eksi</title><link>https://murateksi.com/tags/architecture/</link><description>Recent content in Architecture on Murat Eksi</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 09 May 2026 20:00:00 +0200</lastBuildDate><atom:link href="https://murateksi.com/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Run a Program Reset Without Losing the Customer</title><link>https://murateksi.com/posts/program-reset/</link><pubDate>Sat, 09 May 2026 20:00:00 +0200</pubDate><guid>https://murateksi.com/posts/program-reset/</guid><description>Every enterprise delivery that runs long enough will have a moment where the program is not going as planned. The timeline has slipped, the scope has expanded beyond what the original budget can absorb, a key technical assumption turned out to be wrong, or an organizational change on the customer side has made the original delivery plan unworkable. When this happens, the account team faces a choice that determines whether the customer relationship survives the delivery.</description></item><item><title>The Meeting That Actually Closes Enterprise Cloud Deals</title><link>https://murateksi.com/posts/architecture-review-closes-deals/</link><pubDate>Tue, 14 Apr 2026 09:00:00 +0200</pubDate><guid>https://murateksi.com/posts/architecture-review-closes-deals/</guid><description>Somewhere in every serious enterprise cloud deal is a meeting that looks like a technical checkpoint. Someone from the customer&amp;rsquo;s architecture team asks how the proposed platform handles multi-region failover, or what the data residency story is, or why the migration path doesn&amp;rsquo;t start with a pilot. The salesperson checks their watch and waits for it to end.
That meeting is where the deal is won or lost.
What happens in an architecture review The technical reviewers in that room are rarely trying to block the deal.</description></item><item><title>Predictive Maintenance at Fleet Scale with Sparse Failure Data</title><link>https://murateksi.com/case-studies/industrial-predictive-maintenance/</link><pubDate>Tue, 10 Mar 2026 00:00:00 +0000</pubDate><guid>https://murateksi.com/case-studies/industrial-predictive-maintenance/</guid><description>The customer had a simple idea: if their platform could tell operators which machines were likely to fail before they failed, the customers would pay a premium for that signal. The idea was right. The path to production was not the one anyone planned.
The problem with the obvious approach Predictive maintenance models learn from failure events. To predict a bearing failure, you need historical data showing what the sensor readings looked like in the hours and days before the bearing actually failed.</description></item><item><title>Your Architecture Isn't AI-Ready. Here's What to Fix First.</title><link>https://murateksi.com/posts/building-ai-ready-architecture/</link><pubDate>Thu, 05 Mar 2026 09:00:00 +0100</pubDate><guid>https://murateksi.com/posts/building-ai-ready-architecture/</guid><description>The most common question I hear from engineering leaders right now is some version of &amp;ldquo;how do we add AI to our platform?&amp;rdquo; It is a reasonable question. It is also usually the wrong first question.
The right first question is: can your current architecture support AI workloads reliably? Not just technically, but operationally. In practice, most enterprise architectures were not designed with the access patterns, latency profiles, or cost structures that AI workloads require.</description></item><item><title>What Running Serverless at Scale Actually Teaches You</title><link>https://murateksi.com/posts/serverless-at-scale-lessons/</link><pubDate>Wed, 12 Nov 2025 09:00:00 +0100</pubDate><guid>https://murateksi.com/posts/serverless-at-scale-lessons/</guid><description>The interesting problems in a serverless system at scale do not announce themselves as serverless problems. They announce themselves as pager alerts at 3 AM, as data inconsistencies discovered by a customer three weeks after they occurred, as deployment pipelines that work perfectly in staging and fail silently in production.
When we were running a Nordic telematics platform at 200,000 messages per second across 1.6 million vehicles, the operational challenges had almost nothing to do with Lambda&amp;rsquo;s execution model.</description></item></channel></rss>