Arunjyoti Dey · Enterprise & solution architect · Melbourne
Over many years and many programs, as a developer, then a lead, and now a lead architect, I've worked on ERP, CRM, integration and Single View of Customer transformations. These are my field notes on making them connect, and on using AI-driven delivery to get there faster with less risk.
01 · What I transform
I've worked on each of these across different programs and organisations over the years. The lesson that keeps repeating is that they depend on each other, even when they're run as separate projects with separate teams. 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 account, order, product, pricing and billing, 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 · About
I'm Arunjyoti Dey, an enterprise and solution architect based in Melbourne. Most people call me Arun.
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.
I've spent many years on ERP, CRM, integration and customer data transformations across several organisations: first as a developer, then as a technical lead, and now as a lead architect. My background covers data, applications, master data, analytics and integration. The lesson that keeps repeating is that these transformations succeed or fail together. This site is where I share what I've learned along the way.
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 · Writing
Practical lessons from transformation work, anonymised and written for the people running these programs: CIOs, program directors and architects.
A design people helped shape is a design they'll defend. How I bring business, architects and engineers to one answer.
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.
A golden record isn't the goal. Rewarding loyal customers and reaching them at the right moment is. Here's how to work back from that.
Field notes · Customer
Most single view of customer programs start with the data and hope the value turns up later. I'd rather start from the outcomes the business actually wants, such as rewarding loyal customers and reaching them at the right moment, and work backwards to what has to be built.
A single view of customer program usually begins with master data management. Pick a platform, define the customer model, match and merge duplicates, and produce a golden record. All of that is necessary. The trouble is that many programs stop there and declare success.
A golden record isn't an outcome. Nobody in the business wakes up wanting one. They want to keep good customers, sell to them at the right time and stop wasting money on the wrong ones. If the program doesn't start from those goals, it ends with clean data and no one using it.
Two outcomes come up again and again, and both are easy for a business to recognise.
The same pattern travels well beyond cars. In retail there are short cycles, like a business that reorders a ream of paper every few weeks, and long ones, like a customer who replaces their phone every two or three years. Get the timing right and marketing feels like service rather than noise.
Once the outcomes are clear, the build order falls out of them.
So the program is built in the opposite order to the way it's justified: identity, then history, then value, then timing.
This is the part most people mean by single view of customer. A master data hub sits in the middle, holding the golden record, with the CRM, ERP, eCommerce, point of sale, marketing and service systems around it as spokes. Each system keeps doing its job, and the hub keeps one trusted version of who the customer is.
One distinction matters here. The single view gives you identity, not history. It tells you this customer is one person with one set of details. On its own, it doesn't tell you what they've done.
History comes from a data analytics layer on top of the single view. Its first job is to find the close matches the operational systems can't: the same person with a different email in one channel, or a slightly different address in another. Its second job is to bring transactions from every channel together into one timeline per customer.
This is where most of the business value starts to show, and where most of the hard work sits.
With a history in place, you can start rating customers and their transactions: how long they've been with you, how often they buy, what they buy, and whether they come back for service. The scoring model should be agreed with the business, because "valuable" means different things to marketing, sales and service. Done well, it gives everyone one shared view of which customers matter most.
The last step looks for cycles in each customer's history and flags who is coming due. That signal feeds marketing and sales, so the right customer hears from you at the right time, with an offer that fits where they are in the cycle.
In a previous role in automotive, I delivered a single customer view across a group of brands. The vision went further: lifetime value and purchase cycles, built on top of it. I left before that part was built, and the reason is worth sharing. Not all of the channels had been onboarded to the single view, and the organisation was slow to adopt the change. Without enough channels feeding it, there was no complete history, and without history the value and timing steps couldn't start.
The value of a single view only shows up once enough channels feed into it.
If I did it again, I'd plan channel onboarding as part of the program from day one, not as follow-on work. And I'd tie each channel to the outcome it unlocks, so the business can see why it's worth the effort.
Funding a golden record is hard to justify, because nobody can see what it buys. Funding better retention of loyal customers and better-timed marketing is much easier, because the business can picture the result. Starting from the outcome also gives you the right measures from day one: repeat purchase, retention and response to campaigns, rather than the number of records matched.
Field notes · Leadership
An architect can hand down a design, but a design people helped shape is the one they defend when it gets hard. That's why I build solutions by consensus with business people, peer architects and the engineers on the ground, and why I treat it as part of the architecture work, not a soft skill on the side.
A directive design looks efficient. One person decides, writes it down and circulates it. The trouble shows up later. The business didn't see its real constraint reflected, so it works around the design. The engineers spot a detail the diagram missed, so they quietly build something slightly different. Peer architects weren't asked, so the next decision in their area pulls the other way.
None of that appears in the design review. It appears months later as rework, exceptions and a solution nobody feels they own.
A solution built by consensus is a solution people accept. That acceptance is what carries it through delivery.
I work with three groups, and I want all three in the room before the design settles.
I gather what each group knows, put the options on the table and work towards an answer everyone can stand behind.
If I had to name one skill that has made the biggest difference over my career, it's listening. I like hearing different points of view, especially the ones that disagree with mine. When I sit down with someone and properly hear them out, one of two things happens: either I learn something, or they do. Both are useful.
That only works if the disagreement is genuine. I'd rather surface an objection in a workshop than discover it in a defect log, so I go looking for the people most likely to push back.
Consensus built on slides is fragile. The other half of my approach is to go and touch and feel the system: sit with the developers, look at the actual integration flows and data, and understand how things really work today. Until you get into the detail, you don't understand the complexity that lies underneath, and you can't tell a real constraint from a preference.
It also earns trust. People are far more willing to agree to a design when they've seen the architect understand their part of it.
Take a problem every retailer meets sooner or later. A customer is at checkout with a valid coupon, or a promotion that should apply to their basket, and the promotion engine doesn't respond. Each group in the room has a fair point. Marketing wants the promise honoured, because a customer who was told about a discount expects to get it. Finance wants every discount to be accurate and traceable. Store and digital teams want the checkout to keep moving, because a queue or an abandoned cart costs more than the discount.
A directive answer picks one of those and ignores the rest: block the sale until the engine is back, or let the checkout guess at the discount. Working through it together, we landed on a middle ground. The sale goes through, and the coupon or promotion the customer was entitled to is recorded against the order. Once the engine is back, an automated check works out the correct discount, and the difference is refunded or credited to the customer, with a message that explains it.
Nobody got exactly what they started with. The customer still gets their discount, finance gets an accurate and auditable adjustment, and the checkout never stops. Everyone could see their concern respected in the answer, and that's what made it agreeable.
Consensus isn't the same as unanimity, and it isn't a licence to wait forever. Sometimes the options are clear, the trade-offs are understood and people still don't agree. At that point someone has to make the call, explain why, and own it. Doing the consensus work first is what makes that call land: people may not love the decision, but they know they were heard and they understand the reasoning.
An agreement that lives only in a meeting fades fast. Once we've landed on an answer, I capture it through normal architecture practice: the decision, the options we considered, the constraints that shaped it and who agreed. That record is what stops the same debate restarting six months later with a new set of people.
Consensus can look slower at the start. It's faster over the life of a program. Designs that people helped shape get adopted rather than worked around, surprises surface in design rather than in testing, and fewer decisions get reopened through escalation. Done well, it's like an orchestra: many parts, each playing its own line, all in harmony.
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.
In practice, a Salesforce to S/4HANA integration has two halves, and they need different thinking.
Get the customer half right first. S/4HANA can't create a sales order for a customer it doesn't recognise, so in my experience many order failures in testing trace back to the customer half rather than the order half.
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 call the pricing engine directly. Each has its own credentials, its own retry logic and its own idea of what a price includes. Now replace the pricing engine. That's three projects, three test cycles and three chances to get it wrong.
Multiply that across accounts, orders, products, pricing and billing, 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 account, order, product, pricing and billing.
Model what consumers need, not everything the provider offers. A canonical product model doesn't need every attribute every backend holds. It needs what your consumers use, expressed so that adding a source system is a mapping exercise, not a redesign.
Separate provider responsibilities from service responsibilities. On a billing service, it's easy to blur the line between the two. Tax and invoice rules belong to the billing engine behind the service; retries, error mapping and consumer access belong 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. An ERP rejecting a whole order over one missing account 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.