It is common to compute across autonomous boundaries. The patterns we use to cope with autonomy are rarely discussed even though they frequently impact how we use data and do work.
I’ve worked on and off for 23 years thinking about the implications of autonomy on work across boundaries. This paper is an updated version about Autonomous Computing and how it impacts many aspects of business today.
This paper introduces some common features in seen in the pattern of computing across autonomous boundaries:
Fiefdom: A whimsical name for the boundary of autonomy.
“Fiefdom” is an English word for an independent state such as a duchy, barony, earldom, or kingdom.
For example, Company-A and Company-B are independent and interact with each other as fiefdoms.
Collaboration: A formalism of the set of messages used to accomplish a single long-running business operation.
For many decades, paper forms correlated long-running work using sequence numbers.
This is common today as an application construct to link ongoing work together.
Emissary: Another whimsical name, this time for code running OUTSIDE the autonomous fiefdom who’s role is to help fill out messages. This pattern is still common with human emissaries (e.g., mortgage brokers helping you get a loan) as well as online shopping with products, and prices used to construct an order.
Based on this pattern, we explore the logical conclusions of how business happens. We conclude with some thoughts:
There is a relationship between the personal collaborations dedicated to one business partner AND the sharing of resources within the autonomous fiefdom (for example allocating inventory over time).
Each partner wants a façade of a personal interaction.
Resources managed are shared across many partners.
The behavior of each piece of the pattern EMPOWERS a scalable system.
Back when companies used paper forms, their solution was scalable based on the interaction of long-running work and the resources being managed.
We argue that applications CAN BE IMPLEMENTED to scale without significant bounds. This would be true if we were diligent in the implementation of the work.
Unfortunately, most implementations today impose artificial constraints on their scale.