The Operating Layer

Organizations of every size now run on many systems of record. Each one holds a part of the business, and the work that connects them is done by people: re-keying a signed contract into the ERP, exporting a report because the source system cannot answer a question, reconciling two copies of the same customer. This paper describes an operating layer that takes on that connecting work. It consists of an ontology that defines the organization's objects once, deterministic and AI-assisted workflows that act on those objects across the connected systems, and a governance record of every action. The paper sets out why the layer is organized this way, how each component is defined, how it is built with a client, and how it differs from integration platforms, reporting tools and the enterprise ontology products that preceded it. Benmore Substrate is our implementation of this layer. The paper refers to it where the implementation matters and to the approach where it does not.

1. Introduction

Benmore Substrate is an operating layer for organizations that run on several systems of record. It connects those systems through a shared ontology, runs the workflows that move work between them, enforces who can see and do what, and keeps a record of every action taken. Applications built on the layer use the same ontology and the same permissions, so a new tool does not introduce a new copy of the data.

The layer is not a replacement for the ERP, the CRM, the student information system or the payroll platform. Those systems remain the system of record for what they hold. The layer sits above them and is responsible for the work that happens between them, which today is largely done by hand.

This paper is written for the people who decide how an organization's systems fit together: technology leaders, operations leaders and the finance and department heads whose teams do the connecting work. Section 2 describes the problem as we encounter it. Section 3 sets out the three things an operating layer must let an organization do and explains why one of them matters more than the other two. Sections 4 through 10 define the components of the layer. Section 11 describes how it is delivered, and Section 12 places it against adjacent approaches.

2. The shape of the problem

An organization accumulates systems one decision at a time. The ERP was chosen when the business was smaller. The CRM arrived with a new sales leader. Payroll moved to a platform. A department bought a scheduling tool, another bought a forms tool, and several processes still live in spreadsheets because no system handled them. Each purchase was reasonable. The result is an estate of between ten and a hundred systems, each of which holds a partial view of the same customers, products, employees or students.

Three consequences follow.

2.1 Each system holds its own copy

The same customer exists in the CRM, the ERP and the support tool, entered separately and drifting apart. Reports built from different systems disagree, and the disagreement is resolved in a spreadsheet by a person who knows which system to trust for which field. That knowledge is rarely written down.

2.2 Getting data out is a project

Many systems of record were not designed to expose their data. They provide an export, a scheduled file drop, or a request to a vendor who manages the system. Each new question means a new extract. Over time the organization stops asking questions it cannot afford to answer.

2.3 People are the integration

The work that moves between systems is done by staff. A signed contract is read and re-entered into the ERP, then entered again into a supplier portal. A requisition is filled in on a form, printed, approved by signature, and keyed into finance. The steps are deterministic. No judgment is applied. The person is executing a workflow that was never written down as one.

No individual system is at fault. The organization has no layer whose job is the space between them.

3. Seeing, building and doing

An operating layer gives an organization three capabilities. It can see its operations: reports, dashboards and the answer to a question asked in plain language. It can build: new applications and tools on top of its data. And it can do: work moves between systems and gets completed without a person carrying it.

Products exist for each capability on its own. Business intelligence tools let an organization see. Low-code platforms let it build. Integration platforms let it do, provided someone configures them. The three are usually bought and operated separately, each with its own copy of the data and its own permissions.

We organize the layer around doing, for a practical reason. Consider how often each capability is exercised. A workflow that moves a signed order into the ERP and notifies the plant runs every time an order is signed, which may be many times a day. A dashboard is opened daily or weekly. A question is asked of the data a few times a month. A new application is built a few times a year. The value of the layer is realized in proportion to that frequency, and the workflows are where the value accrues continuously, whether or not anyone is looking.

There is a second reason. Seeing and building require adoption. Someone has to open the dashboard or learn the builder. Doing requires none. Once a workflow is in place it runs the way plumbing runs, and the organization experiences its absence as a failure rather than its presence as a feature. That makes it the right foundation: it delivers value from the first day without asking anyone to change how they work, and it is the thing an organization cannot later remove.

Seeing and building remain part of the layer. They are built on the same ontology and governed by the same rules, so they inherit the data and the permissions rather than duplicating them. They are the capabilities people reach for when they choose to. Doing is the capability that runs regardless.

4. Architecture

The layer has four parts. Sources are the connections to the organization's systems of record and the data drawn from them. The ontology is the shared definition of the organization's objects, their properties, the links between them, and the actions that may be taken on them. Governance is the set of rules about who may see and do what, the approval steps that pause a workflow for a decision, and the record of what was done. Execution is the runtime in which workflows and applications act on the ontology and write results back to the connected systems.

The order of the parts is deliberate. Sources exist before the layer does. The ontology is defined from them. Governance is attached to the ontology, so that a permission is stated once about an object rather than separately in each tool. Execution is the last part, because workflows and applications are only as reliable as the model they act on.

The following sections take each part in turn.

5. Sources

A source is a system of record together with the connection through which the layer reads from it and, where permitted, writes to it. The layer connects to a source in whatever way the source allows: an API where one exists, a database connection, a scheduled file delivery, or a watched folder. A source that can only produce a nightly export is still a source. The layer is designed around the assumption that many systems of record cannot be queried on demand.

5.1 The data layer

Data drawn from sources is kept in two forms. The first is the raw form, exactly as received, with the date and time of receipt. Nothing is altered. If a report is questioned six months later, the file that produced it can be found. The second is the cleaned form: typed, de-duplicated, and joined across sources into tables that correspond to the objects in the ontology. Reports, workflows and applications read from the cleaned form.

The data layer is built on the client's own cloud account using standard services for storage, processing and identity. The choice of platform follows what the client already runs. The layer does not require a particular vendor, and a client that has already invested in a data warehouse keeps it.

5.2 Field ownership

Every property in the ontology has exactly one owner. Either a source system owns it, in which case the layer reads it and never writes it, or the layer owns it, in which case it is stored in the layer and the source systems do not hold it. The decision is recorded for each property and is the first thing settled when a source is connected. It prevents the most common failure of integration projects, which is two systems each believing they hold the authoritative value.

Table 1. Field ownership for a customer object in a manufacturing business. Each property has one owner. The layer reads what sources own and stores what they do not.

5.3 Changes in a source

Sources change. A vendor adds a column to an export, a field is renamed, a file arrives late. The layer treats each of these as an event to be surfaced rather than absorbed. A changed layout stops the affected workflow and notifies the owner; it does not silently load misaligned columns. A late file raises an alert at the time it was expected. These checks are inexpensive and they are the difference between a data layer that is trusted and one that is quietly worked around.

6. The ontology

An ontology is a description of the organization in its own terms. It names the things the organization works with, says what is known about each of them, how they relate to one another, and what may be done to them. It is defined once and shared by every workflow, view and application in the layer.

The word is borrowed from the enterprise platforms that introduced the idea to large companies and government. The concept is the same at any scale. What differs in a mid-sized organization is the number of object types, which is usually in the dozens rather than the thousands, and the cost at which the ontology must be built and maintained.

6.1 Object types

An object type defines a kind of entity or event in the organization. Customer, product, quote, employee, campus, requisition and shipment are object types. An object is one instance: a particular customer, a particular quote. Object types correspond to the nouns people use when they describe their work, and the ontology is built by listening for those nouns.

6.2 Properties

A property defines a characteristic of an object type. A quote has a date, a customer, a currency and a status. A student has an enrollment date and a campus. Properties are typed, and each has one owner as described in Section 5. Properties that mean the same thing across object types, such as a postal address or a cost center, are defined once and shared.

6.3 Links

A link defines a relationship between two object types. A quote belongs to a customer. A line item belongs to a quote and refers to a product. A student is enrolled at a campus. Links are what allow a question such as "which customers have open quotes for products made at the Texas plant" to be answered without anyone writing a join.

6.4 Actions

An action defines a way an object type may be modified, together with the conditions under which it is allowed. Approve a discount. Submit a requisition. Convert a quote to an order. Actions are the only way workflows and applications change the ontology, which is what makes the audit record complete: every change is an action, and every action is recorded with who took it, when, and from where.

6.5 Relationship to the data layer

The cleaned tables in the data layer and the ontology describe the same facts in two forms. The table is how the data is stored; the ontology is how it is understood. A table corresponds to an object type, a row to an object, a column to a property, and a join to a link. Both are kept on purpose. The table is what makes the ontology fast to query, and the ontology is what makes the table safe to act on.

Table 2. Correspondence between storage concepts and ontology concepts.

7. Workflows

A workflow is a sequence of steps that moves work between systems and through the ontology. It is triggered by an event, such as a document being signed, a file arriving, a record changing in a source, or a person submitting a form. It reads and writes objects through actions, and it may call out to a source to create or update a record there.

7.1 Deterministic workflows

Most of the work that people do between systems is deterministic. The steps are known, the inputs are known, and the outcome does not depend on judgment. A signed contract contains a customer, a product list and a price; the ERP needs a sales order with the same fields; the supplier needs a purchase order derived from it. A deterministic workflow performs these steps the same way every time and stops if an input is missing or malformed.

Deterministic workflows are the base of the layer. They are defined during delivery, they are visible and editable to the client's own administrators, and they run without anyone's involvement. When the client replaces a source system, the workflow is re-pointed at the new connector and the rest of it does not change.

7.2 AI-assisted workflows

Some steps require reading, classifying or drafting rather than copying. A support request must be categorized before it can be routed. A supplier's document must be read to find the delivery date. A quote for a non-standard product needs a first draft that an engineer will correct. In an AI-assisted workflow, a model performs that step and the result is treated the same way as any other input: it is validated against the ontology, it passes through the same approval rules, and it is recorded as an action with the model named as the actor.

The model does not have standing access to the organization's data. It sees the objects the workflow passes to it, under the permissions of the person or role on whose behalf the workflow runs. A model acting in a workflow has the same constraints as a new employee in the same role.

7.3 Writing back to sources

A workflow writes to a source only through a connection that was explicitly granted and only to properties the source owns. For many clients the first implementation writes to no source at all; it reads from the systems of record, maintains its own objects, and a person completes the final entry. This is a sound starting point when the source's data structures are not yet harmonized across the business. Write-back is added once the ontology is stable and the client is ready for it.

8. Governance

Governance in the layer has three parts: roles, approvals and the audit record. All three are attached to the ontology rather than to individual tools, which means a rule is stated once and every workflow, view and application honors it.

8.1 Roles

A role is a named set of permissions over object types, properties and actions. A role may read an object type, read particular properties of it, take particular actions on it, or do none of these. Sensitive properties such as a student's health record or an employee's compensation are restricted at the property level, so a role that may see the student can still be prevented from seeing the field. Roles are tied to the organization's existing identity provider; the layer does not maintain its own list of users.

The same roles govern what a person may ask the intelligence layer and what a model may do inside a workflow. There is no separate permission system for AI.

8.2 Approvals

An approval is a step in a workflow that pauses execution until a person with the appropriate role decides. Approvals are defined on actions with conditions: a discount beyond a tier, a purchase above a threshold, a change to a pricing rule. When the condition is not met, the workflow proceeds without a pause. When it is met, the person sees the object, the proposed action and the reason it was held, and their decision becomes part of the record.

8.3 The audit record

Every action taken through the layer is recorded with the object it affected, the actor (a person, a workflow or a model), the time, and the before and after values of any property that changed. The record is append-only and is readable by roles that have been granted it. For organizations subject to privacy or financial regulation, this record is often the first concrete benefit of the layer, because it exists from the first workflow rather than being reconstructed after a question is asked.

9. Views and intelligence

A view is a dashboard, report or list built on the ontology. Because views read from the same objects that workflows act on, a number on a dashboard and the record behind it are the same thing. There is no separate reporting copy to fall out of date. Views are configured by the client's own users within their roles, and the most common views are set up during delivery.

The intelligence layer allows a user to ask a question in plain language and receive an answer drawn from the ontology, or to ask for work to be done and have the request become a workflow run. It is governed by the same roles as everything else: a user receives only answers built from objects and properties their role may see, and a request to act is subject to the same approvals as any other action.

It is used less often than the workflows, for the reason given in Section 3. The intelligence layer is a capability that people reach for when they have a question. The workflows are the capability that runs when no one is asking.

10. Applications

An application is a tool built on the layer for a specific process: a product configurator, a requisition and approval system, a dealer portal, a field inspection form. Applications read and write objects through the ontology and its actions, so they inherit roles, approvals and the audit record without implementing any of them.

An application built this way can also act as a source. A configurator that owns the quote object is the system of record for quotes, in exactly the way the ERP is the system of record for orders. Other workflows read from it and write to it through the same mechanisms. This is how an organization adds a system without adding a silo: the new system is defined in the ontology before it is built, and it connects to everything else by construction.

Applications are built on the layer by Benmore during delivery or by the client's own team afterwards. Because the ontology and governance already exist, the application itself is small. Most of what would otherwise be built, including data access, permissions, approvals and audit, is already there.

11. How the layer is delivered

The layer is delivered by a small team of engineers who work inside the client's organization for the duration of the engagement. We call this forward deployment. The engineers sit with the people who do the connecting work today, map what they do, and build the layer to take it on. The alternative, in which a vendor configures a platform remotely from a requirements document, produces a layer that reflects the document rather than the work.

11.1 Discovery

Discovery is a fixed-fee phase of a few weeks. The team maps the systems of record, who owns each, what data each holds and in what form it can be obtained, and the rules that currently live in spreadsheets and in people. It identifies the workflows that consume the most staff time and the one use case that would prove the layer to the organization. The output is a written scope with a fixed price and timeline for the build. A client that decides to proceed with a different partner leaves discovery with the map.

11.2 Foundation

The foundation is the data layer, the source connections and the first version of the ontology, built in the client's own cloud account and defined as code so that it can be rebuilt or copied to a test environment. Governance is attached at this stage, before any workflow runs.

11.3 First workflows and first application

The deterministic workflows identified in discovery are built, run alongside the existing manual process until they are trusted, and then take it over. The first application follows. It is chosen because a department will use it daily, so that the layer is seen to work.

11.4 Handover

The layer is handed to the client's team with documentation and training. Administrators can see every workflow, edit it, and re-point it when a source changes. Ongoing support is scoped separately and is not required for the layer to operate.

12. Comparison with adjacent approaches

The components of an operating layer each exist as products. What is distinctive is their combination, the ownership model, and the scale at which they are delivered.

Table 3. How the operating layer relates to the approaches an organization is likely to have tried or considered.

The enterprise ontology platforms deserve particular mention because the approach in this paper is descended from them. They established that an organization should be modeled once and that applications should act on that model under governance. They were built for the largest organizations, with engagements and licensing sized accordingly. The organizations described in Section 2, which run on tens of systems rather than thousands and have IT teams of a few people rather than a few hundred, have the same problem at a scale those platforms were not designed to serve. The operating layer is the same idea delivered at that scale, with the configuration done for the client rather than by them.

13. Conclusion

The work that connects an organization's systems is real work. It is done every day by people whose jobs are described as something else. An operating layer takes on that work: it models the organization once, runs the workflows that move work between systems, governs who may see and do what, and records what was done. Views, intelligence and applications are built on the same model and inherit the same rules.

The layer is delivered in stages, each of which is useful on its own. The data layer is useful before the ontology is complete. The ontology is useful before the first workflow runs. The first workflow is useful before the first application is built. An organization can begin at the stage its situation calls for and proceed as far as it finds valuable.

Benmore Substrate is our implementation of this layer. It is deployed hosted or in the client's own environment, delivered by forward-deployed engineers, and handed over to the client's team to operate. Further detail is at benmore.tech/substrate.

Benmore Technologies, Chicago · Tim Uzoegbu · [email protected] · benmore.tech