ERP platforms remain critical systems of record, but they are no longer the full boundary of an enterprise solution.
Modern implementations distribute business capability across transactional applications, integration services, data platforms, automation, identity, analytics and increasingly AI agents. The architecture challenge is therefore not only how to configure the ERP. It is how to design the system around it.
ERP is a component, not the architecture
A Dynamics 365 Finance or Supply Chain Management implementation can own core transactional processes such as general ledger, procurement, inventory, production, warehouse management and order processing. Those capabilities matter because they establish authoritative business state.
But the wider solution usually includes more than the ERP application itself. Customer experiences may sit elsewhere. Data may be replicated into analytical platforms. Integration services mediate external systems. Power Platform may support workflow and edge applications. AI services may reason over enterprise knowledge or invoke approved tools.
Treating all of that as "the ERP implementation" hides the design decisions that determine whether the overall solution is secure, supportable and maintainable.
The boundary matters
The most important architecture question is often not which product can technically perform a function. It is where that function should live.
A useful boundary decision considers:
- system of record and data ownership
- transaction consistency requirements
- security and segregation of duties
- integration latency and failure handling
- operational ownership
- licensing and platform cost
- extensibility and upgrade impact
- reporting and analytical requirements
- auditability and observability
These decisions prevent a common failure mode: solving every requirement in the platform that happens to be most familiar to the implementation team.
Beyond ERP is an architecture viewpoint
Beyond ERP is not an argument against ERP platforms. It is the opposite. A strong ERP core becomes more valuable when its responsibilities are explicit and the surrounding architecture is intentional.
For Dynamics 365 programmes, this means distinguishing several classes of solution decision:
- Standard functionality should remain the first choice when it satisfies the business requirement without distorting the process.
- Configuration should adapt standard capabilities within supported product boundaries.
- Extension should address genuine requirements while preserving upgradeability and architectural ownership.
- External platform capability should be used when the requirement belongs outside the ERP boundary, for example integration orchestration, enterprise data products or specialised AI services.
- ISV solutions should be selected when buying a maintained capability is preferable to building and owning it.
The important point is not that one category is always better. The architecture must make the trade-off explicit.
AI makes the boundary more important
AI agents increase the importance of these decisions because they can cross application boundaries quickly.
An agent may read policy from one source, retrieve transactional context from another, call an enterprise API and request an action in Dynamics 365. That is powerful, but it also creates new trust boundaries.
The agent should not automatically inherit broad application access simply because the model can reason about a business process. Tool permissions, user identity, approval points, audit records and transaction controls still need explicit design.
This is one reason Model Context Protocol is interesting for enterprise applications. MCP can provide a standard way to expose tools and context to agents, but the protocol does not replace enterprise security, integration architecture or process controls. Those remain architecture responsibilities.
Architecture should expose consequences
A useful architecture description should do more than show boxes and arrows. It should explain the consequences of the design.
For example, if an order-status experience reads directly from Dynamics 365, the architecture should explain the expected workload, authentication model and availability dependency. If the experience reads from a replicated data store instead, the architecture should explain data latency, ownership and reconciliation.
Both diagrams may look reasonable. Their operational characteristics are different.
The same principle applies to AI. A diagram showing an agent connected to Dynamics 365 is incomplete unless it explains what the agent can do, under whose identity, through which interfaces, with what approval model and how actions are audited.
What Beyond ERP will focus on
The purpose of Beyond ERP is to examine these wider decisions through practical architecture work.
The main areas are:
- Dynamics 365 Finance and Supply Chain Management architecture
- Azure and enterprise integration
- Power Platform and Dataverse boundaries
- enterprise data and reporting
- security and identity
- Azure AI Foundry, Azure OpenAI and Copilot Studio
- AI agents and agentic architecture
- Model Context Protocol
- architecture governance and implementation practice
The aim is not to collect product features. It is to connect product capability to business responsibility, technical ownership and implementation consequence.
The working principle
ERP should remain authoritative where it needs to be authoritative, while the surrounding enterprise architecture should be designed deliberately rather than accumulating around it.
That is what Beyond ERP means.
Continue reading