What Role Do Your Systems Play?

Most organisations can produce a list of their systems. CRM, website, finance, marketing, service desk, document management, analytics, integration, collaboration, HR and, increasingly, a growing collection of AI tools. Ask what each one does, and you will might get a reasonable answer too.

But there is a slightly different question that organisations don’t ask nearly as often: what role does each system play for them?

Where does the authoritative customer record live? Which system owns identity? Where should customers engage? What system is allowed to make a decision or perform an action? Where does organisational knowledge live? How does information move between all of these places?

And perhaps most importantly, what happens when two or more systems believe they have the same job?

If you haven’t considered your technology estate this way before, maybe you should.

Start With the Systems You Already Have

Don’t start by redesigning your architecture or choosing new technology. Start by cataloguing what you already have.

List the systems your organisation currently uses, and don’t limit this to the large enterprise platforms. Include websites, SaaS products, databases, integration tools, reporting platforms, communication platforms, document repositories, collaboration tools and AI. That spreadsheet somebody relies on to run an important business process probably deserves to be there too.

Then, rather than simply documenting what each product is or what vendor provides it, consider the roles it plays within your organisation.

A single system can have several roles, and that’s completely normal. Salesforce might be a System of Record, a System of Automation and a System of Engagement. A website may provide Engagement, Experience and Communication. Microsoft Teams could provide Collaboration, Communication and Knowledge.

The objective isn’t to put every product neatly into one box. It is to make the responsibilities you have given those products visible.

A Catalogue of System Roles

There isn’t necessarily one universal taxonomy for this, and organisations will have roles specific to their environment. But the following provides a useful catalogue to start the exercise.

System of Record

A System of Record is the authoritative home of information. It is the system that has the greatest right to a particular record or piece of data.

It is common to hear organisations refer to the System of Record, but in practice there will often be several, each authoritative for a different type of information. Your CRM might be the System of Customer Record, your finance platform the System of Financial Record, your HR platform the System of Employee Record, and another system the authoritative source for products, services, assets or transactions.

The distinction can become more nuanced again. A CRM might own the customer relationship and core customer identity, while a finance system has greater authority over that customer’s billing details and transaction history. A marketing platform might hold a copy of their email address and preferences, but neither necessarily belongs there as the authoritative record. Thinking in terms of Systems of X Record helps identify these boundaries rather than trying to nominate one platform as the source of truth for everything.

Other systems will almost certainly hold copies of the same information, and that isn’t inherently a problem. The important question is what happens when those copies disagree. For each important information domain, you should be able to answer: which system has the greatest right to say what is true?

System of Engagement / Experience

A System of Engagement / Experience manages where and how people interact with the organisation. This can include websites, portals, apps and service platforms, but also communication channels such as email, SMS, messaging and push notifications. Engagement might be initiated by the person or by the organisation; what defines the role is that it sits at the point where the organisation and its audiences interact.

These systems shape what someone sees, receives and can do, but they don’t necessarily own the underlying information. A website might allow a customer to update their details, while a marketing platform sends communications based on their interests. In both cases, the CRM might remain the System of Record for the customer, their preferences and their consent.

There may legitimately be several Systems of Engagement / Experience serving different audiences, purposes and channels. Mapping them as a role helps establish which systems are authorised to engage with whom, through which channels, and using information owned by which other systems.

Examples: WordPress, Salesforce Experience Cloud, Salesforce Marketing Cloud.

System of Identity / Authority

A System of Identity / Authority establishes who someone or something is and which representation of that identity should be trusted. This can include authentication and access, but also customer identity, account matching and the relationships between different representations of the same person or organisation.

An organisation may have many identifiers for one person across CRM, website, marketing, service and transactional systems. Those systems may all know something about that person without having equal authority over their identity. A System of Identity / Authority establishes which identity should be trusted, how other identities relate to it and, where relevant, what that identity is authorised to access or do.

This becomes particularly important as systems become more connected. Knowing that two records probably represent the same person is different from having the authority to declare that they do.

Examples: Microsoft Entra ID, Salesforce Identity, Okta.

System of Integration / Ingestion

A System of Integration / Ingestion is responsible for bringing information into the organisation’s technology ecosystem and moving it between systems. It can receive, move, transform, synchronise and route information so that individual systems don’t all need bespoke knowledge of one another.

Integration generally describes information moving between known systems, while ingestion broadens the role to include information arriving from external sources, files, feeds, APIs, events or other inputs. In both cases, the role is primarily about getting information from where it is to where it needs to be.

Its responsibility should usually remain different from owning or interpreting the information it transports. Integration and ingestion systems have a habit of accumulating business logic over time. Eventually something that was intended to move information starts deciding what that information means, which can blur the responsibilities between Integration / Ingestion, Record and Automation / Action.

Examples: MuleSoft, Salesforce Data Cloud, Workato.

System of Automation / Action

A System of Automation / Action is responsible for making things happen. It responds to events, applies rules or decisions and executes the process that should follow, whether that means creating a record, assigning a task, updating a status, sending a notification or coordinating work across several systems.

The decision and the action don’t necessarily need to happen in the same place. One system might determine what should happen while another executes it, particularly as predictive models and AI become more involved in organisational processes. For the purpose of mapping system roles, however, they are part of the same broader responsibility: turning information, events and decisions into action.

There may legitimately be several Systems of Automation / Action, but where multiple systems can initiate or control the same process, it is worth establishing which has the greatest right to do so. Knowing which system is authorised to make something happen can be just as important as knowing which system owns the underlying data.

Automation may exist inside your CRM, marketing platform, integration layer or dedicated workflow technology. The important thing is knowing which system has responsibility for making a particular process happen.

Examples: Salesforce Flow, Salesforce Agentforce, Workato.

System of Collaboration

A System of Collaboration is where people work together. Teams, Slack, project workspaces and other collaborative environments are obvious examples.

These platforms frequently overlap with Communication and Knowledge. A decision discussed in Teams can quickly become organisational knowledge, even though Teams may not be where that knowledge should ultimately live. Identifying the roles helps expose those blurred boundaries.

Examples: Slack, Microsoft Teams, Jira.

System of Knowledge / Content

A System of Knowledge / Content is where an organisation creates, manages and maintains the information it wants people and systems to use. This might include website content, policies, procedures, guidance, documentation, project history, research, articles, resources and other reusable organisational knowledge.

There may be several Systems of Knowledge / Content serving different purposes. A CMS might be authoritative for published website content, a document management platform for controlled policies and procedures, and another knowledge base for internal guidance. As with Systems of Record, the important question is not necessarily whether there should be only one, but whether it is clear which system has authority over which type of knowledge or content.

This role is becoming particularly important with AI. Giving an AI assistant access to ten repositories doesn’t solve the knowledge problem; it can expose it. If several systems contain different versions of the same policy, guidance or content, the AI still needs to know which one is current, authoritative and appropriate to use. Understanding your Systems of Knowledge / Content therefore becomes part of establishing what both people and machines should trust.

Examples: WordPress, Salesforce Knowledge, Confluence.

System of Insight / Intelligence

A System of Insight / Intelligence helps turn information into understanding. This can range from reporting, analytics and dashboards that explain what has happened, through to systems that identify patterns, make predictions, summarise information, discover relationships and recommend what might happen next.

These systems often bring together information from multiple sources without becoming the authority for the underlying records. Their role is to interpret information and make it useful, rather than necessarily own it.

AI is rapidly expanding what this role can do, but intelligence doesn’t need to mean AI. Traditional reporting, behavioural analytics, forecasting, predictive models and AI can all play different parts in helping an organisation move from having information to understanding and acting on it.

Examples: Tableau, Salesforce CRM Analytics, Agentforce.

Now Look for the Overlaps

Once you have your systems and roles, create a simple matrix. Put your systems down one side and the roles across the top, then mark every role that each system currently performs. Don’t worry if individual systems end up with lots of marks. Systems performing multiple roles isn’t the problem.

What you are looking for is the pattern in the other direction: multiple systems performing the same role.

Perhaps three systems maintain customer contact details. Two systems trigger customer communications. Four places contain organisational knowledge. The CRM and finance platform both maintain an organisation name. The website, CRM and marketing platform can all update communication preferences.

None of these examples automatically means the architecture is wrong. They simply identify places where another question needs to be asked: which system has the greatest right to perform that role?

Give Your Systems Rights

When multiple systems perform the same role, the answer isn’t necessarily to eliminate all but one. Information and capabilities genuinely need to exist in multiple places in modern architectures.

Instead, establish their rights.

One system might own the information while another can create it. Several systems might consume it. Another might be permitted to update particular attributes, while others can only read them. A customer email address might legitimately appear in six systems, but there should still be an answer to which system has the greatest right to say what that email address actually is.

The same principle applies beyond data. Which system has the right to communicate with the customer? Which can make a decision? Which can initiate automation? Which can approve an action? Which owns organisational knowledge? Which can modify another system’s record?

Thinking in terms of rights turns the exercise from a system inventory into an architecture.

Look for the Gaps Too

Overlap isn’t the only thing the matrix will reveal. Empty columns can be just as interesting.

You might discover that you have plenty of Systems of Record but no clear System of Knowledge. You collect enormous amounts of information without having a meaningful System of Insight. Automation exists everywhere, but nobody can identify where governance sits. Or perhaps AI is rapidly becoming a System of Intelligence without anyone having decided which Systems of Record and Knowledge it should trust.

These aren’t necessarily reasons to buy another product. Sometimes the capability already exists and simply hasn’t been deliberately assigned. The first step is recognising that the role matters.

Turn the Catalogue Into a Roadmap

Now the catalogue becomes much more useful than an asset register. For each role, consider who performs it today, who should perform it in the future, which system has the greatest right to own it, where responsibilities are unnecessarily duplicated and where no clear owner exists.

You don’t need to fix every overlap. Some will be completely intentional, some will be practical compromises, and some platforms will continue performing several roles because they genuinely are the best place to do so.

Other overlaps will reveal obvious opportunities. An old database can stop being a System of Record. A marketing platform can consume preferences rather than own them. A website can remain the System of Engagement without becoming another customer database. An integration can stop making business decisions that belong elsewhere. An AI assistant can become a powerful System of Intelligence without quietly becoming a System of Record.

That creates a technology roadmap based on something more meaningful than which products should we replace? It asks instead: what responsibilities should our systems have in the future, and how do we move from the architecture we have today to that architecture?

Your Architecture Already Exists

Every organisation already has answers to these questions. The problem is that those answers aren’t always deliberate.

Someone needed a field, so they added it. A project needed an integration, so one was built. A team needed automation, so they configured it. Another department bought a platform. A website started collecting information. A spreadsheet became surprisingly important. Now AI is being connected to all of it.

Individually, each decision probably made sense. Collectively, those decisions became your architecture.

Cataloguing your systems and assigning their roles gives you an opportunity to make that architecture deliberate again. Start with what you have, identify the roles each system plays, find the overlaps and gaps, decide which systems have the greatest rights, and use those decisions to shape where your architecture goes next.

Before deciding what technology you need next, understand the jobs you’ve already given the technology you have.