Arunjyoti Dey · Enterprise & solution architect · Melbourne
I design ERP, CRM, integration and Single View of Customer transformations as one connected landscape, and I use AI-driven delivery to get there faster with less risk. These are my field notes.
01 · What I transform
Most programs run these as separate projects with separate teams, yet they depend on each other. The ERP sets the core, CRM shapes how you engage, integration connects them, and a single view of the customer is the payoff.
Moving off legacy ECC to SAP S/4HANA and RISE with a clean core, so the business can keep upgrading without starting over.
From the fieldOrder fulfilment, pricing and product data designed so the ERP stays the system of record, not the system everyone works around.
Salesforce sales, service and order management, built around how teams actually work and designed for adoption from the start.
From the fieldOrder orchestration across web, store, B2B and bulk channels, with the CRM orchestrating and the ERP fulfilling.
Replacing point-to-point connections with reusable API- and event-led services, and a data layer the business can trust.
From the fieldShared enterprise services for carriers, messaging, product and pricing, each with one owner and one contract.
Bringing customer data from every channel into one view that marketing, sales, service and stores actually use.
From the fieldCustomer lookup and account data served once, as a service, instead of copied into every channel.
02 · How I deliver
I use AI across the whole delivery lifecycle, from requirements to run, in the day-to-day work of designing and building integrations on live programs.
Turn workshop transcripts, documents and process maps into structured, system-attributed requirements.
Draft designs, mappings and decision records early, then check every claim against the real API specs.
AI agents build and review integration flows from the design, working to the organisation's own standards.
Test cases and data generated from requirements, so coverage keeps up with change.
Design pages versioned with the code, so knowledge stays after the project team leaves.
The guardrails
The architect's edited version is the source of truth, not the AI's first draft.
Security and integration standards sit in a rules file every agent reads, every time.
AI works under the same data rules as the human team. Nothing sensitive crosses a line it shouldn't.
AI can build and push to development. A person verifies and promotes.
03 · Writing
Practical lessons from transformation work, anonymised and written for the people running these programs: CIOs, program directors and architects.
It isn't one interface. It's a set of decisions about ownership, direction, mapping and failure. Here's the order I make them in.
Why I put reusable, owned business services on the middleware instead of building another point-to-point interface.
The toolchain, inputs, workflow and controls I use to have AI agents build and review integration flows.
When a cloud service on the checkout path goes down, you don't have to choose between lost sales and expensive failover.
What happened when I put AI agents to work on real integration builds. The speed-up was real; the hard parts weren't the AI.
The most expensive defects on an order orchestration program started as sentences that didn't name a system.
Every customisation you keep is a cost you pay at every upgrade. How to have that conversation with the business.
Why the customer view usually arrives last, and how to design ERP and CRM programs so it arrives at all.
04 · Ask
Send me the question you're wrestling with on ERP, CRM, integration, customer data or AI in delivery. I answer the most useful ones here, anonymised, so others can learn from them too.
Start by asking which system owns the outcome. If the receiving side has a standard API that reports status, the cleanest answer is often for the owning system to poll it on a schedule and act on what it finds. That keeps the recovery logic with the team that understands the business consequence.
What I try to avoid is adding a new component into the live transaction path just to handle failures, or copying existing integration flows to build a recovery variant. Both work on day one. Both become something you maintain forever, and the copy drifts from the original the first time either changes.
Rule of thumb: the happy path and the recovery path should have the same owner, and recovery should reuse standard interfaces wherever they exist.
Separate the people who build integrations from the people who grant access. A platform team should own identities, access control profiles and queue ownership. Integration developers and direct consumers request access; they don't mint it.
Then keep the patterns few and boring: one identity per domain or application, per environment, named the same way as your topics so anyone can read it. OAuth client credentials in production, certificates as a fallback, basic authentication only in development. And make consumers read from queues they own rather than subscribing to topics directly, so you always know who receives what.
Rule of thumb: if you can't answer "who can read this event?" from your naming alone, the standard isn't finished.
05 · About
I'm Arunjyoti Dey, an enterprise and solution architect based in Melbourne. Arun is fine.
I'm currently a lead architect on the ERP (SAP S/4HANA, RISE) and CRM (Salesforce) transformations at a major Australian retailer, where I lead a small team of integration architects. My domain spans supply chain, B2B, product and pricing, marketing technology, digital channels, and store and point-of-sale systems.
My background covers data, applications, master data, analytics and integration. The lesson that keeps repeating is that ERP, CRM, integration and customer data transformations succeed or fail together. This site is where I share what I've learned along the way.
Pattern · ERP + CRM
Integrating Salesforce and S/4HANA isn't one interface. It's a set of decisions about who owns each object, which way data flows, how the two data models line up and what happens when either side is unavailable. This is the order I make those decisions in.
The most common mistake I see is starting with a list of interfaces. Start with a list of business objects instead, and give each one exactly one system of record: customer and account, product, price, order, fulfilment and delivery, invoice and payment.
A common split is that the CRM owns engagement, order capture and orchestration, while the ERP owns product master, the pricing engine, fulfilment and finance. Your split may differ. What matters is that it's written down and that nobody can point to an object with two owners.
Every object gets one owner. Everything else holds a copy, and knows it's a copy.
Once ownership is clear, most interfaces design themselves: data flows out from the owner to whoever needs a copy, and changes flow back to the owner as requests, not updates.
Different flows need different patterns. All of them go through the same governed middle layer.
Everything goes through the integration layer, even when a direct connector exists. The connector saves a week at the start and costs you visibility, reuse and a single place to enforce security for the life of the platform.
SAP thinks in documents: header, items, schedule lines. Salesforce order management thinks in orders, order items and delivery groups. Mapping one to the other is where most build effort goes, and where a few lessons repeat.
Every flow needs an answer to "what if the other side said no, or didn't answer?"
On go-live, the CRM may be ready long before the ERP is accepting orders. Build a control so the CRM pushes only when the ERP is ready, and release the backlog in small batches rather than all at once. A controlled trickle lets you spot a mapping problem on the first handful of orders, not the first few thousand.
A Salesforce to S/4HANA integration lives for a decade. Clear ownership reduces rework during the build; a governed middle layer reduces the cost of every change after it; and designed failure paths are what stop an outage turning into a week of manual reconciliation.
Pattern · Integration
Point-to-point integration ties every consumer to every backend's quirks, so changing a provider means changing everyone. An enterprise service puts one owned, reusable contract on the integration middleware in front of a business capability, so consumers integrate once and backends can change behind it.
Picture a retailer where the website, the store systems and the CRM each talk directly to an SMS provider. Each has its own credentials, its own retry logic and its own idea of what an opt-out means. Now change provider. That's three projects, three test cycles and three chances to get it wrong.
Multiply that across carriers, product data, pricing and delivery options, and you have a landscape where every change is expensive and nobody can say who depends on what.
An enterprise service is a business capability exposed through the integration middleware with four properties:
Swapping or adding a provider happens behind the contract. Consumers don't change.
The kinds of capability that suit this are the ones many systems need and few systems should own the details of: customer messaging, carrier booking and tracking, product data, pricing, delivery options and customer account lookup.
Model what consumers need, not everything the provider offers. A canonical carrier model doesn't need every field every carrier supports. It needs what your consumers use, expressed so that adding a carrier is a mapping exercise, not a redesign.
Separate provider responsibilities from service responsibilities. On a messaging service, opt-outs and inbound replies are easy to conflate. Some of that the provider handles; some belongs in the service layer. Write down which is which before anyone builds.
Validate every claim against the provider's spec. Before circulating a service design, I do a revalidation pass of every statement against the provider's actual API documentation. It has caught substantive errors more than once.
Validate early, at every entry point. Some providers reject a whole request for one bad field. A carrier rejecting an entire consignment over one address detail is the classic case. Validate where data is entered, and keep a safety net downstream.
Standardise the boring parts. Security identities per domain, shared error handling and central alerting are set once for all services, not reinvented by each one.
One service, one repository, one design page. The design page is versioned with the code, so the documentation describes what's actually running.
An enterprise service isn't free. It adds a hop. Replacing a slow legacy endpoint with a service is usually low-risk. Replacing a consumer's own fast local backend is not: if a channel answers a price in tens of milliseconds today, a central service has to be performance-tested against that before anyone commits, and the consumer may need its own optimisation.
The data platform has a role too, but for scheduled consumption and analytics, not as a real-time backend for customer-facing journeys.
Enterprise services turn integration from a cost you pay per consumer into an asset you build once. They lower the cost of switching providers, which strengthens your hand in commercial negotiations. They shorten onboarding for new channels. And they give you one place to answer the questions auditors and security teams always ask: who calls what, with which identity, and what happens when it fails.
How-to · AI delivery
This is the practical companion to my lessons piece on AI in delivery: the toolchain, the inputs, the workflow and the controls I use to have AI agents build and review integration flows on SAP Integration Suite. None of it depends on a particular model; all of it depends on discipline.
Keep it to one front end. Developers work in VS Code, with the AI coding agent, Git and the platform tooling all in the same place. Each interface or enterprise service gets its own Git repository. Design pages live in the team wiki, one per interface, and each version of a design page is paired with the version of the integration flow it describes.
One rule up front: check whether a repository already exists before creating one. It sounds trivial. It's the first thing that goes wrong when several people start at once.
Every piece of work starts as exactly one of these:
Naming the kind of work tells the agent, and the reviewer, what "done" looks like.
The agent is only as good as what it's given. For new development that means:
Most "AI got it wrong" moments were really "the design didn't say".
Two human gates: the architect approves the breakdown, and a person verifies and deploys.
Think of it as the standards a senior reviewer would otherwise apply by memory: security and authentication patterns, naming, error handling and dead-letter routing, logging rules (what must never be logged), central alerting conventions and preferred adapters. Write it once for the organisation, and every agent and every developer gets the same reviewer.
The same setup works in reverse. Point the agent at an existing flow with the rules file, and it reports where the flow breaks the standard and proposes fixes. Retrofitting existing interfaces to a standard is work that almost never gets prioritised by hand. With an agent, it becomes routine, and it's the safest place for a team to learn the approach.
Deployment. Automated deployment from the agent didn't work in my first iteration, and I'm in no hurry. A person verifying before deploying is a cheap control, and nothing about the speed-up depends on removing it.
The same shape carries over to CRM development: agents with explicit human checkpoints, read-only access where they need to inspect a real environment, and security scanning built into the developer's tools from the first line rather than bolted on at the end. Most real features cross CRM, ERP and integration anyway, so the approach should too.
The value isn't that an agent writes integration code. It's that design intent survives from the meeting room to the running interface, standards are applied every time instead of when someone remembers, and the documentation is always current. That's lower rework, lower operational risk and less dependence on any one person's memory.
Case study · Resilience
When a cloud service on the checkout path goes down, the usual answers are to accept the lost sales or build expensive multi-region failover. On one program we chose a third option: take the order now, confirm the detail later, and design the recovery as carefully as the happy path.
Every retailer has a service that tells the customer when their order will arrive or be ready to collect. On this program that delivery-promise service ran on a cloud platform, and every channel called it before the customer could pay.
That made it a single point of failure at the most expensive moment in the journey: just before money changes hands. The platform's planned maintenance and its rare unplanned incidents both landed in the same place. Customers could browse and fill a basket, then hit a wall.
I was asked to find a high-availability or disaster recovery answer. The brief sounded technical. The answer turned out to be mostly a business design.
The first two options treat it as an infrastructure problem. The fourth treats it as a customer problem, which is what it actually is.
The happy path is unchanged. The new work is the hold state and what happens after it.
When the promise service is unavailable, channels accept the order without a confirmed date and send it to order management in its own hold state. Once the service is back, the held orders are confirmed and released, and customers get a message written for exactly that situation. If, in the worst case, an order can't be honoured, we contact the customer, cancel cleanly and reverse the payment.
A sale that's slow to confirm is a much smaller problem than a sale you never made.
For executives, that's the trade in one line. The risk moves from infrastructure few people understand to a customer process everyone does: communication and, occasionally, a refund. And it costs a fraction of building and testing failover.
A distinct status, not a reused one. It was tempting to park these orders as drafts. But a draft means "the customer hasn't finished", and that's not true here. A first-class hold state means fulfilment can't accidentally pick it up, and operations and reporting can see exactly what's waiting.
Know who you affected from minute one. The list of impacted customers is captured as the outage happens, not reconstructed afterwards. Remediation becomes a task, not a forensic exercise.
Different dependencies deserve different answers. For the integration platform itself, the answer is the opposite: a clean fail. No order accepted, no payment authorised. If you can't reliably record an order, holding it is worse than refusing it. Anyone who has reconciled orders and payments after an integration incident knows that's work you want to design away.
One page per dependency. Each critical dependency gets a one-page outage design in the same template: what the customer sees, what we capture, how we recover, who owns it. That format is what got this approved quickly.
Field notes · AI delivery
I ran a proof of concept using AI agents to review, fix and build integration flows on SAP Integration Suite, then started moving a small group of developers onto the approach. The speed-up was real, but it came from places I didn't expect, and the hard parts weren't the AI.
Integration delivery on a large ERP program usually runs as a relay. An architect writes the high-level design. Someone turns it into a detailed design. A developer builds from that. Each handoff loses context, and most rework traces back to something that was clear in a design meeting and gone by the time it reached the build.
So the question wasn't "can AI write code?" It was "can AI shorten the relay without dropping the baton?"
Deployment. Automated deployment from the agent didn't work in the first iteration. So we kept it simple: the agent pushes to development, a person verifies, a person deploys. Automating that is a later step, and nothing about the value depends on it.
Consistency across repositories. Once I was working across several interfaces, each one started to drift: slightly different error handling, naming, logging. The fix wasn't a better prompt. It was a shared knowledge base, plus the organisation's security and integration standards in a single rules file that every agent reads on every build.
Handoffs. This was the big one. If an architect produces a finished build with AI, then hands it to a developer who wasn't in the design conversation, you've rebuilt the relay. The developer has the code but not the why. The real gain came from letting the people who hold the design context carry it through to a tested build in development.
AI didn't remove the handoff problem. It made it impossible to ignore.
None of this works inside an enterprise without rules that hold whether a person or an agent is doing the work.
I didn't switch the whole team over. We started with a handful of developers, with change support for their day-to-day ways of working, and a single team guide covering process, documentation structure and onboarding. Every piece of work starts as one of three things: new development, a fix, or documenting an existing interface.
The message I give leadership is deliberately modest. This is a step-by-step learning process, not full automation. The agent sometimes gets things wrong. That's exactly why the knowledge base and the human review points exist, and why they matter more than the model.
Build time shrinks, but that was never where most of the cost was. The bigger saving is in rework and handoffs, and you only get it if you change the operating model, not just the tooling. If you buy licences and keep the relay, expect a modest gain. Redesign who carries the design through to the build, and the gain compounds.
Field notes · ERP + CRM
On an order orchestration program spanning a CRM and an ERP, the most expensive defects started as sentences in requirements documents that didn't say which system owned the behaviour. Two disciplines fixed most of it: attribute every requirement to exactly one system, and keep one tiebreaker document for order state.
The target design was a familiar one: the CRM orchestrates the order, the ERP fulfils it, and an integration layer sits between them. Orders came from several channels and covered several types of product, each with its own path through the two systems.
Two platform teams, two backlogs, and one set of requirements written by people who, quite reasonably, thought about the business process rather than the systems.
Take a harmless-looking requirement: "The customer is notified when the order ships." Which system detects that the order shipped? Which one sends the notification? Which one stores that it was sent?
When a requirement doesn't say, one of two things happens. Both teams build it and the customer gets two messages. Or each team assumes the other has it and the customer gets none. Either way, you find out in integration testing, which is the most expensive moment to discover a design gap.
Ambiguous ownership doesn't show up in design reviews. It shows up in test, with a deadline attached.
Every requirement names exactly one system and states only what that system must do. If two systems are involved, it becomes two requirements, plus an interface between them.
That sounds bureaucratic. In practice it made requirements shorter. A CRM requirement no longer describes what the ERP does, and an ERP requirement no longer smuggles in CRM obligations. Each team reads its own list and knows that's the whole job.
The supporting artefact is a requirements traceability matrix per system, not one giant matrix with a "system" column that everyone filters differently.
Large programs accumulate logic sheets: one per channel, one per product type, one from each workshop. Sooner or later two of them disagree.
We kept a single authoritative order-state model. Every state an order can be in, which system owns each transition, and what triggers it. When documents conflicted, the state model won, and any change to behaviour went through it first. It turned arguments about wording into a question with one place to look up the answer.
Later, we had to decide how to recover orders that failed to transfer between two order management systems. Options included adding a separate orchestration component, or copying existing integration flows to build a recovery variant. We chose to have the owning system poll the other's standard API on a schedule.
Same principle: the system that owns the outcome owns the recovery, and nothing new goes into the live transaction path unless it has to. Copied flows and extra components look cheap on day one and cost you on every change after that.
None of this is clever. It's a writing discipline. But it moves the discovery of design gaps from test back into design, where fixing them costs a conversation rather than a sprint. On a program with fixed cutover dates, that's the difference between a controlled plan and a late scramble.