Systems of Engagement vs Systems of Reference – Core Concept for Infrastructure Architecture

Richard Fichera
Vice President, Principal Analyst
July 16, 2013

My Forrester colleagues Ted Schadler and John McCarthy have written about the differences between Systems of Reference (SoR) and Systems of Engagement (SoE) in the customer-facing systems and mobility, but after further conversations with some very smart people at IBM, I think there are also important reasons for infrastructure architects to understand this dichotomy. Scalable and flexible systems of engagement, engagement, built with the latest in dynamic web technology and the back-end systems of record, highly stateful usually transactional systems designed to keep track of the “true” state of corporate assets are very different animals from an infrastructure standpoint in two fundamental areas:

Suitability to cloud (private or public) deployment – SoE environments, by their nature, are generally constructed using horizontally scalable technologies, generally based on some level of standards including web standards, Linux or Windows OS, and some scalalable middleware that hides the messy details of horizontally scaling a complex application. In addition, the workloads are generally highly parallel, with each individual interaction being of low value. This characteristic leads to very different demands on the necessity for consistency and resiliency.

Systems of record, on the other hand, are often transactional, highly stateful, and demand absolute consistency and transactional integrity regardless of the value of an individual transaction (the state of an airline seat, for example, must be exact and must show consistently to every querying entity). As you might imagine, these qualities play out when considering where to stage a particular workload. Enterprise I&O groups have a strong penchant for wanting to keep systems of record close, since they represent highly valuable information about the state of the enterprise, and are often very unsuited to a runtime where latencies, data locality and scaling mechanisms are mismatched to their fundamental architecture without major surgery.

Many SoE solutions, on the other hand, lend themselves well to cloud environments, being written with no dependencies on underplaying hardware, and containing essentially transient data of little value per transaction and with no requirements for inter-transaction communication and lower demands for absolute consistency.

The bridges between SoE and SoR are often trouble points – Architecturally, collection and aggregation interfaces have always been problems in software design. In the case of SoE and SoR systems, we have to interface a front-end SoE system that generates a highly variable and unpredictable event stream to a back-end SoR that was architected for a more deterministic and serialized environment.[i]  While the developers of message busses and queuing software have worked near miracles, it still remains a potential source of problems. From an infrastructure perspective, these potential problem areas mean careful monitoring at both application and infrastructure and generous allocations of system resources to these parts of the solution, as well as attention to latency as data crosses from the cloud the enterprise.

This problem of “impedance matching” is generic to almost all forms of engineering, both electrical, mechanical, and software. Even early atomic bombs required a layer of aluminum between the explosive lens and the fissionable core to correctly couple the explosive shock waves to the core.


Related Posts