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

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.

I’d be interested in hearing from people who have dealt with interfacing new SoE environments to existing back-end SoR systems. How do you deal with these challenges? How do you implement monitoring and capacity planning? Does you VM environment make this easier or does it complicate things?




[i]
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.

Comments

thanks!

"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." Thanks for informative article !
Proweb365

Financial and Operations Business Intelligence Solution

This is a good article & good site.Thank you for sharing this article. It is help us following categorize:
internet strategy, Delivering high-quality service for your business applications,
Solutions for all Industries,
Getting your applications talking is the key to better business processes,
Rapid web services solutions for real business problems,
Understanding Your Data is the Key to Good Decision-Making,
Web-based Corporate Document Management System,
Outsourcing Solution,
Financial and Operations Business Intelligence Solution,

Aligning front to back (SoE to SoR)

Hi Richard - Just stumbled on your post, but I think you've succinctly identified a critical problem. We all want more flexible/responsive user-experiences, but we need software architecture that can tie that front to back.

We've solved for this - www.enterpriseweb.com. I'd be happy to brief you and your colleagues.

Best Regards,
Dave

Post new comment

If you have an account on Forrester.com, please login.

Or complete the information below to post a comment.

(Your name will appear next to your comment.)
(We will not display your email.)
Email me when:
Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.