Aleš Holeček

As a prelude to the AI Infra Summit starting today at the Santa Clara Convention Center (Sept 9-12 2025), I published a paper highlighting the architecture challenges facing the industry. You can download the paper from the following link: https://lnkd.in/gz3-3cTn Artificial Intelligence is no longer a niche workload—it is the engine driving hyperscale data centers, autonomous vehicles, and mission-critical systems worldwide. Yet behind the promise lies a crisis in design: unpredictable workloads, skyrocketing silicon costs, interconnect bottlenecks, thermal hotspots, and the fragility of heterogeneous chiplet integration. This paper cuts through the noise, showing why traditional tools and benchmarks are failing us and why predictive, system-level exploration is now essential. From chiplets to cloud, it demonstrates how early modeling uncovers bottlenecks, reduces risk, and saves millions in time and cost, while enabling safer, faster, and more energy-efficient AI infrastructure. If you care about building AI systems that actually deliver in the real world—reliably, at scale, and ahead of competitors—this is the paper you cannot afford to ignore #AISystemArchitecture #ErchitectureExploration #PredictiveModelingForAISystems, #AIInfrastructureDesign #ChipletSystemDesign #SoCArchitectureExploration #DataCenterAIArchitecture #VisualSimArchitect #AIWorkloadModeling #ChipletIntegrationChallenges #SystemLevelSimulationTools #CacheHierarchyOptimization #MemorySystemArchitecture #InterconnectBottlenecksInAI #AIPowerAndThermalManagement #AIPerformanceVSReliabilityTradeOffs #EarlyStageSystemDesignExploration

49

4 Comments

The myth of the "𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲" approach. When facing architectural decisions, defaulting to "best practice" or imitating the systems of successful companies is often a failure of intellectual rigor. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗺𝘂𝘀𝘁 𝗮𝗹𝘄𝗮𝘆𝘀 𝗱𝗶𝗰𝘁𝗮𝘁𝗲 𝘁𝗵𝗲 𝗱𝗲𝘀𝗶𝗴𝗻, not imitation. Instead, we must quantitatively weigh the trade-offs within their specific context and decide based on cost-benefit analysis. Let's use the example considering 𝗺𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗳𝗼𝗿 𝗮 𝗻𝗲𝘄 𝘀𝘁𝗮𝗿𝘁𝘂𝗽 (this analytical framework applies equally to technology stack choices, e.g., NoSQL adoption, or managing database migrations with tools like Liquibase). The dominant trade-offs usually look like this: Pros 1. Decoupled Deployment: Enables feature shipping without global system release coordination. 2. Organizational Alignment: Promotes clear domain ownership, facilitating parallel development as the organization scales. 3. Domain Isolation: Better alignment to business domains, and facilitates creating product lines. 4. Resource Elasticity: The ability to scale only the specific services under load. 5. Blast Radius Reduction: A failure in one service is contained, minimizing the system-wide impact. Cons 1. High Operational Overhead: Significantly increases complexity across security, CI/CD pipelines, monitoring, tracing, incident response, and even debugging. 2. Testing complexity: a simple test running on build now requires environment-heavy integration tests 3. Higher Infrastructure Cost: Costs often increase substantially before real scale demands it. 4. Fault isolation: Partial outages, retries, and timeouts introduce distributed system failure patterns that are inherently difficult to reason about and debug. 5. Data Consistency & Latency: Loss of simple ACID transactions and added network hops increase complexity and performance risk. We need to decide what is best for us, and for that, we require context-specific metrics: 1. What is the size of our team, and what is the projected growth trajectory? 2. What is our required delivery velocity? 3. What is our 𝗿𝗲𝗮𝗹𝗶𝘀𝘁𝗶𝗰 𝗶𝗻𝘃𝗲𝘀𝘁𝗺𝗲𝗻𝘁 𝗰𝗮𝗽𝗮𝗰𝗶𝘁𝘆 for infrastructure and operations? (Proceeding without proper investment will inevitably result in 𝗯𝘂𝗴𝗴𝘆, 𝘂𝗻𝗺𝗮𝗻𝗮𝗴𝗲𝗱 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲.) Now, consider a small startup with a small co-located team, fresh off a seed round, and focused on securing the next round within a year. Based on the above analysis, what choice would you make? For this startup, at this stage, microservices are almost always the wrong choice. 𝗕𝗲 𝗶𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻𝗮𝗹 𝗶𝗻 𝘆𝗼𝘂𝗿 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀. Architectural choices are fundamentally risk-mitigation bets. "Best practices" often obscure inherent risk, while a deep understanding of your context brings it into clear focus. The intention behind a decision—even if it proves suboptimal—provides a superior learning trajectory. Happy Hanukkah, everybody :)

21

Great to see initiatives like the recent Impact Lab, where 27 teams built projects in one day using AI combined with San Diego’s open city data. This is a strong signal of where city platforms are heading. Proud that Honeywell has been ahead of the curve in adopting Generative AI within the Honeywell City Suite Smart City platform, demonstrating how AI and city data together can unlock the cognitive cities potential. When LLMs are connected to structured urban data — such as mobility, utilities, assets, permits, GIS layers, and real time IoT data — the result is entirely new ways of interacting with the city itself, not just dashboards. Instead of navigating multiple systems, users can query the city in natural language, generate insights instantly, and even prototype services in hours rather than months. For smart cities, the real value of AI is not in the model alone, but in the availability of well governed, interoperable, and accessible city data. Cities that invest in open data, semantic models, and integration platforms today will be the ones able to fully leverage generative AI tomorrow. Experiments like this show that the future city interface may not be an application, it may be a conversation.

14

1 Comment

The meteoric rise of OpenClaw (local, persistent agents) and Moltbook (social networks for AI) signals a structural shift in AI Systems. OpenClaw represents a meaningful evolution in AI architecture: systems that are no longer just responsive tools, but persistent agents that observe, decide, act, and update continuously. Moltbook, a Reddit-style platform exclusively for autonomous AI agents, adds a second, more consequential dimension: agents interacting with other agents at scale, exchanging information, reinforcing behaviors, and shaping decisions without direct human prompting. Together, they introduce a new class of system behavior: * Decisions informed by machine-to-machine consensus * Knowledge that evolves through feedback loops, not static datasets * Humans increasingly positioned as consumers of outcomes As an AI engineer and researcher, this is exciting and unnerving at the same time. On one hand, this was inevitable. Of course agents will talk to one another. Of course they’ll exchange heuristics, patterns, and partial beliefs. That’s how every scalable system — biological, economic, or computational — works. On the other hand, the OpenClaw + Moltbook moment forces a serious conversation: * How do we audit a system that learns from another system? * How do we prevent a "hallucination echo chamber" where agents drift away from reality? * How do we design systems that surface uncertainty instead of hiding it? * And most importantly: how do humans retain the ability to challenge the interface between belief and reality?

18

1 Comment

7NF based Statically Typed Name Space Driven Development overall picture, which is a ten-years later additional slide for the slide deck, in which 7NF has been coined with Alumni in 2015 (just in front of David Garlan, the primary author of "Architectural Mismatch: Why Reuse Is So Hard"); https://lnkd.in/gYKsa8Vb The attached picture is an informal "architectural diagram", which may be explained by a "try-to-be formal" paper in 2025 as follows; -- 3.3 Manage transactions by canonical table design: 7th Normalization (7NF) When normalization is pursued, the total number of tables increases, leading to two problems. First, querying the database (usually with SQL) becomes more complex as the number of join conditions rises. Second, transaction management becomes more complicated due to the increased number of tables and the presence of foreign key columns across many tables. One of the responsibilities of the database is to maintain transactional consistency. To this end, there is a function called rollback, which restores the database state to the point at which the process started if a database state change procedure fails in the middle of a transaction. When normalization is pursued, the processing load related to rollback increases. To address this issue, a method was developed to eliminate the need for rollback. Transaction management should move from the database to the application, with a focus on canonicalizing the table design on the application side. One author named this the seventh normalization, which includes the sixth normalized set of tables and additional tables for transaction management. For more details, please refer to the references [5]. The following simple example demonstrates this concept. The key idea of the seventh normalization is to reverse the usual order of INSERT operations in transaction management. In traditional models, parent records are inserted first, followed by child records. In 7NF, this order is reversed to enhance concurrency in completing children’s transactions individually. If “parent first, children last” is the normal case, the reverse is “children first, parent last.” Children records are considered logically invalid without a corresponding parent, with the parent table serving as the commit point. The order in which the child tables are written to the database is not questioned, and the INSERT process is performed concurrently, facilitating database distribution. Thus, rollback functionality is logically implemented in application level. Rerefences [5] Yuzo Ishida (2018): U.S. Patent for Data management system Patent (Patent # 11,169,984 issued November 9, 2021) - Justia Patents Search, https://lnkd.in/gyta85Zp -- source) https://lnkd.in/gUDgvJa5 7NF is designed for out-of-order executions in both read and write operations with commutativity and idempotency in pursuing scalability and efficiency under massive parallel processing without losing "read" consistency. https://lnkd.in/gSrRumAc

2

9 Comments

🤔 Is Your Architecture AI-Ready, or Just Legacy in Disguise? 🐘 The "Elephant in the Room" is simple: You can’t run 2026 Agentic AI on a 2000s Monolith. If your BSS/OSS is a "Black Box," your AI is effectively blind. 🧐 Before you sign off on your next AI pilot, assess your estate with the DEXTRIT Architectural Readiness Checklist: 1️⃣ Data Liquidity: The "15-Minute Rule" - The Test: Can your AI agents access real-time subscriber, billing, and network data via a standardized Open API in less than 15 minutes of configuration? - The Reality: If it requires a 3-month System Integration (SI) project to "expose" the data, you don't have an AI strategy; you have a data silo problem. 2️⃣ Decoupling: The "Vendor Sovereignty" Audit - The Test: Can you replace your "Charging" or "Product Catalog" module without collapsing your entire CRM and Order Management flow? - The Reality: TM Forum ODA (Open Digital Architecture) isn't a suggestion; it’s a survival requirement. AI needs a "Composable" estate to trigger autonomous actions. 3️⃣ Operability: The "Self-Healing" Benchmark - The Test: Does your architecture support Closed-Loop Automation? Can your system detect a failure, root-cause it via AI, and auto-remediate without a manual ticket? - The Reality: AI "Chatbots" are easy. AI "Ops" (AIOps) that manages a cloud-native core is where the ROI lives. 4️⃣ Governance: The "Technical Debt" Police - The Test: Do you have an internal Architecture Authority that can veto vendor "quick fixes" that violate your ODA blueprint? - The Reality: Most technical debt is born in the gap between the Board’s vision and the SI’s delivery timeline. If you aren't policing the code, you aren't in control. 5️⃣ Security-by-Design: The "Agentic Guardrail" - The Test: If an AI Agent autonomously modifies a customer's credit limit or network slice, is there a secure, auditable trail that complies with 2026 regulations? - The Reality: Trust is the currency of AI. If your architecture doesn't have native "Guardrail" layers, your AI is a liability, not an asset. ☑️ The DEXTRIT Verdict: If you checked "No" to more than two of these, your AI strategy will likely stall at the "Pilot" stage. At DEXTRIT, we don't do generic transformation. We help mid-sized operators regain Architectural Authority and build the Composable IT Estates required for the AI era. Stop layering intelligence on top of monoliths. Let’s have a real conversation about your foundation. #Telecoms #TMForum #DigitalTransformation #DEXTRIT #OpenDigitalArchitecture #OpenAPIs

4

As Anthropic's Claude Code continues to evolve, vibe coders are discovering powerful ways to orchestrate AI-driven workflows. Two key features that often cause confusion are the Task tool and the newer Subagent system. While they appear different on the surface, understanding their relationship reveals some interesting insights about how Claude Code’s architecture works under the hood. Full article here: Task Tool vs. Subagents: How Agents Work in Claude Code https://lnkd.in/gRDcDcET

5