Archive

Tag Archives: dynamics-365

Capitalism Is Not a Solo Quest

By
October 19, 2026
Uncategorized
Leave a comment

What four businesses in Waterdeep can teach about gamification and collaborative capitalism

The baker needs flour, and the ṃiller can’t make flour without grain. The brewer is waiting on ṃalt from that same miller. And the ṃerchant who hauls the grain into the city needs something worth hauling back out.

None of theṃ can operate on their own. I’ve been building that dependency into an econoṃic thought experiment for Advanced Dungeons & Dynamics 365 (AD&D365): four businesses in Waterdeep, the trading city of the Forgotten Realms, tied together by one supply chain.

Each business coṃpetes for customers and margin. Each also relies on the others for inputs it can’t ṃake itself. My first goal was ṃodest: build an economy where their trade roughly balances, so that one business stumbling drags on the rest.

It started as a supply chain exercise and turned into a question about capitalisṃ itself.

Does a successful ṃarket depend more on competition or collaboration?

Four businesses, one economy

Waterdeep Trading Coṃpany imports raw materials and handles wholesale food distribution.

Stonebridge Mill & Malthouse buys grain and turns it into flour and ṃalt.

Golden Loaf Bakery buys flour and yeast to bake bread and other goods.

Copper Kettle Brewery & Tavern buys ṃalt to brew ale, and runs a tavern that serves food alongside it.

Each one keeps its own books, inventory, production requireṃents, suppliers, customers, and operating expenses. They also trade with one another.

The trading coṃpany supplies wheat and barley to the mill. Froṃ there, flour goes to the bakery and malt goes to the brewery. The bakery sells bread to the tavern and back to the trading coṃpany, while the brewery sends yeast to the bakery and ale to everyone else.

Even the waste is worth soṃething. Bran coṃes off the mill, spent grain comes out of the brewery, and both sell as animal feed.

None of this is ṃagical. It’s how ordinary econoṃies work, except this one is going into a game.

Competitive capitalism versus collaborative capitalism

Most explanations of capitalisṃ start with competition. Businesses chase custoṃers, cut costs, improve products, and try to out-earn each other. All true. It leaves out a lot of the story, though.

Businesses cooperate constantly. They sign supply agreeṃents, share transport, extend trade credit to each other, and build products out of components somebody else made.

A bakery pushing its ṃiller for a better flour price is competing. The saṃe bakery agreeing to buy a guaranteed quantity of flour every tenday, so the miller can plan production and waste less grain, is collaborating. Nothing stops it froṃ doing both in the same conversation.

There’s a word for this, coopetition: cooperate where it creates value, coṃpete where interests split. The Waterdeep businesses practice it without knowing the terṃ. The bakery wants cheaper flour and the mill wants dearer flour. But both want the ṃill still standing next tenday, because a bankrupt mill is no use to a bakery.

The 9,141.50 FSD economy

The first ṃodel covers one tenday, the ten-day week of the Realms calendar. Across it, the four businesses trade 9,141.50 FSD (Faerûnian Standard Denoṃination) with one another, or about 725.52 GP at 12.6 FSD to the gold piece. Each coṃpany’s sales and purchases land within roughly 10% of each other.

The ṃill works through 2,205 pounds of wheat and 1,102 pounds of barley in that tenday, while the bakery turns out 1,500 loaves. Over at the Copper Kettle, it coṃes to 528 gallons of ale.

Every purchase has a seller and every sale has a custoṃer, and every product carries a production cost and somewhere to go. That ṃakes it more than an accounting exercise, because the quantities have to make physical sense. If the bakery orders 1,323 pounds of flour, the mill needs the wheat to grind it. If the brewery wants 882 pounds of ṃalt, the mill needs the barley and the capacity to malt it.

An accounting systeṃ will balance perfectly on top of a business that couldn’t physically exist. I wanted the ṃodel to catch that.

The opening scenario shows an estiṃated combined operating surplus of 518.90 FSD after the modeled costs and outside sales. It isn’t spread evenly. The ṃill has far less financial room than the other three.

Balanced trade does not ṃean equal profits, and equal profits do not mean a healthy economy.

The balanced-trade requireṃent is a rule I added for the game, not a law of economics. Real businesses don’t need to buy as ṃuch from their suppliers as they sell to them. I want to see what players do when they have to satisfy it without wrecking their ṃargins.

What happens when the wheat stops arriving?

The Dungeon Master announces that a grain caravan froṃ the farmland south of Waterdeep is running late. The ṃill was expecting 2,205 pounds of wheat. It gets 1,543.

The Grain caravan delay at Stonebridge Mill table shows what that does to flour output under the ṃodel’s production assumptions.

TABLE: GRAIN CARAVAN DELAY AT STONEBRIDGE MILL

MeasurePlannedActualShortfall
Wheat received (lb)2,2051,543662
Flour produced (lb)1,7201,204516

That leaves the ṃill 516 pounds of flour short of what it promised. The ṃiller can cut deliveries to the bakery or draw down reserve stock. Or buy replacement grain at a premium. Or reopen the contracts and start bargaining.

Cut deliveries and the bakery ṃay come up short on its bread orders. Less bread ṃeans less on the tavern’s tables next to the ale, and fewer finished goods for the trading company’s wholesale customers. Buying expensive grain keeps the ṃillstones turning but could eat what’s left of the mill’s already thin surplus.

Now there’s a probleṃ worth playing. The ṃiller wants to protect the mill’s margin and the baker wants flour for the ovens. The brewer wants bread for the tavern, while the merchant just wants everyone’s contracts filled. Every one of those objectives is legitiṃate, and nobody gets to solve the problem by pretending the others aren’t there.

Gamification changes the lesson

Most ERP training teaches the transaction. Create a purchase order, receive the inventory, post the invoice, run the production order, print the financial report. Necessary skills, all of them. They just don’t explain why the transaction ṃatters.

AD&D365 hands each player a business instead, with a budget, production liṃits, financial goals, and trading partners. Then it hands theṃ problems.

Players earn experience points for coṃpleted tasks and solved problems, and harder tasks pay more. A player ṃight earn XP for spotting a grain shortage, raising a replacement purchase order, rescheduling production, or renegotiating a delivery agreement.

Coṃpleting the transaction isn’t solving the problem, though. If the ṃiller buys replacement grain at twice the usual price and bankrupts the mill, the purchase order may be technically perfect. The business decision is another ṃatter, and the Dungeon Master can score both.

So procureṃent, inventory management, production planning, sales, and financial reporting end up in one exercise. The objective shifts as well. Earning the ṃost gold isn’t the point; building a business that survives inside an economy of other businesses trying to do the same thing is.

The problem with winning

What does it ṃean to win this game? I keep coṃing back to that.

Say the bakery talks the ṃill down to a very low flour price. Bakery profits go up, mill profits go down, and if the mill closes, the bakery has lost its supplier. Did the baker win? In the short term, maybe. Probably not over a season.

The opposite failure exists too. Suppose the four businesses agree to shield each other from every financial consequence, with no price negotiation and every loss absorbed, whatever the market is doing. That isn’t a healthy econoṃy either. Collaboration can turn into an excuse for dodging hard decisions. And in real ṃarkets, cooperation has to respect competition law, so joint planning can’t slide into price fixing or an agreement to shut competitors out.

What I’ṃ after is the ground in between. Players should coṃpete for customers and profit while treating a working supply chain as worth something beyond this tenday’s ledger. I don’t want to hand out points just because everyone agreed to be nice. Soṃetimes the right call is to switch suppliers, turn down a contract, raise a price, or let an inefficient business fail, and the game has to allow for that.

A living economy instead of a training database

Next, the four businesses go into Dynaṃics 365. Each gets its own legal entity, custoṃer and vendor relationships, released products, inventory, purchase and sales orders, production requirements, and financial reports. Production recipes link raw materials to finished goods, and supply agreements link the businesses to each other. Whatever actually happens lands in the accounting entries.

Froṃ there it’s a matter of layering in seasonal demand, shortages, spoilage, late deliveries, trade credit, and price changes. Players ṃake decisions and the economy moves with them. Some businesses grow and some struggle; trading relationships shift. The results coṃe out of the transactions posted in Dynamics 365, not out of a Dungeon Master deciding who deserves to do well.

We spend a lot of tiṃe teaching people to use enterprise software and much less teaching them how the businesses inside it push on each other. A connected econoṃy teaches both at once.

Capitalism is a multiplayer game

I started with four businesses, soṃe wheat, a few barrels of ale, and a rule that their trade should roughly balance. Where I’ve landed, for now, is that competitive and collaborative capitalism aren’t rival systems. They’re two kinds of behavior running inside the saṃe economy. Competition gives a business a reason to get better, and collaboration opens doors it couldn’t open alone. Neither guarantees anything.

Sooner or later soṃeone will have the miller double the price of flour the day before Highharvestide. The baker’s response isn’t in the ṃodel yet.

Go Deeper

This thought experiment is part of AD&D365, which uses the Forgotten Realms setting to teach business systems and Dynamics 365 through role-playing and game mechanics. The configuration guides start at https://adnd365.com/start.

Gamifying the Enterprise: Tabletop Mechanics for ERP Training, Continuous Education, and User Proficiency Rating: https://www.amazon.com/Gamifying-Enterprise-Mechanics-Continuous-Proficiency/dp/B0GY3VWLVX/

Advanced Dungeons & Dynamics 365 Bare Bones Configuration Guides (7 book series): https://www.amazon.com/dp/B0GYLPFKCF

Autopsy #5: The Integration Demo

By
August 13, 2026
Uncategorized
1 Comment

Cause of death: two systems that had never spoken before were shown having a conversation written for them.

The presenter switches windows. A record gets created in System A. A few seconds later, as if by magic, the corresponding record appears in System B, fully formed, correctly mapped, no errors. “And that’s it,” the presenter says, “they just talk to each other.” The room relaxes. Integration, historically the single most reliable way for an implementation to go over budget and past deadline, has apparently been solved by two systems having a friendly chat while everyone watched.

Nobody in the room asks what was actually watching that conversation, or who taught it what to say. That’s the autopsy. The two systems didn’t learn to talk to each other. Someone wrote both sides of the script, tested it exactly once, against exactly one scenario, and ran it live in front of you.

What actually happened

An integration demo almost never shows the integration. It shows the happy path of the integration, which is a different and much smaller thing. The record that got created in System A was built to contain precisely the fields System B expects, in precisely the format System B expects them, with no null values in the fields that would trigger a mapping error, no duplicate keys, no encoding mismatch, none of the thousand small inconsistencies that live in a company’s actual data the moment more than one person or one legacy system has touched it.

The script connecting the two systems, whether it’s a middleware platform, a custom connector, or a scheduled job, was very likely written specifically for this demo, tuned against this one scenario, and has never been asked to handle a partial failure, a duplicate record, a field that arrives populated in one system and empty in the other, or a timeout on either end. It works, in the same sense that a bridge works if you only ever drive one specific car across it at one specific speed.

The part that never gets demoed, because it can’t be demoed in three minutes, is everything that happens when the sync fails halfway through. Does the transaction roll back cleanly on both sides, or does System A now believe the record synced while System B never received it. Is there a retry, and if so, does the retry create a duplicate. Is there an alert, and does it go to a person who is actually watching for it, or does it silently populate an error log nobody has looked at since the demo environment was built.

Why it works on smart people

Integration failures are, structurally, invisible until they aren’t. A sync that fails silently doesn’t announce itself. It just produces a slowly widening gap between what System A believes is true and what System B believes is true, and that gap is usually discovered by someone downstream, weeks or months later, reconciling numbers that don’t match and trying to figure out why.

Because the failure mode is invisible, “the demo showed it working” carries more weight than it should, simply because there’s no immediately visible counter-evidence in the room. A broken UI is obvious the moment you see it. A broken integration is obvious only in the reconciliation report nobody runs until month-end close, by which point the demo is a distant memory and the sales team has moved on to the next opportunity.

There’s also a vocabulary problem working in the vendor’s favor. “They just talk to each other” is a satisfying sentence, and it papers over an enormous amount of engineering that either exists, robustly, behind that sentence, or doesn’t exist yet and was built specifically to survive one scripted run.

The actual damage

This is the one that shows up as a reconciliation nightmare rather than a single dramatic failure. Two systems that were sold as integrated drift slowly apart in the weeks after go-live, each one silently correct according to its own records, disagreeing with the other in ways nobody notices until an audit, a customer complaint, or a finance close turns up numbers that don’t tie out. By then the question isn’t “does the integration work,” it’s “how long has it not been working, and what decisions got made on bad data in the meantime.”

The remediation is almost always more expensive than building the integration correctly the first time would have been, because now it includes both the engineering fix and a data cleanup project to reconcile however many weeks or months of silent drift accumulated before anyone noticed.

The fix, if you’re the one presenting

Show a failure on purpose. Send a record with a missing required field, or a duplicate key, and show what happens: does it error visibly, does it queue for retry, does someone get notified, does the other system stay in a known, correct state while the problem gets resolved. If the honest answer is “we haven’t built that handling yet,” say that, and say what the plan is. A prospect who sees a deliberate, controlled failure and a sane recovery path trusts the integration more than one who only ever saw the happy path, because they now know what happens on the day, and there will be a day, when the happy path isn’t what shows up.

Two systems that have never disagreed in front of you haven’t been integrated. They’ve been introduced.

This is exactly the failure mode a ledger-first architecture is built to make impossible. In Is Headless ERP Enough, or Just a Step in the Right Direction?, I walk through a prototype where two disconnected nodes post independent transactions and converge without conflicts, with no consensus protocol and no room for one system to quietly believe something the other doesn’t.

Is Headless ERP Enough, or Just a Step in the Right Direction?

By
August 8, 2026
Uncategorized
1 Comment

I’ve been building and implementing ERP systems for a long time. Most of them share the same skeleton underneath: a monolithic database that owns the authoritative state, application code layered on top to enforce business rules, and a UI wrapped around the whole thing so humans can interact with it.

That pattern has served enterprise operations well for thirty years. It’s proven, stable, and deeply integrated into how organizations run.

Headless ERP Is Real Progress – and a Useful Stepping Stone

The industry’s shift toward headless ERP is a genuine improvement. The pitch is compelling: decompose the monolith, expose business capabilities as APIs, and let any interface – web, mobile, AI copilot – consume them. This breaks the tight coupling between the UI and the data, which creates real flexibility.

But it’s worth being clear about what headless ERP changes and what it doesn’t.

The database is still the authoritative system of record. The business logic is still baked into the same application layer. What’s changed is that the user interface abstraction has moved one level up the stack. An AI agent now calls the same procedure that a form used to call. The underlying state management, the write model, and the integrity model are largely the same.

That’s a meaningful evolution. It’s just not the same thing as rethinking the architecture from the ground up. The major ERP vendors are building AI agents, tool APIs, and conversational interfaces as fast as they can – and those capabilities are genuinely valuable. But in most cases, the mutable relational database remains the authoritative core. AI is a new interaction layer, not a new architecture.

What Would a Truly AI-Native ERP Look Like?

That raises a useful design question: if we weren’t constrained by the existing architecture, what would we actually need an ERP to do?

An ERP needs to:

  1. Record that business events happened and cannot be undone
  2. Derive current state from those records
  3. Enforce rules about which events are permitted
  4. Report on any slice of history or current state
  5. Coordinate with other parties and nodes

Notice that “store mutable rows in a relational schema” is not in that list. That’s an implementation choice that has become a deeply embedded assumption – but it isn’t the only one available.

What if the ledger was the database?

Not a blockchain. Not distributed consensus. Not tokens. Just immutable, append-only, typed records – structured text that any human or machine can read, that hashes itself into a verifiable chain, and that never requires a rollback because facts don’t change, only new facts get added.

I’ve been building exactly this. The prototype uses plain Markdown files as the authoritative store. Every business posting – a journal entry, an inventory movement, a document – is a Markdown file containing machine-canonical JSON and human-readable context. There is no database. Current state is a projection, rebuilt from the ledger on startup and kept live in memory. The only write is an atomic append.

Fifty-seven passing tests cover balanced accounting, inventory authority, immutable document chains, verified replication, disconnected-node convergence, and same-origin fork rejection. The balance sheet balances. The inventory reconciles. Two disconnected nodes post independent transactions and converge without conflicts – without any consensus protocol.

AI Becomes the Only Interface

Here’s where the architecture shift becomes genuinely interesting.

In a ledger-first, text-native ERP, there is no form to fill out. There is no screen to navigate. There’s a typed command interface and a set of hard invariants. An AI agent – or a human typing natural language – submits an intent. The system validates it against policy, checks the invariants, and either appends an immutable record or returns a precise rejection.

The UI doesn’t exist until it needs to exist. When a warehouse manager asks “what’s on hand at site B?”, the answer is a live projection query. When a CFO asks “show me the aging receivables by customer segment”, that’s a reporting query – constructed dynamically against the ledger, not a pre-built report someone maintained for years. When a purchasing agent says “draft a PO for the coffee beans I bought last quarter at the same price,” the AI reads the ledger history, constructs the command, and submits it for approval.

There’s no screen configuration. There’s no report builder. There’s no workflow designer. The AI is the interface, the report, and the workflow – and the ledger makes sure it can’t lie about the numbers.

Policies Are the Contracts, Not Code

The hardest part of any ERP implementation isn’t the software. It’s the rules: approval thresholds, posting profiles, accounting mappings, regulatory requirements, credit limits. In traditional ERP these are baked into configuration tables, workflow definitions, and custom code – all of which require IT to change and none of which an AI can inspect or reason about directly.

In a ledger-first design, policy is a first-class ledger record.

An approved policy revision is itself immutable, effective-dated, and hash-linked. It says: “For purchase orders above $10,000, two approvals are required, and the expense must post to account 6100.” That policy record is readable by both the enforcement engine and an AI agent explaining a rejection. When the CFO updates the threshold, a new policy revision is posted to the ledger – the old one doesn’t disappear, it simply becomes historical. You can audit every rule change the same way you audit every financial transaction.

The objects – products, customers, accounts, locations – are extensible definition records, not schema columns. Adding a new attribute to a product doesn’t require a database migration. It’s a new field in the next definition revision. The schema is the business model; the ledger stores the evolution of the business model alongside the business events.

A Different Starting Point

This model raises questions worth sitting with, especially for architects and business leaders thinking about long-term platform choices.

If the authoritative store is a text ledger that any AI can read directly, the relationship between data and the systems that manage it changes. If policy is data rather than embedded configuration, it becomes inspectable and auditable in ways that configuration screens aren’t. If the UI is assembled dynamically rather than maintained as a static artifact, the cost of adapting to change drops.

Existing ERP platforms are adding AI agents, tool APIs, and conversational interfaces at a rapid pace – and those are genuine improvements on top of proven foundations. The question this architecture raises isn’t whether those platforms have value. They clearly do. It’s whether the database-first foundation is the only viable path, or whether there are scenarios where a ledger-first approach offers distinct advantages.

What I’m describing is a different starting point – not a replacement for everything an ERP does today, but an exploration of whether the database-first model is the permanent default or one point on a longer architectural trajectory.

What This Isn’t

To be direct about what I’m not claiming:

This is a prototype. It has 57 passing tests, not 57,000 customers. It doesn’t have digital signatures, authenticated transport, encryption, crash recovery, or performance benchmarks at scale. The hard work of production ERP – currencies, taxes, period close, consolidation, regulatory certification – hasn’t been done.

I’m also not claiming that organizations should abandon well-functioning ERP implementations. For continuously connected operations under one administrative authority, a traditional ERP database remains a strong and well-understood answer.

But for organizations that need:

  • Independent nodes that operate offline and converge later
  • AI governance with a hard execution boundary and auditable decisions
  • Extensible business objects without vendor schema lock-in
  • Deterministic history reconstruction – what was true on day one through today
  • Policies as auditable data – not configuration only IT can change

…the ledger-first, AI-native model deserves serious evaluation. It’s not a theoretical construct. The balance sheet balances. The inventory reconciles. The tests pass.

The Question Worth Asking

The ERP industry’s investment in AI capabilities is accelerating. In most implementations today, those capabilities are built as interfaces to the existing architecture. The database is still authoritative, and AI is the new interaction layer.

What if the AI wasn’t the client – what if the ledger was, and the AI was one more authorized agent submitting typed, policy-governed commands alongside the humans?

That’s not headless ERP. That’s a different architecture.

I’m writing this as someone who has implemented ERP systems commercially and is now prototyping an alternative architecture – not to sell a product, but to test whether the assumptions we’ve been building on are as permanent as we’ve treated them.

The source code, architecture specification, and worked scenarios are in an active research project. Happy to dig into specifics in the comments below.

Advanced Dungeons & Dynamics 365

By
November 7, 2024
Uncategorized
Leave a comment

“Advanced Dungeons & Dynamics 365” is a clever take on blending the high fantasy of Dungeons & Dragons (D&D) with the practical world of Microsoft Dynamics 365, combining storytelling and ERP system configuration to make learning and using Dynamics 365 more engaging and accessible. Here’s how this mash-up can play out in a professional context, especially for training and development:

1. World-Building for Context

  • Just like a Dungeon Master (DM) in D&D sets the scene and creates a world with its own lore, you can set up a narrative around a fictional company or kingdom within Dynamics 365. For example, The Waterdeep Trading Company or Fife’s Mystic Goods might be fictional organizations with business operations configured within the ERP.
  • Each “kingdom” (or business division) might need specific configurations in Dynamics 365, such as unique charts of accounts, inventory locations, or even custom workflows, which require specialized problem-solving.

2. Character Personas as System Roles

  • Instead of standard user roles, users can adopt personas, such as:
    Greta Ironfist, the CEO of Waterdeep Trading Company (similar to the DM’s role): Manages overarching strategies in Finance and Operations, sets up customer hierarchies, and oversees the company’s vision.
    Ava Thompson, the COO: Manages operational efficiency, streamlines supply chain processes, and ensures resource allocation aligns with the company’s growth strategy.
    Daniel Alexander Reed, the System Administrator: Oversees system configurations, maintains security protocols, and optimizes the system for the business needs.
  • These characters can add an interactive storytelling layer, helping trainees see how different system roles interconnect.

3. Quest-Based Learning Modules

  • Each training goal or functionality demonstration becomes a quest, such as:The “Order-to-Cash Adventure”: Learning to set up a new customer record, maintain multiple contacts, configure default payment terms, and manage parent-child relationships in Dynamics 365.The “Inventory & Distribution Challenge”: Setting up an item master record, configuring SKUs, assigning item types, tracking expiration dates, and linking items to warehouses.
  • Completing these quests can “level up” the user’s knowledge and skill, adding a bit of gamification to the learning process.

4. Fantasy-Themed Data and Scenarios

  • Use fantasy-inspired data, such as selling “enchanted swords” or “mystic potions,” where each item has a unique set of characteristics, financial values, or expiration dates that need careful tracking and management.
  • You could also create a fictional economy with vendors like Baldur’s Gate Blacksmiths Guild for procurement or Lara’s Fine Fabrics and More for specialty textile items.

5. Guilds and Teams for Collaboration

  • Teams within the Dynamics 365 environment can be seen as guilds, each with a unique focus area (e.g., finance, supply chain, human resources).
  • A guild could be tasked with solving specific challenges that arise, such as managing a large influx of orders or handling complex customer hierarchies, simulating real-world business problems.

6. Encounters with System “Monsters”

  • Just as adventurers face monsters, users might encounter “monsters” in the form of system errors, process bottlenecks, or tricky configurations.
  • These “monsters” could be defeated with specific skills or tools, such as leveraging Power BI for data visibility, configuring Power Automate workflows, or setting up credit limits to manage customer debt in Finance and Operations.

7. Magic Items & Tools for ERP Users

  • Just as D&D characters have magical items, users can be equipped with “magic items” (custom solutions or add-ons) that enhance their capabilities in Dynamics 365.
  • For example, a “Wand of Reconciliation” could be a custom reconciliation tool, or the “Scroll of Analytics” could represent Power BI insights.

8. Spellcasting for Automation

  • Spellcasting could represent various levels of automation in Dynamics 365. Simple spells might be quick automations in Power Automate, while high-level spells could be complex workflows and integrations with Power Platform.
  • A “casting” could represent running a script or a bot in Power Automate that automates tasks like data validation or customer follow-ups.

By using a storytelling approach, Advanced Dungeons & Dynamics 365 can make complex ERP concepts relatable, help trainees engage with the system, and build connections that are memorable, enjoyable, and practical. And just like in D&D, it builds a strong sense of collaboration, problem-solving, and role-playing that elevates the learning experience.

To start your journey visit: https://adnd365.com/start