Russell East's blog

thoughts |> share |> ignore

recent posts

about

I’m a Principal Systems Architect with a background in distributed systems, cloud-native engineering, and large-scale software architecture. I’m currently exploring how AI-native systems change the way we think about orchestration, runtime behaviour, observability, and stateful execution in production environments. This blog is a place to document ideas, experiments, and architectural observations around AI systems, platform engineering, distributed runtimes, and modern software architecture.

  • What Happens When C4 Meets a Capability Language?

    An experiment in combining structural and behavioural architecture models for AI-assisted reasoning.

    Why combine C4 and DCL?

    Architects rarely work with one complete representation of a system.

    A C4 model can show systems, containers, relationships, and dependencies. It is excellent at answering questions such as:

    • What exists?
    • What talks to what?
    • Where does responsibility sit structurally?

    But structural diagrams do not always explain the business behaviour moving through those structures.

    DCL, the Declarative Capability Language, approaches architecture from the other direction. It describes capabilities, outcomes, effects, events, policies, and lifecycle. It is intended to answer questions such as:

    • What is this system responsible for?
    • What business outcomes matter?
    • What happens when something fails?
    • How does a business I progress over time?

    That led to a simple question: What happens if an LLM is given both models of the same architecture?

    This experiment was not about replacing C4, nor about forcing DCL into a structural modelling role. It was about testing whether the two models could become complementary sources of architectural knowledge.

    The complete experiment -> C4 DSL, DCL source, prompts, findings, and diagram source is available in the DCL Repository

    The experiment

    The scenario is a fragment of an enterprise media content-management architecture that I worked on more than a decade ago, reconstructed from memory. It is not a complete production architecture, but it contains enough behaviour and structure to make the experiment meaningful.

    Users upload batches of video, images, audio, and microsite packages through a web portal. They assign attributes to content and later approve it for publication.

    Uploaded media is analysed and routed into the appropriate processing path. Video is analysed, transcoded, and thumbnailled. Images are thumbnailled. Approved content is matched to playlists using its attributes, and digital signage players poll for new playlist versions before downloading the required media. Playback events are sent to analytics.

    The original architecture used CQRS and event sourcing, with asynchronous processing across several services.

    The models

    The C4 model describes the structural architecture:

    • portal and content-management application
    • media-processing services
    • playlist publishing and serving services
    • digital signage players
    • analytics
    • storage, eventing, event sourcing, and read models
    C4 system context
    C4 Container diagram

    The DCL model describes the behavioural architecture:

    • UploadContentBatch
    • AnalyseMediaFile
    • GenerateThumbnail
    • TranscodeVideo
    • ApproveContent
    • PublishContentToPlaylist
    • ServePlaylistToPlayer
    • RecordPlaybackAnalytics

    It also includes a supervising lifecycle for a media item:

    Uploaded
    → Analysed
    → Processing
    → ReadyForApproval
    → Approved
    → Published

    or

    → Rejected
    → Failed

    The lifecycle is deliberately business-oriented. It is driven by declared outcomes and events, rather than by service calls. That keeps DCL focused on behavioural progression while C4 remains responsible for structural orchestration.

    DCL architecture view

    Generated from the DCL code in the VS Code extension (architecture view)

    DCL event flow

    Generated from the DCL code in the VS Code extension

    Method

    I created a C4 DSL model and a DCL model for the same scenario. I then used Codex with both the C4 and DCL MCP servers available.

    The prompts did not use a hand-authored mapping file. Instead, the LLM had to correlate the models through shared vocabulary, responsibilities, effects, events, lifecycle transitions, and C4 relationships.

    The experiment asked five questions:

    QuestionWhat it testedMost useful result
    Correlate the modelsCan DCL capabilities be related to C4 containers without a mapping file?High-confidence correlation where vocabulary and responsibilities aligned
    Find fragmented capabilitiesWhich capabilities span multiple containers?Distinguished intentional distributed workflow from possible responsibility leakage
    Architectural consistency reviewWhere do the structural and behavioural views disagree or leave gaps?Found role, event, lifecycle, and ownership ambiguities
    Impact analysisWhat does a container outage mean in business terms?Connected dependency failure to capabilities, outcomes, and lifecycle states
    Explain a capabilityHow is one capability realised structurally?Produced a useful explanation of one business capability across the architecture

    The complete prompt outputs and findings are available in the repository rather than reproduced in full here.

    What the experiment showed

    The first result was encouraging but not surprising: correlation was high where names and responsibilities aligned.

    For example, AnalyseMediaFile correlated strongly with the File Analyser Service. GenerateThumbnail correlated with the Thumbnail Service. TranscodeVideo correlated with the Video Transcoding Service. PublishContentToPlaylist correlated with the Playlist Publisher.

    That is not magic. It is the result of consistent business vocabulary appearing in both models.

    The more interesting result was that the models contributed different kinds of evidence.

    C4 showed that the Playlist Publisher reads playlist projections, publishes events, and sends playlist versions to the Playlist Service.

    DCL explained why those relationships mattered. PublishContentToPlaylist produces a business outcome, emits PlaylistUpdated, applies reliability and audit policy, and advances the media-item lifecycle from Approved to Published.

    C4 gave the architecture implementation gravity. DCL gave the relationships business meaning.

    Fragmentation became visible

    The second prompt asked which capabilities were implemented across multiple containers.

    Most capabilities were not owned by a single container. That was expected.

    UploadContentBatch involved the portal, content-management application, media storage, eventing, event sourcing, and read-model projection. PublishContentToPlaylist involved the Playlist Publisher, query/read model, eventing, event store, and Playlist Service.

    This did not automatically indicate poor architecture. In many cases, it reflected intentional separation between user interaction, command handling, asynchronous processing, event sourcing, and query models.

    The useful distinction was between:

    • a capability with one clear primary business-logic owner and supporting technical dependencies
    • a capability split across several business services
    • a cross-cutting lifecycle that has no single container-level implementation

    The media-item lifecycle was the clearest example of the last category. It spans analysis, processing, approval, and publication. It is not a service. It is a behavioural view over a business journey.

    That is something C4 does not normally express directly.

    Consistency review was more useful than expected

    The consistency review did not reveal major contradictions, but it found useful architectural questions.

    For example:

    • C4 described a Content User who could review and approve content, while DCL separated ContentUser and ContentApprover.
    • DCL modelled rejection as an outcome and lifecycle state, but not yet as a first-class event.
    • DownloadMediaAssets appeared as part of the DCL serving capability, while the C4 model showed the digital signage player downloading assets directly from storage.
    • The lifecycle had no explicit structural owner. The Content Management Application was the likely candidate, but the lifecycle could also be interpreted as an event-sourced behavioural projection.

    These are exactly the sort of questions that often remain implicit in architecture documentation.

    Impact analysis was the strongest operational result

    The impact-analysis prompt produced the most interesting result.

    C4 can show that an Event Bus, Event Store, Query Store, or Media Storage component is central to many dependencies. But DCL allowed the analysis to go further:

    If this component fails, which business capabilities become unavailable?
    Which outcomes are no longer achievable?
    Which lifecycle transitions are blocked?
    Which actors are affected?

    For example, failure of the Event Bus did not simply break a technical dependency. It interrupted the chain from upload to analysis, processing, playlist publication, lifecycle progression, and analytics propagation.

    Failure of Media Storage affected upload, analysis, thumbnail generation, transcoding, and player asset download.

    This is the beginning of a more useful form of blast-radius analysis:

    C4 identifies structural dependencies.
    DCL translates dependency failure into business impact.

    The next refinement should return this analysis in a structured format, including a transparent blast-radius score. That would allow diagrams and heat maps to be generated from evidence rather than from free-form prose.

    What did not work as hoped

    I initially expected the LLM to turn its findings directly into useful Mermaid or PlantUML diagrams.

    That was the wrong abstraction.

    The LLM could produce reasonable explanations, but prose findings are not a diagram model. Asking it to jump directly from analysis to a generic graph produced diagrams that were technically correct but not particularly useful as architecture communication.

    The missing step is a structured derived projection.

    For example:

    Business area: Publish Content
    Capability: PublishContentToPlaylist
    Primary business-logic owner: Playlist Publisher
    Supporting business-logic containers: Playlist Service
    Evidence: PublishPlaylistVersion, PlaylistUpdated, C4 publication relationship
    Confidence: 0.96
    Fragmentation: primary owner plus serving responsibility

    That is not a manual mapping file. It is derived analysis output: a capability-allocation projection built from C4, DCL, and the LLM’s evidence-based reasoning.

    Diagrams should be rendered from that projection, not directly from a paragraph of findings.

    The real discovery: a functional architecture view

    The most useful outcome was not an AI-generated explanation. It was the beginning of a functional architecture view.

    Architects often need a view that answers:

    Which systems, services, or containers contain the business logic for this capability?

    That view should be built in two layers.

    The first layer is a pure capability map. It contains only business capabilities and their relationships. It should be readable without knowing the technology landscape.

    The second layer is an implementation overlay. It adds the applications, services, and containers that contain or directly execute business logic for each capability.

    Shared infrastructure is deliberately excluded from this overlay. Databases, queues, event buses, event stores, and object storage are important, but they make the functional view noisy. They belong in dependency, reliability, and impact views.

    This distinction matters.

    A functional architecture view should show where business responsibility lives.

    An impact view should show the shared infrastructure and technical dependencies that can affect that responsibility.

    Where C4 and DCL each matter

    C4 remains the structural source of truth.

    It describes systems, containers, relationships, dependencies, and the technical landscape in which the software operates.

    DCL remains the behavioural source of truth.

    It describes capabilities, outcomes, effects, events, policies, and lifecycle progression.

    Neither model should be forced to become the other.

    The value comes from using both as complementary evidence. With disciplined vocabulary, an LLM can correlate them and derive useful projections:

    • capability-to-container allocation
    • functional architecture views
    • fragmentation analysis
    • structural and behavioural consistency checks
    • business-aware blast-radius analysis
    • capability implementation explanations

    Conclusion

    This experiment did not produce an automatic mapping engine between C4 and DCL.

    It produced something more credible: two complementary sources of architectural evidence.

    C4 explains what exists and how it connects. DCL explains what the system is responsible for and what business behaviour is affected when things change or fail.

    The most promising output is a derived functional architecture view: a capability map first, followed by an implementation overlay showing where business logic lives.

    The next step is to make the analysis more structured, especially for impact analysis. If a C4 failure can be expressed not only as broken dependencies but as affected capabilities, outcomes, actors, and lifecycle progression, architecture knowledge becomes much more useful to both humans and AI.

  • I Didn’t Build DCL for AI Governance—AIShowed Me It Could

    When I started designing the Declarative Capability Language (DCL), I wasn’t thinking about regulatory compliance. My goal was much simpler: I wanted a language that could describe what a system is responsible for, entirely independent of frameworks, programming languages, or deployment technologies.

    A language centred on capabilities, intent, outcomes, effects and policies rather than controllers, services and APIs. The problem I was trying to solve was architectural clarity.

    Recently I’ve been sharing the language with different large language models, not to generate code, but to critique the language itself. I asked them the difficult questions you’d ask any design partner:

    • Where is the language weak?
    • What concepts are missing?
    • Does it make sense?
    • Could you build software from this?
    • What kinds of systems could it describe?

    Some of the answers were expected, mostly surrounding syntax tweaks or better examples. But then something unexpected happened. Different models, working completely independently, began identifying use cases that I hadn’t originally considered.

    The strongest recurring theme? AI governance and system assurance.

    The Regulatory Challenge

    Across every industry, there is increasing pressure to demonstrate how software behaves. For AI systems, this pressure is even greater.

    The EU AI Act, GDPR and other regulatory frameworks ask organisations to answer questions such as:

    • What decisions does this system make?
    • Which data does it process?
    • What safeguards exist?
    • Where is human oversight required?
    • What evidence is produced?
    • How can these decisions be audited?

    Most organisations already have answers to these questions. The problem is where those answers live.

    • Architecture documents.
    • PowerPoint slides.
    • Wiki pages.
    • Design reviews.
    • Code comments.
    • Slack conversations.

    None of them is strongly enough connected to the software they describe. Documentation gradually becomes an approximation of reality.

    Why DCL Fits Naturally

    The interesting observation wasn’t that DCL had features specifically designed for regulation. It didn’t. Instead, the language already described the exact concepts that governance teams care about because they happen to be the exact concepts architects care about.

    In DCL’s semantic model:

    • A capability declares what a system is responsible for.
    • Actors describe who or what participates.
    • Rules constrain behaviour.
    • Outcomes make possible results explicit.
    • Effects describe interactions with the outside world.
    • Policies define the architectural expectations surrounding execution.
    • Events and observability describe the evidence a system produces.

    Those concepts exist because they are useful architectural concepts. It turns out they are also useful governance concepts. That wasn’t something I planned. It emerged from the semantic model.

    From Documentation to Compiler Verification

    Traditional governance is largely document-driven. A policy is written, architects interpret it, developers implement it, and auditors review the result. Every single step introduces room for interpretation and the certainty of drift.

    DCL suggests a different approach: making the expression of responsibility part of the capability definition itself.

    By attaching policies directly to capabilities, the compiler can validate the structure. Documentation, diagrams, and reports all become generated projections of the exact same semantic model. Rather than asking whether the documentation is up to date, the documentation simply becomes another view of the source truth.

    AI as a Design Partner

    One of the most enjoyable parts of building DCL has been using AI as a sounding board. The models weren’t caught up in the syntax; they recognised that DCL’s semantic model could become a foundation for operational assurance.

    That feedback has already actively influenced the language. Recent additions such as agent actors, tool effects, and confidence policies were introduced to better describe AI-native systems, while remaining strictly true to the original principles of the language. The language didn’t become “an AI language”, it just became a better language for describing modern, autonomous systems.

    Looking Forward

    I still see DCL first and foremost as a language for describing business capabilities. That hasn’t changed. What has changed is my understanding of where those descriptions become valuable.

    • Architecture.
    • Documentation.
    • Code generation.
    • AI-assisted development.
    • Governance.
    • Regulatory reporting.

    They all depend on the same thing: an accurate, unambiguous description of what the system is responsible for.

    The more I explore DCL, the more I realise that the language isn’t just describing software. It’s describing organisational responsibility. And perhaps that’s why AI kept discovering these new applications before I did.

  • AI Won’t Replace Engineers. Ticket-Driven Development Already Did.

    Introduction

    For a while now, it has been impossible to open LinkedIn, Hacker News, or X without seeing endless posts asking and debating a single existential question: Will AI replace software engineers? Seems like every week, a new autonomous coding agent or large language model promises to render human developers obsolete, fueling a cycle of tech anxiety and defense.

    But I think we are asking the wrong question entirely.

    The panic assumes that AI is arriving to disrupt a thriving, deeply intellectual craft. The reality is much quieter and far more uncomfortable. In many organisations, software engineering has already been reduced to ticket processing. We transitioned from creative system builders to assembly line workers long before the first LLM was trained. AI didn’t create this trend; it simply arrived after it had already begun.

    When Engineers Solved Problems

    If you go back 20 years, the daily footprint of a software engineer was vastly different. Teams were much smaller, and product teams operated with a lean, direct focus. We did not have dedicated DevOps departments, platform engineering teams, or isolated data teams to handle specialized tasks. Instead, we had fewer specialisations. As an engineer, you were expected to touch everything: you wrote the front-end and back-end, designed the databases, managed the deployments, and literally owned the build servers.

    This lack of structural buffering meant engineers were naturally closer to customers. Because there was no complex game of telephone passing through multiple layers of product management, engineers were the ones designing, building, deploying, and supporting systems end-to-end.

    Ultimately, engineers owned outcomes. This ownership materialized in very practical ways across the entire lifecycle of a project:

    • Gathering requirements directly from stakeholders to understand the true business need.
    • Designing databases from scratch, ensuring data models fit long-term goals.
    • Building deployment scripts manually to safely push code to production environments.
    • Supporting production directly, making you immediately accountable if something broke.
    • Creating internal tooling to optimize the team’s workflow and fix engineering friction.

    Engineers weren’t handed pre-packaged solutions or step-by-step checklists. They were given ambiguous business problems and trusted to figure out how to solve them.

    Agile Was Never Supposed To Lead Here

    When the Agile Manifesto was written, it was a radical document created by engineers, for engineers. It was an engineering discipline, not a framework intended for project managers. At its core, agile was a mindset; it wasn’t about what you did, it was about how you did it. It was about us, our craft, and our relationship to the work.

    The origins of agile were deeply rooted in Extreme Programming (XP) practices, where technical excellence and adaptability went hand in hand. The goal was to establish tight feedback loops, commit to continuous improvement, and foster direct customer collaboration. Originally, agile tried to bring engineers closer to customers, eliminating bureaucratic walls so we could build better software.

    Being agile simply meant wanting faster feedback and having the ability to pivot as the customer’s needs changed. Crucially, back then, the tickets or task breakdowns were created by the engineers themselves. A ticket wasn’t a top-down directive; it was our decomposition of the problem. It was how we chose to slice a complex engineering challenge into manageable pieces.

    Somewhere along the way, the industry lost the plot. What began as an empowering engineering mindset was co-opted, turned upside down, and transformed into just another rigid delivery process. The very thing that had brought a group of engineering thought leaders together to challenge it in the first place.

    The Rise of Ticket-Driven Development

    Today, the digital board, whether in Jira, Azure DevOps, or another tool, is the centre of gravity for almost every software team. Regardless of whether an organisation claims to run Scrum or Kanban, this digital board has become the de facto operating system of modern tech companies.

    This infrastructure caused a profound shift in how work is framed: we moved from solving problems to processing tickets.

    • Before: The challenge was broad and meaningful: “We need a customer management system.”
    • Now: The challenge is narrow and mechanical: “Add field X to screen Y.”

    During backlog refinement, the conversation shifts away from the actual business problem. Instead, the entire ceremony becomes an exercise in assigning a number. We need to face it: estimates are just “guesstimate” guesses disguised as data. Yet, teams spend hours debating whether a task is a three or a five, because the primary goal of the meeting has become getting numbers on tickets.

    The entire ecosystem is now governed by rigid mechanics:

    • Acceptance criteria that define exactly what to code, leaving zero room for creative interpretation.
    • Story points that turn abstract effort into a rigid currency.
    • Velocity metrics that track how fast a team can burn through that currency.

    This framework introduces dangerous systemic side effects. It creates local optimisation, where individual developers maximise their own output at the expense of the overall system. It causes a total loss of context and a loss of ownership, leading to reduced decision-making on the ground. Why think deeply about the architecture when the ticket tells you exactly which line to change?

    Ultimately, we changed the definition of success. Success used to be measured by outcomes (the value we delivered to the business). Now, success is measured by outputs, how many tickets we moved to the right. The ticket became the hard boundary of an engineer’s responsibility. If it isn’t in the acceptance criteria, it isn’t our problem.

    The Feature Factory

    To compound the loss of agile as an engineering discipline, the power dynamic in tech companies shifted. Product management took full control of the process. Rather than collaborating as equal partners in problem-solving, many organisations began operating like assembly-line factories.

    The pipeline became completely standardised and linear:
    Business Problem → Product Vision → Backlog → Ticket → Engineer → Test → Release

    In this assembly line, the engineer’s role has been deeply diluted. The daily routine is reduced to a repetitive, four-step cycle: implement the instructions, test the code, merge the pull request, and move on immediately to the next card in the queue.

    When you treat engineers like factory workers, you fundamentally alter how technical decisions are made. A classic exchange happens every day in these environments: an engineer realises that a robust, correct solution to a problem is much larger and more complex than the product owner expected. The product owner, knowing they have to manage expectations with higher management or external customers, immediately pushes back.

    To keep the assembly line moving, engineers are forced to compromise. They accept a simpler, short-term patch or hide behind the dreaded “MVP” (Minimum Viable Product) label. This compromise adds another heavy layer to the company’s technical debt catalogue, always accompanied by the empty promise of “we will fix that later.”

    Corporate guidelines often state that engineers must follow “best practices.” But inside the feature factory, the true, unwritten engineering standard isn’t best practice; it is JFDI.

    The most worrying aspect of ticket-driven development is not the process itself. It is what happens to the engineer after ten years inside that process. If every problem arrives pre-defined, every requirement arrives pre-refined, every architecture decision has already been made, and every task is reduced to a ticket, when exactly does an engineer learn how to discover requirements, formulate designs, evaluate trade-offs, and create systems from first principles?

    Speed and output beat craftsmanship every single time.

    The Quiet Disappearance Of Innovation

    Innovation Used To Live Between The Tickets

    Historically, some of the most impactful software innovations were never requested by a product manager or outlined in a business requirement document. They lived in the spaces between the tickets. Many of today’s engineering disciplines began as engineers solving their own problems. Continuous integration, deployment automation, developer tooling, internal frameworks, and observability platforms didn’t emerge because they appeared on a roadmap. They emerged because engineers were given enough ownership to improve the ecosystem around the product.

    These projects emerged because engineers were curious, frustrated by friction, or simply driven by craftsmanship. They explored the wider ecosystem around the product to find hidden efficiencies. Today, that organic exploration is gone. In fact, you would be lucky if your engineers explore the backlog, let alone the broader technical ecosystem.

    If It’s Not In Jira It Doesn’t Exist

    The modern corporate landscape is governed by a hyper-rigid prioritisation and utilisation culture. Driven by the pressure for predictable delivery, management demands that every single hour of an engineer’s day be accounted for and mapped to an official corporate goal.

    This creates an environment where if a task is not in Jira, it simply does not exist. But true innovation rarely begins as a ticket. Innovation usually starts with informal, creative sparks:

    • “I wonder if…”
    • “This seems painful…”
    • “There must be a better way…”

    When every minute must be allocated to a pre-approved user story, there is no room left for these sparks to catch fire. By optimising out the “inefficiency” of unstructured time, companies have inadvertently optimised out their own capacity to innovate from within.

    True innovation requires slack in the system. It requires empty space on a calendar to experiment, fail, prototype, and think. Ticket-driven environments view empty space as inefficiency. Many organisations now rely on hackathons to stimulate innovation. The irony is that hackathons exist precisely because day-to-day engineering no longer provides enough space for experimentation. We celebrate two days of creativity because we’ve unintentionally removed it from the other 250 working days of the year.

    Have We Stopped Teaching System Creation?

    To be absolutely clear, this is not a criticism of the new generation of software engineers. It is a sharp criticism of modern engineering environments that rarely, if ever, give developers the structural opportunity to build and flex these critical skills.

    Because we have spent years treating engineers as ticket-processors, we have fundamentally changed what it means to grow as a developer. This raises an uncomfortable question for the modern tech landscape: Could a typical engineering team today actually build a product from a completely blank sheet of paper?

    When you strip away the layers of product management buffering, you have to wonder if a modern team can:

    • Discover requirements directly by talking to users and navigating business ambiguity.
    • Formulate a design that balances immediate needs with long-term architectural stability.
    • Model the domain accurately without a pre-baked schema handed down to them.
    • Identify technical trade-offs and confidently choose what not to build.
    • Create a roadmap that sequences engineering milestones logically over months, not days.
    • Operate independently without a steady stream of pre-written, pointed tickets.

    By over-indexing on ticket execution, we are no longer teaching or practising the art of holistic system creation. We are training developers to be highly proficient at colouring inside the lines, but we have stopped teaching them how to draw the lines in the first place. How will these engineers become senior? How do they become architects?

    DevOps, Platform Engineering And The Abstraction Trap

    To understand how the modern engineering role became so watered down, we have to look at our infrastructure. Let’s acknowledge the good first: CI/CD was a massive improvement for our industry. DevOps solved real, painful deployment bottlenecks, and Platform Engineering solves genuine architectural complexity. The creation of Internal Developer Platforms (IDPs) has done wonders to reduce cognitive load, allowing developers to spin up environments with a single click.

    However, we have walked right into an abstraction trap.

    The fundamental purpose of any abstraction is to remove complexity, not to remove understanding. Unfortunately, the industry has confused the two.

    Modern engineers certainly don’t need to know every single Kubernetes API or Terraform syntax by heart. But the abstraction shouldn’t insulate them from foundational operational realities. Engineers still deeply need to understand:

    • How systems fail: What happens to the application when a downstream dependency drops or a network splits?
    • How systems scale: What actually happens under the hood when traffic spikes, and where are the bottlenecks?
    • Operational consequences: How does a simple code change impact memory, CPU, or database performance?
    • Costs: What is the financial reality of writing highly inefficient code in a cloud-native world?
    • Observability: How do we safely monitor, trace, and debug an issue across a distributed system?

    When we abstract away the infrastructure so completely that developers have no idea where their code lives or how it runs, we destroy their ability to build resilient software. Platform engineering should empower developers, but ownership of the system’s runtime behaviour must ultimately remain with the engineers who built it. Another view, of course if certain engineers do know this, yet processing tickets excludes them from using or acting on this knowledge.

    Platform Engineering removed operational complexity. Ticket-driven development removed engineering autonomy.

    AI Changes Everything

    This brings us to the ultimate turning point of our current era. The reason the tech industry is experiencing such widespread anxiety about AI is that we are looking at a total inversion of what makes engineering valuable.

    Historically, implementation was incredibly expensive. Translating a business requirement into functional, production-ready code required deep technical expertise, time, and significant capital. Because it was difficult, writing the code was the premium skill.

    Today, that reality is shifting overnight. Implementation is rapidly becoming cheap, fast, and highly commoditised. Modern generative AI can increasingly produce:

    • Clean code across multiple programming languages in seconds.
    • Comprehensive unit and integration tests based on basic inputs.
    • Thorough technical documentation that updates automatically (never seen so much markdown).
    • Complex boilerplate infrastructure and repetitive system scaffolding.

    This shift forces us to confront a critical question: What happens to the software engineer when implementation is no longer the scarce skill?

    The answer is that the centre of gravity moves. When the mechanical act of writing code costs next to nothing, the market value shifts squarely back to the human-centric elements of engineering: problem solving, keen judgement, systems thinking, clear communication, macroscopic architecture, and true ownership.

    The deep irony, of course, is that these are the exact skills that have been slowly eroded from an engineer’s day-to-day responsibility over the last decade of moving tickets across the board. For senior engineers who lived through the previous generation and remember what it felt like to own an entire system end-to-end, flexing these muscles will feel natural, like returning home. But for a generation trained exclusively inside the feature factory, this paradigm shift will require a fundamental re-learning of the craft.

    AI does not just represent a danger to engineers; it affects product managers/owners, too. So far, the tooling is very much a solo sport. Vibe coding is experimental, but a more serious relationship with AI requires context engineering, of which we are still adapting and still learning. Be it spec-driven development, Hypervelocity engineering, or just navigating Codex or Claude code with your own set of skills and agents. We don’t need tickets from the product anymore; we need the epic / big picture (the problem) as part of the context. Do we still need to work in two-week sprints, as you can implement a lot in two weeks with AI? Maybe with the return of the engineers, product owners will return to thinking about product vision and SWOT analysis of the competitors rather then slice and dicing requirements into tickets. The methodology needs to change again when we learn have to use AI as a team sport.

    The Return Of The Engineer

    To look forward is not to indulge in blind nostalgia. This is not an anti-AI manifesto, nor is it a call to completely dismantle the foundations of Agile. Both technology and frameworks have their place in modern development. Instead, this is an acknowledgement that the pendulum is finally swinging back. By taking over the repetitive, assembly-line mechanics of software development, AI is inadvertently paving the way for a renaissance of the craft.

    The future engineer may look surprisingly familiar to those who remember the origins of the discipline. Stripped of the need to spend hours writing boilerplate code or manual test cases, the developer of tomorrow will return to the core responsibilities that defined the role twenty years ago.

    They will need to:

    • Deeply understand customer problems rather than blindly accepting pre-written feature descriptions.
    • Design holistic solutions that account for architecture, performance, security, and long-term viability.
    • Challenge assumptions and push back when a requested feature or business logic fails to make logical sense.
    • Own outcomes end-to-end, measuring their success by the value brought to the business rather than the velocity of their sprint board.
    • Work alongside AI as a high-level director, utilizing the machine to generate the bricks while they focus entirely on designing the castle.

    We are entering an era where the implementation becomes vastly easier, but the thinking becomes significantly harder. The engineers who thrive will not be those who can write syntax the fastest, but those who can think the most deeply about the systems they build.

    Conclusion

    The job of a software engineer was never just to write code. The job has always been to solve problems. For a while, we confused the two because writing code was the most technically demanding part of the process. AI is simply exposing that mistake.

    We spent decades building feature factories optimized for rapid delivery. In the process, we forgot that engineers are not conveyor belts. They are thinkers, architects, and problem solvers. The organisations that remember this truth will massively outperform those that do not.

    Everyone in tech is currently on a journey where technologies and processes change rapidly—and as we have seen with the industrialization of Agile, change is not always for the better. Engineers who started their careers only knowing ticket-driven development face the biggest challenge. They are the ones who must adapt quickly. Growth now means learning how to understand the underlying business problem, conceptualizing holistic solutions, and developing deep insights into aspects of the system far beyond the repository. With AI tools at their disposal, their success will depend on their ability to provide the machine with the right context, constraints, and instructions.

    We should not fear AI; we should welcome it.

    For years the industry has asked engineers to behave like compilers, processing tickets through increasingly efficient delivery pipelines. AI is simply taking over the repetitive environment we built for ourselves. The opportunity now is to reclaim engineering.

    Is AI threatening software engineering?

    Or is it exposing what software engineering was always supposed to be?

    The organisations that continue treating engineers as ticket processors will discover that AI processes tickets faster. The organisations that cultivate problem solvers will discover that AI amplifies them.

    The future belongs to engineers who understand the problem, not just the implementation.

    .

  • AI Needs Better Architectural Representations

    Ask an LLM to modify an existing system, and it will often produce convincing code.

    But ask it questions such as:

    • What business capability owns this behaviour?
    • What guarantees does this process provide?
    • Which outcomes are possible?
    • What happens if an external dependency fails?
    • Which teams or systems would be affected if this service disappeared?

    And the answers quickly become uncertain. The problem isn’t necessarily the model. The problem is the representation.

    We Optimised Architecture For Humans, Not AI

    Discuss how current architectural artefacts evolved.

    Current architectural artefacts evolved over decades to help humans manage complexity. We created a rich ecosystem of specialised tools, each serving a distinct purpose:

    • Source code: Defines implementation logic.
    • APIs: Expose integration contracts.
    • Sequence diagrams: Visualise runtime interactions.
    • C4 diagrams: Map structural boundaries and relationships.
    • Infrastructure diagrams: Illustrate deployment topology.
    • ADRs: Capture historical decisions and trade-offs.
    • Wiki pages: Provide narrative context and onboarding material.

    These artefacts remain enormously valuable. They have helped generations of engineers build increasingly complex systems.

    But they were designed primarily for human consumption.

    They partition knowledge across multiple views, each describing only part of the system. None provide a complete semantic description of system behaviour.

    Structural representations such as C4 are extremely effective at explaining what a system is made of. They do not, however, capture business intent, guarantees, outcomes, or operational expectations.

    Humans compensate for these gaps remarkably well.

    AI cannot.

    The Missing Semantic Layer

    Humans excel at filling in the blanks using intuition and tribal knowledge. AI cannot do this. While current artefacts explain the how and the where it runs, they rarely make explicit:

    • Time: how behaviour evolves over time.
    • Business responsibility: what the system is actually accountable for.
    • Intent: why a capability exists.
    • Outcomes: the complete set of possible results.
    • Invariants: Conditions that must always remain true.
    • Guarantees: reliability, consistency, security, and operational expectations.
    • Effects: the downstream mutations and side effects of an action.

    Because these elements are often missing, scattered, or implicit, AI struggles to reason about systemic change.

    This matters because architecture increasingly lives outside the codebase.

    Important knowledge frequently exists as:

    • tribal knowledge shared in conversations
    • PowerPoint diagrams
    • wiki pages
    • framework conventions
    • Slack discussions
    • institutional memory

    Humans can navigate this ambiguity. Machines struggle.

    AI Understands Structure Better Than Ambiguity

    Large language models exhibit remarkable linguistic capabilities, but they do not possess intuition.

    They cannot reliably infer missing architectural context or resolve conflicting information.

    To reason effectively about software systems, AI performs best when information is:

    • Explicit: avoiding hidden assumptions.
    • Finite: bounded and well-defined.
    • Structured: organised predictably.
    • Causally connected: tracing clear paths from intent to outcome.
    • Semantically clear: using unambiguous terminology.

    Unfortunately, much of our architectural documentation looks very different.

    Typical engineering documentation is:

    • prose-heavy
    • incomplete
    • contradictory
    • stale
    • fragmented across multiple tools

    When AI encounters this ambiguity, its usefulness declines rapidly. Instead of reasoning about architecture, it starts guessing.

    The result is hallucinated behaviour, misunderstood boundaries, and inconsistent implementations.

    The English Language Paradox

    We currently use AI to consume large volumes of documentation because natural language is the universal interface shared by humans and machines.

    English is the bridge between human intent and machine execution. But treating natural language as the sole source of truth for architecture may be a design flaw. Natural language is excellent for explanation. It is much less effective as an executable architectural model.

    This creates several problems:

    • The Translation Tax: We force AI to continuously translate vague prose into logical structures.
    • The Hallucination Trap: Natural language is inherently ambiguous, requiring AI to infer missing context rather than compute facts.
    • The Scale Limit: Complex distributed systems become increasingly difficult to describe precisely using prose alone.

    The goal is not to eliminate natural language. The goal is to stop treating natural language as the only source of truth for architecture. Natural language should explain architecture, not define it.

    Source Code Is No Longer Enough

    Historically, human engineers held the system’s entire architectural blueprint in their heads and manually translated that vision into code. The source code was the ultimate artefact because humans controlled the context.

    Increasingly, this dynamic is flipping. AI is transitioning from a passive autocomplete tool to an autonomous agent that translates high-level intent into functional code. As artificial intelligence takes on the bulk of implementation work, code ceases to be the primary constraint. Instead, the quality and precision of the underlying architectural representation become the ultimate bottleneck.

    The Cost of Abstract Context

    When AI is tasked with generating code without a formal architectural model, it operates in a vacuum. If a system’s true architecture remains trapped in legacy formats, the AI is starved of essential context.

    We drastically limit AI capabilities when architecture is left as:

    • Tribal knowledge: Unwritten rules shared only during human conversations.
    • PowerPoint diagrams: Static, non-computable shapes boxes floating on a slide.
    • Wiki pages: Outdated text files decoupled from the actual production environment.
    • Framework conventions: Hidden assumptions embedded silently inside software libraries.
    The AI Implementation Tax

    Deprived of a rigorous semantic blueprint, an LLM cannot guess the broader systemic constraints. It treats every code generation task as an isolated problem.

    This information deficit directly forces the AI to produce:

    • Hallucinated behaviour: Creating logical pathways that violate unwritten system rules.
    • Inconsistent implementations: Solving the same technical problem three different ways across different files.
    • Accidental complexity: Introducing bloated, redundant code paths because it lacks a bird’s-eye view of the system.
    • Weakened guarantees: Silently breaking critical architectural boundaries, security protocols, and data consistency models.

    What Might Better Representations Look Like?

    When code is generated at machine speed, structural rot happens at machine speed too. We cannot safely delegate implementation to AI until we can formally feed it the architectural guardrails.

    To bridge the gap between human intent and AI execution, we must move away from passive text and static boxes. Future architectural representations must be machine-readable, deterministic data models. They need to transform abstract concepts into explicit, computable parameters.

    An AI-optimised architectural representation must explicitly define eight core dimensions of a system:

    • Responsibility: The precise domain boundaries and business capability ownership. It clearly states exactly what a specific component is accountable for.
    • Intent: The underlying business logic and technical justification. It records why a particular piece of software or architectural pattern exists.
    • Outcomes: A complete, finite matrix of all possible technical and business results. It eliminates guessing by mapping out every valid end-state.
    • Rules: The core system invariants and business logic conditions that must always hold true, acting as unbreakable guardrails for AI code generation.
    • Effects: A clear inventory of all downstream mutations, state changes, data emissions, and external interactions that occur across system boundaries.
    • Guarantees: The operational baselines, detailing the exact security protocols, reliability targets, latency SLAs, and data consistency expectations.
    • Time: The temporal lifecycle of the system. It models how data state changes, how events flow, and how system behaviour evolves over time.
    • Causation: The deterministic lineage of system events. It provides a clear trace explaining exactly why a particular outcome occurred.

    By formalising these dimensions into a unified, machine-computable semantic layer, we give AI the missing blueprint it needs. This allows automated agents to safely write code, predict systemic failures, and evolve architectures without human intervention.

    My Experiment

    Theory is valuable, but execution is the ultimate validation. Over the last few months, I have been actively experimenting with a Declarative Capability Language (DCL) to see if a structured semantic layer could fundamentally change how artificial intelligence interacts with software architecture.

    The most striking, unexpected outcome of this experiment has been just how naturally large language models reason over capability-based descriptions.

    Testing the AI’s Cognitive Limits

    Instead of overwhelming the models with thousands of lines of syntax, I provided them with explicit, deterministic definitions of a system’s core parameters:

    • Capabilities: What the system is fundamentally equipped to do.
    • Intent: The objective behind any given operation.
    • Outcomes: The explicit, finite end-states of an action.
    • Effects: The downstream mutations and side effects.
    • Policies: The strict governance, security, and operational rules.
    • Lifecycle progression: How system states evolve chronologically.
    The Results: Autonomous Systemic Reasoning

    When provided with this blueprint, multiple LLMs independently recognised DCL as a highly optimal representation format for AI systems. Because DCL exposes semantic intent rather than granular implementation details, the models were able to reason about the system at a much higher, more sophisticated level than when given raw source code alone.

    DCL’s core interaction model explicitly maps system behaviour as a direct causal chain:

    Intent → Outcomes (via Capability).

    By removing the noise of loops, variables, and framework boilerplate, we create a unified language designed from the ground up to be “implementable by both humans and AI.” It proves that when we give AI the right structural context, it stops guessing and starts engineering.
    Intent → Outcomes (via Capability) and is designed to be “implementable by both humans and AI”.

    Closing thoughts

    As software development transitions from human-written code to AI-assisted generation, the discipline of software architecture must fundamentally evolve. The traditional methods we use to document, map, and discuss systems are no longer sufficient for a world run by autonomous agents.

    The core question driving software engineering is permanently shifting.

    We are moving away from the legacy paradigm:

    • “How should we represent systems so humans can implement them?”

    And rapidly moving toward an entirely new frontier:

    • “How should we represent systems so both humans and AI can reason about them?”

    This shift represents more than a mere change in tooling. It demands a complete philosophical overhaul of how we define system boundaries, intent, and guarantees. Solving this problem will become one of the most critical and defining architectural challenges of the coming year.

    This is precisely why I am building the Declarative Capability Language (DCL). By moving away from ambiguous prose and focusing strictly on intent, outcomes, and capabilities, DCL provides the exact machine-computable semantic layer this new era demands. It bridges the gap between human strategy and machine execution, offering a concrete answer to how we will design, validate, and safely scale AI-driven software systems.

  • Why I Created DCL: Treating Capability as a First-Class Architectural Construct

    https://russelleast.github.io/Capability-Language

    The Problem Was Never Code

    I didn’t set out to create a programming language.

    If anything, creating a language sounded like a terrible idea.

    The world doesn’t need another language.

    What it does need is a better way to describe software systems.

    Throughout my career, I’ve worked as a developer, technical lead, solution architect, and principal architect across a range of industries and systems. During that time, I’ve noticed the same pattern repeatedly.

    The business talks about capabilities.

    Architecture talks about services, domains, integrations, and platforms.

    Engineering talks about APIs, queues, databases, workflows, and code.

    Operations talks about reliability, observability, recovery, and support.

    Everyone is describing the same system.

    Nobody is describing it in the same way.

    The Loss of Architectural Intent

    The original capability — the thing the business actually needs the system to do — becomes fragmented across:

    • PowerPoint decks
    • Capability maps
    • Architecture diagrams
    • ADRs
    • Jira tickets
    • Source code
    • Infrastructure definitions
    • Tribal knowledge

    Eventually the implementation becomes the source of truth. The problem is that implementation is not intent.

    A service tells me how something works. It does not necessarily tell me why it exists.

    An API tells me how to call something. It does not necessarily tell me what responsibility it owns.

    A workflow tells me what happens. It does not necessarily tell me which outcomes matter.

    Somewhere between business strategy and software delivery, we lose the architectural meaning of the system.

    Architecture’s Documentation Problem

    As architects, we’ve spent years trying to bridge this gap.

    • We create diagrams.
    • We write ADRs.
    • We document domains and integrations.
    • We build capability maps.

    All of these are useful. All of them suffer from the same weakness. They are passive artefacts. They cannot be validated. They cannot be compiled. They cannot tell us when architectural intent has drifted. Over time, they become snapshots rather than living representations of the system.

    The Missing Layer

    The longer I worked in architecture, the more I became convinced that something fundamental was missing.

    • We have languages for implementation.
    • We have languages for infrastructure.
    • We have languages for APIs.
    • We have languages for data.

    But we do not have a language for capability. We do not have a language that treats business responsibility as a first-class architectural construct. That realisation became the foundation of the Declarative Capability Language (DCL).

    A Different Starting Point

    DCL starts with a simple premise:

    A capability is a unit of architecture.

    Not a service.

    Not a controller.

    Not an endpoint.

    Not a deployment boundary.

    A capability is a responsibility that a system exposes.

    Once that responsibility is defined, we can describe:

    • The intent it accepts
    • The outcomes it produces
    • The rules it follows
    • The effects it causes
    • The events it emits
    • The policies that constrain it
    • The lifecycle it progresses through

    These are not documentation conventions.

    They become language constructs.

    Capability as Code

    The goal of DCL is not to replace code.

    The goal is not to replace architecture.

    The goal is not to generate entire systems automatically.

    The goal is to create a durable, compiler-verifiable representation of architectural meaning.

    A representation that sits between business intent and implementation.

    A representation that can survive organisational change, technology change, and system evolution.

    A representation that makes capability itself part of the architecture.

    Why AI Makes This More Important

    When I started exploring AI-native systems, orchestration runtimes, and architecture intelligence platforms, the problem became even more obvious.

    AI systems perform best when context is:

    • explicit
    • structured
    • machine-readable
    • unambiguous

    Most architecture today is none of those things. Instead, architectural knowledge exists as a mixture of documents, diagrams, code, meetings, and tribal knowledge.

    Humans can often navigate this ambiguity.

    AI struggles with it.

    If we want AI to participate meaningfully in software design and delivery, we need better representations of architectural intent.

    We need something more precise than a PowerPoint diagram and more durable than a wiki page.

    An Experiment in Architectural Language

    In many ways, DCL is an experiment. An experiment in whether capability can become a first-class language primitive. An experiment in whether architecture can be expressed with the same precision we expect from code. An experiment in whether business intent can survive the journey from strategy to software delivery.

    I don’t know whether DCL will ultimately succeed. What I do know is that the problem it is trying to solve is real. Business capability deserves to be more than a box on a diagram.

    It deserves to be part of the language.

  • Capabilities as a unit of architecture

    The industry keeps changing its technical shapes

    Over the past thirty years, software architecture has undergone multiple revolutions. We have moved from monoliths to service-oriented architectures, from services to microservices, from containers to serverless platforms, from synchronous APIs to event-driven systems. Every few years the industry discovers a new way to organise software and, for a time, it feels like we have found the answer.

    Yet despite all this change, I have become increasingly convinced that we may be missing something fundamental. Not a framework. Not a platform. Not a deployment model. A unit of architecture.

    The disconnect between business language and software structure

    The more systems I have worked on, the more I have noticed an odd disconnect between how businesses describe themselves and how software is ultimately implemented.

    At the highest levels of an organisation, strategy is often discussed in terms of capabilities. Enterprise architects create capability maps. Business architects model organisational capabilities. Transformation programmes are funded around capabilities. Leaders discuss where capabilities need to improve, where they need to be modernised, and where they provide competitive advantage.

    Capabilities are often the language of strategy.

    A business rarely says: “We need a new service.”

    It says:

    • “We need to onboard customers faster.”
    • “We need to process payments more efficiently.”
    • “We need to improve fraud detection.”
    • “We need to support self-service account management.”

    These are capabilities. They describe what an organisation is responsible for doing.

    How capabilities disappear during delivery

    Yet something curious happens as work progresses from strategy into delivery. The capability begins a long journey.

    1. A business capability becomes an initiative.
    2. The initiative becomes an epic.
    3. The epic becomes a collection of user stories.
    4. The stories become designs.
    5. The designs become APIs, services, handlers, repositories, entities, commands, and queries.

    At every step we gain implementation detail. But at every step we seem to lose sight of the capability itself. By the time we reach the code, the thing the business originally cared about has often disappeared entirely.

    Open a typical codebase, and you will find controllers, services, handlers, repositories, aggregates, entities, and DTOs. What you rarely find is a first-class representation of the capability that justified all of those things existing in the first place.

    The capability survives only as tribal knowledge. It exists in conversations, diagrams, documentation, and people’s heads. But it is rarely represented directly in the software itself. This has always struck me as strange.

    The capability is arguably the reason the system exists, yet it becomes one of the least visible concepts in the implementation.

    Why Domain Driven Design felt like the answer

    For many years, I believed Domain-Driven Design was the answer to this problem.

    I still believe Domain Driven Design was one of the most important advances in software architecture. It encouraged us to think in terms of business concepts rather than technical layers. It introduced a shared language between technical and non-technical stakeholders. It challenged us to model the problem instead of merely modelling data.

    For a long time I advocated this approach. Then I had a conversation that forced me to reconsider some assumptions. While discussing a design approach with an engineering leader, I was told:

    “The team are happy to follow whatever approach you recommend. Just please don’t do Domain Driven Design.”

    When good intentions turn into accidental complexity

    The comment genuinely surprised me. The explanation was not that the business concepts were wrong. The problem was that previous attempts had resulted in an explosion of types, abstractions, and complexity. Estimates grew. Development slowed. The resulting model became difficult to understand and maintain.

    The easy response would be to argue that Domain Driven Design had been applied incorrectly. Perhaps it had. But I found myself asking a different question.

    Why are we working so hard to bend general-purpose programming languages into representing business concepts in the first place?

    Modern business systems revolve around concepts such as responsibilities, capabilities, outcomes, policies, rules, and processes.

    Yet our programming languages provide classes, functions, methods, interfaces, and modules.

    There is an obvious mismatch.The business describes responsibilities.The language describes implementation mechanics.

    Perhaps Domain Driven Design was never the destination. Perhaps it was evidence of a deeper problem.

    A long history of bridging the gap

    For two decades, software engineers have been inventing architectural patterns that attempt to bridge the gap between business meaning and implementation structure.

    • Layered architecture.
    • Hexagonal architecture.
    • Clean architecture.
    • CQRS.
    • Domain Driven Design.
    • Event sourcing.
    • Vertical slice architecture.

    Each represents an attempt to move software closer to the problem it is trying to solve.

    Why vertical slices get closer

    Among these approaches, I have always found vertical slice architecture particularly interesting.

    Unlike many earlier styles, it does not organise software primarily around objects or technical layers. Instead, it begins to organise software around behaviour.

    • Not Customer, but Register Customer.
    • Not Order, but Place Order.
    • Not Invoice, but Generate Invoice.

    This feels natural because change requests rarely arrive in the form of object modifications. They arrive as changes to capabilities. The business wants to:

    • improve onboarding.
    • Reduce payment failures.
    • Introduce social login.
    • Add automated verification.

    The discussion is almost always capability-centric.

    The capability is still missing

    Vertical slices move closer to this reality. Yet even there, the capability itself remains implicit.

    We still ultimately implement it through handlers, commands, queries, services, repositories, and infrastructure concerns. The capability is present in spirit, but not as a first-class architectural construct. This led me to a realisation. Perhaps the reason capabilities disappear is that our implementation languages have no native way to represent them.

    We begin with capabilities. We end with technical constructs. Everything in between is translation.

    The thing that survives every rewrite

    The capability survives organisational change. It survives technology shifts. It survives rewrites. It survives migrations from monoliths to microservices, from on-premise systems to cloud-native platforms, and perhaps now from traditional applications to AI-enabled systems.

    The implementation changes. The capability remains. Which raises a question I have found increasingly difficult to ignore.

    If capability is the fundamental unit of business responsibility, why is it not also a first-class unit of software architecture?

    And if it were, what would that change about how we design, build, analyse, and evolve systems?

    A final question

    That question ultimately led me down a path I was not expecting. A path that started not with a new framework or architecture pattern, but with a much simpler idea:

    What if the capability never had to be lost in translation?

  • The Disappearing Architect, and Why We Might Miss Them

    The Rise of Engineering Career Ladders

    Years ago, most medium and large technology organisations had architects. Today, many organisations are reducing dedicated architecture functions in favour of engineering career ladders: Senior Engineer, Staff Engineer, Principal Engineer. Architects have not disappeared, but architectural responsibilities are increasingly being absorbed into engineering leadership roles.

    In many ways, that can be seen as a healthy correction. The industry was right to challenge architecture when it became a disconnected governance function: diagrams no one implemented, review boards that slowed down delivery, and decision-making detached from operational reality. Cloud platforms, DevOps, and platform engineering have shifted more responsibility to teams and brought architectural decisions closer to the people building and running systems.

    That was mostly a good thing. But in some organisations, the pendulum may have swung so far toward engineering ownership that system-level architectural thinking is becoming undervalued.

    This is not because engineers are incapable of thinking architecturally. Many do. And many of the best architects came from engineering backgrounds. The issue is not capability. It is structure.

    Architectural thinking operates at a different level of abstraction and over a different time horizon. Engineering tends to focus on implementation, correctness, maintainability, performance, and delivery. Architectural thinking focuses more on system behaviour, boundaries, interactions, long-term evolution, and trade-offs.

    Engineers often ask:

    • How do we build this?
    • What technology should we use?
    • How do we deploy and test it?

    Architectural thinking asks:

    • Should this capability exist at all?
    • Where should it live?
    • What dependencies does it create?
    • What fails when this fails?
    • What will this decision look like in five years?

    Both perspectives matter. But they are not the same perspective. And when architecture is fully collapsed into delivery-based feature teams, something important can get lost.

    Architecture Needs Space To Breathe

    Feature teams are optimised for delivery. They are measured by roadmap progress, sprint commitments, team outcomes, production health, and local ownership. Those are reasonable incentives. But they naturally reward solving the problem directly in front of the team.

    Architectural thinking often requires something else: the space to step back from immediate delivery pressure and ask what the system, platform, and organisation are becoming over time.

    When architectural responsibility is absorbed entirely into delivery teams, architecture does not disappear. But it often loses the space to breathe.

    That matters because many of the most important architectural questions sit outside any one team’s backlog:

    • Are our boundaries still fit for purpose?
    • Can teams evolve independently?
    • Are we accumulating architectural drift?
    • Are we creating accidental complexity faster than we are removing it?
    • Is our platform becoming a force multiplier or a coordination bottleneck?
    • Are we scaling the system, or merely scaling the effort required to change it?

    These are not feature-level concerns. They are system-level concerns. And they often have no obvious owner.

    Architecture Maturity Versus Technical Debt

    This is where architecture maturity becomes important. Engineers often discuss code quality, refactoring, and technical debt. Architectural thinking asks a broader question:

    Is the organisation becoming easier or harder to evolve?

    Architecture maturity is not just about whether today’s design is acceptable. It is about whether the wider system, operating model, team topology, platform, and governance model are becoming more coherent and more resilient over time.

    A mature architecture is one that can absorb growth, support independent team evolution, tolerate change, and reduce accidental complexity rather than constantly producing more of it.

    Those questions rarely belong neatly to a feature team. Often, nobody is explicitly rewarded for asking them.

    What Architecture Is Actually Optimising For

    One reason architecture is often misunderstood is that architects are rarely measured by the same outcomes as delivery teams.

    Feature teams are expected to deliver capabilities.

    Architectural thinking is responsible for ensuring those capabilities can continue to operate and evolve successfully over time.

    Its outputs are rarely features.

    Its outputs are system qualities.

    • Reliability
    • Scalability
    • Security
    • Resilience
    • Operability
    • Observability
    • Recoverability
    • Compliance
    • Adaptability
    • Cost efficiency
    • Architectural coherence

    These qualities are easy to overlook because they are not usually visible during feature delivery.

    They become visible when they are absent.

    • Customers notice outages.
    • Engineers notice operational friction.
    • Businesses notice rising costs and slower delivery.

    Architecture exists to influence those outcomes before they become problems.

    This is perhaps why architecture has always struggled to demonstrate its value.

    Organisations are very good at recognising visible value: features shipped, delivery speed, customer outcomes, roadmap progress.

    They are much worse at recognising invisible value: avoiding scalability failures, preventing future coupling, reducing operational fragility, identifying security risks before launch, or preserving the ability for teams to evolve independently.

    Architecture is often judged poorly because its best outcomes look like nothing happened.

    • A scalability failure that never occurred.
    • A security incident that never happened.
    • A costly rewrite that was avoided.
    • A product that continued evolving long after its original design life.

    Success is often measured by the problems that never materialised. That does not make the work less important. It simply makes it harder to explain.

    Did Organisations Lose Faith In Architecture?

    Many of the criticisms levelled at architecture over the years were justified. Some architecture functions became detached from delivery, overly governance-focused, and disconnected from operational reality. But that does not necessarily mean organisations stopped needing architecture. It may simply mean they stopped seeing the value because the value was poorly articulated. Perhaps businesses did not lose faith in architecture. Perhaps many never fully understood what architecture was for in the first place.

    Architecture was often presented as diagrams, review boards, standards, governance, and documentation. Those are outputs. They are not the purpose.

    The purpose of architecture is to guide systems toward desirable outcomes and away from undesirable ones. The artefacts are merely tools. The value lies in shaping the conditions under which systems remain reliable, secure, scalable, maintainable, and capable of evolving over time.

    Why AI Changes The Equation

    For a while, the gap was easier to ignore. With cloud-native, many architectural choices became standardised. Infrastructure patterns matured. Deployment models became repeatable. Observability stacks, platform abstractions, and managed services reduced the number of foundational decisions each organisation had to make from first principles.

    That made it easier to flatten architecture into engineering seniority and still function reasonably well.

    AI-native systems may expose the limits of that model. These systems introduce concerns that are not purely implementation concerns:

    • Model selection
    • Grounding
    • Memory
    • Orchestration
    • Evaluation
    • Agent coordination
    • Runtime governance
    • Human oversight
    • Cost behaviour

    These are not simply feature decisions. They are system decisions.

    An engineer might ask: How do I integrate an LLM?

    Architectural thinking asks: What role should reasoning play in this system in the first place?

    An engineer asks: Which model should we use?

    Architectural thinking asks: What happens when that model changes, degrades, or becomes economically unviable?

    An engineer asks: How do I call the API?

    Architectural thinking asks: What new dependencies, failure modes, operational risks, and governance challenges have we just introduced?

    These are questions that span teams, products, platforms, and business strategy. Historically, they are exactly the kinds of questions architecture disciplines emerged to address.

    The Real Question

    This is why I think the more interesting question is not whether organisations need architects.

    It is whether they have preserved architectural thinking while reshaping the role.

    Many organisations seem to assume that architectural capability naturally emerges at higher levels of engineering seniority.

    Sometimes it does.

    Many principal engineers absolutely think architecturally. Many staff engineers do too. But seniority and architecture are not synonyms.

    Promoting someone into a more senior engineering band does not automatically create the incentives, space, or organisational mandate to think about cross-system coherence, long-term evolution, architecture maturity, or systemic risk.

    Engineers create value by delivering capability. Architectural thinking creates value by shaping the conditions under which capability can continue to be delivered safely, reliably, and coherently over time.

    The real question is not whether organisations need architects.

    It is who is thinking about the system qualities nobody else is incentivised to own.

  • The Return of Orchestration in AI-Native Systems

    Introduction

    For the last decade, cloud-native architecture has optimised for stateless execution: ephemeral compute, horizontal elasticity, and infrastructure abstraction. That model remains highly effective for APIs, event handlers, and short-lived workloads. But AI-native systems, especially agentic and long-running ones, this introduces a different set of runtime demands: continuity, memory, supervision, and durable coordination.

    Stateless systems worked extremely well

    For the past decade, cloud-native architecture matured into a predictable, robust standard. While containerisation initially solved deployment headaches, it birthed a new challenge: orchestration. This friction sparked an evolution in hosting that moved us away from managing ‘servers’ and toward managing ‘intents.’

    From the operational rigour of Kubernetes to the abstraction of Fargate, Container Apps, and Lambda, we entered the golden age of the stateless microservice. With request/response as the dominant interaction pattern, we offloaded the hardest parts of distributed systems being scaling, healing, and resource allocation to the cloud provider.

    Statelessness was our superpower; it simplified operations to a single metric: can we spin up another instance fast enough to handle the next request? This simplicity allowed us to treat infrastructure as a commodity, but as we move into AI-native systems, that ‘fire and forget’ simplicity is hitting a new wall.

    Operational Simplicity: The “Cattle, Not Pets” Standard

    The brilliance of statelessness lay in its operational silence. By stripping away local state, we removed the need for complex data synchronisation and “sticky” sessions that used to plague legacy systems. If a container became unhealthy, Kubernetes or Fargate didn’t waste time trying to diagnose or “fix” it; the orchestrator simply terminated the instance and spun up a fresh one. This “cattle, not pets” philosophy meant that system recovery was instantaneous and automated. Engineering teams could sleep through the night because the infrastructure was self-healing by design, governed by simple health checks rather than manual intervention.

    Predictability: Deterministic Scaling

    This architectural constraint provided a level of predictability that redefined the software lifecycle. Because every request was treated as an isolated, independent event, performance became deterministic. We could simulate high-traffic bursts in staging with total confidence that the 1,000th instance would behave exactly like the first (although this was not always easy). This consistency bridged the gap between development and production, allowing engineers to focus on shipping business logic rather than hunting down the idiosyncratic “ghosts in the machine” that typically haunt stateful environments.

    Cost-Efficiency: Scaling to Zero

    Financially, the shift to serverless and managed containers turned infrastructure into a true utility. The ability to “scale to zero” meant we finally stopped paying for idle CPUs waiting for work. Whether using Lambda’s per-millisecond billing or the event-driven scaling of Container Apps, cost became a direct, transparent reflection of actual demand. This efficiency allowed startups to run enterprise-grade architectures on a shoestring budget, radically optimising margins by ensuring that every pound spent was tied to a successful request/response cycle.

    AI-native systems introduce orchestration pressure

    For years, infrastructure dominated architecture discussions, and stateless services defined our runtime thinking. However, the rise of AI-native systems has fundamentally shifted these requirements, introducing a new level of orchestration pressure. Albeit an older problem in new clothes.

    Not every AI workload creates orchestration pressure of course. A prompt-in, response-out inference endpoint can still be treated much like any other stateless service. The pressure appears when systems become:

    • or dependent on persistent memory across sessions.
    • long-running,
    • tool-using,
    • multi-step,
    • human-in-the-loop,
    • multi-agent

    AI systems introduce six pressures that traditional request/response systems rarely had to solve:

    • Reasoning is inherently stateful: Effective AI requires maintaining the context of a problem-solving process.
    • Orchestration matters: Coordinating multiple models and tools requires precise oversight.
    • Execution is probabilistic: Unlike deterministic code, AI outputs vary, requiring logic to handle uncertainty.
    • Conversations are long-running: Interactions often span multiple exchanges, necessitating persistent session management.
    • Memory and supervision matter: Systems must remember past interactions and allow for human-in-the-loop or automated oversight.
    • Streaming matters: Real-time data flow is essential for the responsive, “live” feel of modern AI.

    These shifts have made high-level coordination patterns architecturally vital once again. We are seeing a resurgence in the importance of actors, workflows, event systems, orchestration runtimes, and stateful execution as the backbone of the next generation of software.

    This pressure manifests in several critical operational requirements. Maintaining conversational continuity and managing memory ensures the system doesn’t “forget” the user mid-task. Because AI is non-deterministic, robust retries and long-running execution are necessary to see complex goals through to completion, even when a model stumbles.

    Furthermore, as systems move toward agency, tool coordination and runtime planning become the glue that connects reasoning to action. Finally, because these models can hallucinate or drift, supervision provides the essential guardrails for reliability.

    Ultimately, these are as much orchestration concerns as AI concerns. They represent a shift from simply calling an API to managing a complex, living process.

    This marks a definitive departure from the “stateless microservices” era. In that world, we treated every request as an isolated event, offloading state to a database and assuming the network was the only real point of failure.

    But in an AI-native world, the “request” is no longer a discrete event; it is a persistent, evolving journey. We can no longer afford to treat the execution layer as a passive pipe. Instead, the runtime must become an active participant; one capable of holding context, recovering from probabilistic failures, and managing the lifecycle of a thought. We are moving from a world of static endpoints to a world of dynamic, stateful agents.

    Orchestration is becoming the runtime

    Traditional orchestration was largely concerned with infrastructure:

    • start containers
    • schedule workloads
    • scale replicas
    • recover failed nodes

    AI-native orchestration operates at a different level:

    • coordinate reasoning
    • manage memory
    • invoke tools
    • supervise execution
    • route work between agents
    • recover long-running processes

    The orchestration layer is moving up the stack. It is no longer simply deciding where code runs. It is increasingly deciding how work progresses.

    The return of durable execution

    A phrase I have heard a few times over the years: “failure is not an option.” Ok, so how many 9s? 4 or 5? To be told it must never fail, never go down for maintenance. My fellow architects, I am sure you have had to carefully explain that nothing can be 100% or it’s going to cost you lots of money.

    However, AI has changed the stakes. AI systems increasingly behave more like long-running processes than traditional web requests. When a “request” is actually a twenty-minute chain of reasoning involving multiple tool calls and human approvals, a simple network glitch shouldn’t mean starting from scratch. This is where the marketplace has responded with heavy hitters like Temporal, Dapr, and LangGraph.

    • Temporal has become the gold standard for durable workflows (this is very cool stuff). It treats the entire execution as a “virtual thread” that can be paused, moved between servers, and resumed months later. If a worker dies mid-thought, Temporal performs execution recovery so seamlessly the LLM never even knows it “tripped.”
    • Dapr (Distributed Application Runtime) offers a more modular approach. By using Dapr Workflows and its Actors building block, you get state persistence and resiliency baked into your sidecar. It’s particularly powerful for those looking to build “Durable Agents” that can survive across distributed environments without being locked into a single workflow engine.
    • LangGraph shifts the focus to the cognitive loop. While Temporal and Dapr handle the “plumbing” of durability, LangGraph manages the state of the logic—ensuring the agent’s memory and branching paths remain consistent even as the “conversation” evolves.

    Durable execution is the ability to persist workflow progress and resume from the last known step rather than restarting from the beginning after failure, pause, or redeployment. AI workflows frequently pause for:

    • human approval
    • external systems
    • asynchronous events
    • scheduled execution

    In this new architecture, we aren’t just calling APIs; we are managing the lifecycle of a thought. We’ve moved from stateless fire-and-forget to a world where the runtime substrate guarantees that if a process starts, it will finish.

    Why actor systems feel very relevant

    If you’ve ever worked with actors, for me it is Akka.NET, you know it changes how you think about software. You stop seeing systems as a series of database rows and start seeing them as a collection of living, breathing entities. Three years ago, I created a solution using actors (Akka.NET) in a commercial project; at the time it felt niche but the correct architectural choice for the problem. Today, it feels like a prerequisite for the agentic era.

    AI agents are, by definition, autonomous entities. This brings several core actor concepts back to the forefront:

    • State Isolation and Ownership: In an actor system, only the actor can touch its state. This is exactly what an AI agent needs—a dedicated sandbox where its specific memory, personality, and “thought history” are protected from the rest of the system.
    • Distributed Identity: Actors allow us to treat an agent as a first-class citizen with a unique ID. Whether that agent is helping one user today or a million tomorrow, the system can route messages to that specific “brain” across a cluster effortlessly.
    • Supervision and Resilience: My favourite part of Akka.NET was the supervision tree. If a child actor fails, the parent decides how to handle it. In AI, where model outputs are probabilistic, and tool calls often fail, having a hierarchical “manager” that can supervise and recover a “worker” agent is essential for stability.

    The Key Insight:

    “An AI Agent is essentially an Actor with a Brain.”

    While traditional actors use hard-coded logic to respond to messages, AI agents use LLMs to decide their next move. But the packaging remains the same. Frameworks like Dapr Actors or Microsoft Orleans are seeing a resurgence because they provide the perfect “host” for an agent—giving it a permanent home, a mailbox for communication, and the guarantee that its state will survive a crash.

    We are moving away from treating AI as a utility function and toward treating it as a distributed population of stateful entities.

    Multi-agent systems

    The rise of multi-agent systems amplifies these orchestration concerns. Once work is distributed across specialised agents, research agents, planning agents, coding agents, review agents. The platform must coordinate communication, state propagation, supervision, and recovery across the entire population. What appears to be an AI problem quickly becomes a distributed systems problem.

    Observability becomes behavioural

    Traditional observability focused on:

    • latency
    • throughput
    • error rates

    AI-native observability introduces new concerns:

    • reasoning traces
    • tool execution chains
    • memory usage
    • agent interactions
    • prompt lineage
    • decision provenance

    We are no longer observing requests, we are observing behaviour. This is another reason orchestration matters.

    Kubernetes and the runtime platform

    In the stateless era, if a pod crashed, K8s spun up a new one, and we didn’t care because the state was in the database. But as we move toward AI-native systems, we are seeing a fundamental tension: the “stateless” nature of Kubernetes is colliding with the “stateful” needs of AI.

    • The Orchestration Gap: Traditional Kubernetes orchestration focuses on availability: is the container running? AI orchestration requires continuity: is the reasoning process still alive? This forces us to move beyond simple deployments toward a more sophisticated use.
    • StatefulSets and the Persistence Tax: While StatefulSets provide stable identifiers and persistent storage, they come with a significant operational tax. In my experience with Akka.NET on EKS, managing scalability and handling pod rescheduling without losing the “hot” state of an active agent requires a level of configuration that traditional web-dev teams rarely encounter.
    • Operational Implications: We are moving from “cattle” (disposable pods) back toward something more like “pets”—or perhaps “managed entities.” The operational burden shifts from scaling horizontally to managing locality. If an agent is mid-conversation, the orchestrator needs to ensure the “brain” and its “memory” stay close together to avoid the latency of constant database round-trips.

    The Key Insight:

    “Kubernetes is increasingly being used as the foundation upon which stateful execution engines are built.“

    The “runtime substrate” must now do more than just provide CPU and RAM; it must provide a durable home for long-running logic. This is why tools like Dapr are becoming so popular; they abstract that “persistence tax” away from the developer while letting Kubernetes handle the heavy lifting of the infrastructure.

    What this means for serverless-first architectures

    Serverless is not going away. Fargate, Container Apps, Functions, and Lambda remain excellent solutions for:

    • APIs
    • event handlers
    • integration endpoints
    • document processing
    • short-lived workloads

    The architectural shift is that AI-native systems introduce a second runtime model alongside them. Increasingly we will see hybrid architectures:

    • Stateless services remain serverless.
    • Long-running reasoning moves to orchestration runtimes.
    • Agent memory moves to specialised stores.
    • Workflow engines manage durable execution.
    • Event systems connect everything together.

    The question is no longer: Serverless or stateful? It becomes: Which parts of the system require continuity?

    The likely outcome is not the replacement of serverless, but its coexistence with a new generation of orchestration runtimes.

    For many organisations, Kubernetes may remain invisible behind services such as Azure Container Apps or AWS Fargate, while specialised runtimes such as Temporal, Dapr Workflows, LangGraph, or managed agent platforms provide the durability and coordination layer above it.

    The future is likely hybrid. Not everything needs durable execution. But increasingly, the most valuable AI workloads will.

    Closing thoughts

    The interesting architectural shift may not be AI models themselves. It may be the return of orchestration.

    For the last decade we optimised for stateless execution, treating infrastructure as an interchangeable commodity and reducing software to independent request/response interactions.

    AI-native systems are reintroducing concepts many architects thought had become niche: workflows, actors, supervision, durable execution, coordination, and long-lived state. The next generation of platforms will not simply host intelligence. They will orchestrate it.

    The architectural mistake would be to treat AI-native workloads as if they were simply another stateless API tier. For many of the most valuable systems, continuity is becoming a runtime requirement, not an implementation detail.

    References

    View at Medium.com

  • Why AI Systems Are Fundamentally Runtime Problems

    We are moving from a world where ‘Software is a Document’ (Code) to a world where ‘Software is a Process’ (Inference). In this new world, the compiler isn’t our last line of defense—the runtime is.

    TL;DR: The Infrastructure Shift

    • The Model is Not the System: In production, AI is no longer a prompt/response task; it is a distributed runtime problem involving state, memory, and orchestration.
    • AI systems reintroduce durable execution concerns: Traditional cloud-native “stateless” patterns fail AI agents. Reliability requires Durable Execution—where a system doesn’t “forget” its train of thought if a container restarts.
    • Code as a Process: We are moving from a world where software is a document (static code) to a world where software is a process (live inference). Success depends on runtime supervision, not just model benchmarks.

    Introduction

    Today, most of the current AI discussions focus on models:

    • model capability
    • benchmarks
    • prompting
    • fine-tuning
    • context windows

    But once AI systems move toward agentic, conversational, or long-running AI workflows and beyond isolated demos and into production environments, a different set of problems begins to dominate.

    The difficult part is often no longer the model itself. It becomes the runtime. Traditional web apps (REST/CRUD) treat every request as a clean slate. AI requires “Session Persistence” on steroids.

    The shift from model-centric to system-centric thinking

    An LLM on its own is relatively simple: Input –> inference –> output

    But production AI systems rarely operate in isolation. Real systems involve:

    • orchestration
    • tool execution
    • memory
    • retrieval
    • retries
    • supervision
    • permissions
    • temporal workflows
    • streaming events
    • human interaction
    • distributed state
    • observability
    • failure handling

    At that point, the architecture starts to resemble a distributed runtime system more than a traditional request-response application. It’s not just about saving a chat history in a database; it’s about Execution State.

    In a stateless architecture, a container restart midway through a 5-step agentic workflow isn’t just a hiccup; it’s a lobotomy. The system loses its ‘train of thought’ because that state wasn’t durable.”

    Runtime complexity emerges quickly

    Even relatively small AI-enabled systems introduce runtime concerns such as:

    • long-running execution
    • partial failure
    • coordination between components
    • asynchronous workflows
    • state persistence
    • conversational continuity
    • cost-aware execution
    • retry semantics
    • execution tracing
    • non-deterministic behaviour

    These are not prompt engineering problems. They are runtime architecture problems. In a runtime environment, you can’t “prompt” your way out of a 504 Gateway Timeout or a rate-limit error. If your system logic lives inside a prompt, you lose the ability to use standard Circuit Breakers or Backoff policies effectively. A “Runtime Problem” approach treats the LLM as a fallible library call, not the “brain” of the application.

    Why traditional web architecture patterns are insufficient

    Many existing application architectures assume:

    • short-lived requests
    • deterministic execution
    • stateless services
    • predictable control flow

    AI-native systems challenge these assumptions. Agentic and conversational systems often require:

    • persistent context
    • dynamic planning
    • adaptive execution paths
    • background processing
    • memory over time
    • orchestration across multiple capabilities

    This starts to push architectures toward:

    • workflow runtimes
    • actor systems
    • event-driven orchestration
    • distributed state models
    • graph execution systems

    The big gap I see here is that the industry is settled on cloud-native stateless architecture and not thinking about AI native stateful architecture. Many will introduce AI into their products with much support from the business. The side effects will start when production usage increases. The risk is that systems will become unstable, which will lead to the mistaken belief that the AI is at fault.

    The return of orchestration

    One of the most interesting developments in AI systems is the renewed importance of orchestration. For years, many architectures moved toward increasingly stateless service models. But intelligent systems frequently require:

    • coordination
    • supervision
    • execution tracking
    • runtime decision-making
    • stateful interaction over time

    This creates architectural pressure toward systems capable of managing:

    • execution lifecycles
    • state transitions
    • temporal reasoning
    • distributed coordination

    In many ways, this resembles problems already explored in:

    • actor systems
    • workflow engines
    • distributed systems
    • event sourcing
    • stream processing

    The actor model provides supervision trees which act as runtime supervisors. Imagine an agent (worker) and a deterministic script (supervisor). The supervisor doesn’t just watch; it has the power to kill, restart, or roll back the Agent’s state. This moves AI safety (excluding AGI) from “ethics” to “systems engineering”.

    Debugging Nightmare

    In traditional software, if a bug happens at runtime, you can often replicate it with a unit test. In AI, because of non-determinism, the “bug” might only happen 1% of the time under specific concurrency loads. If we view AI as a runtime problem, we need tools that can “record” the exact state, tokens, and environmental variables to reconstruct a failure.

    Observability becomes critical

    AI systems also introduce new operational challenges. Traditional observability already struggles with distributed systems. AI-native systems add:

    • probabilistic behaviour
    • reasoning chains
    • dynamic execution graphs
    • runtime tool selection
    • evolving context state

    Understanding why a system behaved a certain way becomes significantly harder. This makes observability a first-class architectural concern rather than an operational afterthought.

    Runtime architecture may become the real differentiator

    Model capability will continue to improve and commoditise. But the systems capable of operating intelligently, safely, and reliably in production will increasingly depend on runtime architecture quality:

    • orchestration
    • supervision
    • memory
    • execution semantics
    • observability
    • coordination
    • resilience

    The future of AI systems may depend less on who has the best model, and more on who builds the best runtime.

    Example


    Closing thoughts

    The industry is still early in understanding what production AI architecture really requires. Many current systems are still model-centric. But over time, I suspect the focus will increasingly shift toward runtime design:

    1. how intelligent systems coordinate?
    2. how they maintain state?
    3. how they reason over time?
    4. how they recover from failure?
    5. how they remain observable?
    6. how humans interact with them safely?

    The interesting architectural problems are only just beginning.

    References

  • Fluid interface for data access with SQL Server

    While working on my current project I came up with this simple fluid interface used for data access with SQL Server. My current project doesnt use any ORMs for reasons that would wage war, so I won’t go into those details. I came up this with fluid interface to reduce the mundane ADO.NET code and to reduce repetition.

    As with an ADO.NET Command object, this code executes non query or return a scalar or a  data reader.  My goal was to try and reduce as much code as possible especially with the data reader. I wanted to not use strings and ordinals and keep the code simple, so with a bit of experimenting I managed it with a class called “DynamicDbDataReader” which is a DynamicObject.

    As a generic library, I had to allow for connections to be supplied / configured by allowing a connection instance to be supplied, a connection string or my preferred method, the name of the connection string that existing in the config file which I would keep as a string constant and pass it into the method.

    The parameters that are supplied are done using a string for the parameter name and the object containing the parameter value. Method chaining is used to add more that one parameter and the data type is inferred automatically. All parameters are input only.

    Example: Running a stored procedure with many parameters that does not return a result set (ExecuteNonQuery)

    [code language=”csharp”]
    With.StoredProcedure("SomethingTo_Insert")
    .UsingConfiguredConnection("SomeConnectionStringName")
    .WithParameter("id", something.Id)
    .And.WithParameter("name", something.Name)
    .And.WithParameter("desc", something.Description)
    .And.WithParameter("severity", something.Severity)
    .And.WithParameter("systemKey", something.SystemKey)
    .ExecuteNonQuery();[/code]
    Example: Running a stored procedure that returns a scalar which in this case is a boolean (ExecuteScalar)
    [code language=”csharp”]
    bool result = With.StoredProcedure("Somthing_Exists")
    .UsingConfiguredConnection(DatabaseConnections.SomeDatabase)
    .WithParameter("name", name)
    .ExecuteScalar<bool>();[/code]
    Example: Running a stored procedure with no parameters that does not return a result set using (ExecuteNonQuery)
    [code language=”csharp”]
    With.StoredProcedure("SomethingTodo")
    .UsingConnection(sqlConnection)
    .WithNoParameters()
    .ExecuteNonQuery();[/code]
    Example: Running a stored procedure that returns a data reader with parameters
    [code language=”csharp”]
    dynamic reader = With.StoredProcedure("Somthing_SelectAllWithOtherStuff")
    .UsingConfiguredConnection(DatabaseConnections.QueryStore)
    .WithParameter("searchId", organsiationId)
    .ExecuteReader(CommandBehavior.CloseConnection);

    while (reader.Read())
    {
    response.Something.Add(new SomeSummaryInfo
    {
    Id = reader.Id,
    Forename = reader.FirstName,
    Surname = reader.LastName
    });
    }

    reader.NextResult();

    while (reader.Read())
    {
    response.Tasks.Add(new OtherSummaryInfo
    {
    Id = reader.Id,
    Name = reader.Name,
    SomeId = reader.SomeId,
    SomeOtherName = reader.OtherName,
    DisplayOrder = reader.DisplayOrder,
    });
    }
    [/code]
    Example: Running a sql statement that has no parameters
    [code language=”csharp”]
    With.SqlStatement("DELETE FROM SomeTable")
    .UsingConfiguredConnection("DatabaseName")
    .WithNoParameters()
    .ExecuteNonQuery();
    [/code]
    In the event that a field name is spelt wrong when working with the dynamic reader, a ColumnNotFoundException will be thrown. The dynamic reader has methods on it for “Read()” and “NextResult()”.

    That’s it in a nutshell.

    You can download the code. its got a .doc extension but its really zip file. So download it and change the extension to get the code.
    dataAccessBuilder