Systems of Record vs. Systems of Engagement vs. Systems of State
This post is about how we’re thinking of combining all three kinds of system patterns at a high-level at Tallyfy.
We believe workflow management software has the unique potential to finally stitch these disparate pieces together.
Systems of Record
Examples — CRM’s, ERP’s, standard spreadsheets, “pretty” spreadsheets, tables, databases
This is well covered elsewhere, but systems of record are essentially dataset driven and include ERP’s, financial systems, CRM’s, EMR systems in healthcare, and so on. At a basic level, it’s also a spreadsheet, and apps that are “prettier spreadsheets” like SmartSheets and AirTable are plays on being systems of record for non-technical people.
Their core function is to suck up data and organize it, and often — inherently combine light and loose interactions from record-keeping operations. They tend to have layered permissions for CRUD (Create, Read, Update, Delete) for audit trails and blocks to/for certain people or groups.
The UI is really just a skin on great schema design around systems of record. Underlying database systems can be SQL-driven (more common) or just noSQL (which might work better for looser and more graph-driven records like in a CRM).
Systems of Engagement
Examples — Activity feeds, LinkedIn, Facebook, social networks, Twitter, Pinterest
When social networks became a “thing” in the early years of 2005–2015 — systems of engagement in their purest form were built for sticky engagement — and this evolution combined very loose records (stories, posts, etc.) with interactions and aggregations around those records. It turns out that someone realized that just updating records and objects wasn’t very glamorous, especially if they’re inherently conversation-worthy.
More specifically — such systems treat an object or record, like a photo, video, post or tweet as a micro-object that represents the classical social object. I personally remember having conversations with the early pioneers in social object theory — who went on to create and influence the social networking boom that was yet-to-come.
In my previous company, we had Dion Hinchcliffe on our team — and he summarized the above two like this:
Systems of State
Examples — Middleware like Microsoft Power Automate, Zapier, Boomi, Snaplogic, Mulesoft, Integromat — and to some extent — BI platforms like Tableau and Microsoft PowerBI.
At present, the early-stage representation of this category of software is best represented by middleware. This category of software has now become a commodity — but vendors in this area enable you to “watch” or “push” data between apps.
Pre-defined recipes are mostly triggered by a state change (a “trigger”) — although that’s highly limited since historical mining of datasets is not possible to achieve through simple middleware (that needs BI) — and then they do some sort of “action” — which either means moving data from place-to-place or automating some kind of status change between one app and another.
The marketing claim sits in the camp of “automation” but it’s not true automation, because it only works for well-defined movement of data from one place to another.
I don’t believe RPA sits in this bucket at all, as it just seems like over-hyped desktop recorders that mostly only apply to legacy apps or systems where clean data transfer isn’t possible i.e. systems with no API, for example.
I think a GitHub issue is quite inspiring, as it loosely combines state, record-keeping (to a very small extent) and engagement — in a single UI and object!
The future
At Tallyfy, we’re thinking of integrating to systems of record, then surfacing systems of engagement as an on-ramp or tasking layer — then using engagement to create state change in a way that blurs the boundary between all three. I can’t publish how exactly, but get in touch — I’d love to chat!
