Autonomous Computing (short version)

We frequently compute across trust boundaries. The patterns that cope with distrust are rarely discussed even though they impact how we use data and do work.

Abstract

Over 20 years ago, I spoke about how autonomy impacts our designs.  By 2001, I presented these ideas at a number of conferences.  I regret not setting them to prose.  Many of these ideas moved forward to be called SOA (Service Oriented Architecture) in the early 2000s.  Now, in 2021, as these principles still influence our designs, we don’t talk enough about them or their implications.

This paper introduces a concept called a fiefdom.  This is a collection of autonomous computing and data designed to work with untrusted outsiders.  This is not the same as Byzantine consensus since we don’t really draw consensus across these boundaries.

Another related computational component is an emissary, which is designed as a part of the fiefdom’s trust boundary, but it is NOT trusted.  It runs outside the trusted fiefdom.  The emissary makes working with the fiefdom simpler by providing an easy-to-use interface running close to the untrusted partner.  Since messages generated by the emissary match those expected by the fiefdom, incoming work usually succeeds, and more business is accomplished. 

Working across boundaries happens over time by correlating related messages.  Before computers, this was done with paper forms having unique serial numbers, multiple parts to the form, and successive modifications over time.  We will introduce an abstraction called a collaboration to explain how this works.  Like fiefdoms and emissaries, this is a pattern with many possible implementations.

These patterns are rooted in centuries of business practices helping companies work across boundaries.  While all the benefits I discussed 20 years ago still apply, there are even more ways to leverage these patterns in our distributed and replicated world.  This paper is finally the prose version of my many presentations on Autonomous Computing.  

1. Introduction

Autonomous computing comprises independent computer systems, whimsically named fiefdoms.  Fiefdoms are independently controlled and managed.  They don’t trust outsiders.  This is not about identity, authentication, authorization, or secure communications.  Those are incredibly important topics but not what this paper addresses.  This is about the flow of messages across trust boundaries, the data contained in those messages, and how to successful accomplish business across trust boundaries.  In this design pattern, the set of related messages comprising a single business operation is called a collaboration.  Another part of the pattern lies in emissaries, another whimsically named role for code running outside of the fiefdom’s trust boundary but with clear understanding of the fiefdom’s expectations.  We are going to examine how such distrusting systems interact, how data is handled, and how work gets done across boundaries.  

If you don’t trust your business partner you won’t share transactions with them.  Transactions aren’t used across organizations since this may lock up YOUR database if THE other organization messes up!  Without transactions, you must use multiple messages over time.  But running across time to get a long-running business task accomplished means you must deal with uncertainty about the outcome!   This, in turn, implies you must reconcile the work’s outcome.   All of this is implied by distrust.

When originally discussed over 20 years ago, fiefdoms were conceived of as a single database surrounded and protected by a two-tier application.  As time has moved on, I see examples of fiefdoms running over hundreds of thousands of computers providing massive scale.  The autonomous computing pattern is agnostic to scale both large and small.   Rather, it focuses on the importance of working across multiple interactions and correlating later messages to earlier ones using the abstraction we’re calling a collaboration.  Collaborations encompass business specific sequences of messages, how they interact, and how they are resolved.

In this paper, I will introduce fiefdoms, collaborations, and emissaries and show examples within computing and within our daily lives.  I examine how emissaries work outside the trust boundary and are NOT trusted, just convenient.  This paper examines how work across different fiefdoms can be initiated, run for long periods of time, and eventually complete. 

Finally, we conclude by reiterating that trust and shared work are based on both collaborations and the data shared between partners.

2. Fiefdoms, Collaborations, and Emissaries

Let’s introduce a few concepts seen in the common pattern I’m calling Autonomous Computing.

Fiefdom is an English word for an estate with its own independent leadership, rules, and sphere of control.  Historically, this included duchies, baronies, or other independent legal domains.  Each fiefdom has its own customs, laws, and way of doing things.  It is largely independent of other places.

An emissary is a representative.  It is person sent on a special mission as a diplomatic representative.  Unlike an ambassador, an emissary has NO authority.  They can only play nicely, suck-up, and try to ease the relationship.

Collaborations support messaging over time.  Like paper forms that empowered business before computers, a collaboration is modified by both emissaries and fiefdoms as they send messages back and forth.  In addition to tying together related messages, they provide a means to connect the work within a fiefdom or emissary to the long-running internal state supporting the cooperative business work.

I am describing computing patterns in many existing applications.  These patterns may be supported by relational data, no SQL key-values, and many other techniques.  

Correlating related messages to the work they stimulate empowers cooperative business work even when the partners don’t trust each other.

Let’s introduce the notion of a fiefdom within the autonomous computing pattern.  Then, we’ll consider the special role of an emissary: making it easier to work with the emissary’s fiefdom.  The collaboration messaging pattern gets our attention next.  Each fiefdom’s lack of trust changes the nature of data both inside and outside its rigid and untrusting boundary.

2.1.        Fiefdoms and Autonomous Computing

The only way to get work done with a fiefdom is by sending a message.  Each fiefdom has messages it accepts and specific requirements of partners sending work.

When I go to my bank’s ATM machine to withdraw cash, there are only a few things it lets me do.  I can withdraw cash, deposit a check, transfer funds, and check my balance.  All attempts to get a JDBC connection to the bank’s backend database have failed!  It’s like my bank doesn’t trust me!  How do we work together when one party doesn’t trust the other?  What about when neither party trusts the other?

This is what it’s like working with a fiefdom.  A fiefdom can be computing software and hardware, or it can be a bunch of people trying to do business together without computers.  

Requesting Service from a Fiefdom

Fiefdoms define their own rules for doing work. If you want cash, put in your ATM card and your PIN.  If you want to sell your products on the shelf of my mega-store, send me the following electronic messages describing the products and beg my permission.  In general, the shape and description of the interaction is defined by the fiefdom.

Sometimes, multiple fiefdoms work together.  Overall, the fiefdom with the most economic sway in the relationship defines the protocol and messages to be used.   The economic dog wags the economic tail.

Private Data within Fiefdoms

Encapsulated within the fiefdom is private data.  This is internal and rarely shared with outsiders.  My bank knows my accounts and their balances.  It doesn’t ME this information about YOUR accounts.  Heck, it doesn’t tell ME about MY bank accounts any more than necessary.

Private data encapsulated within the fiefdom may take many forms.  It contains the fiefdom’s most precious thoughts and business knowledge.  It is internal and should remain internal.

Transactions and Fiefdoms

Transactions across boundaries imply trust across boundaries.  Classic database transactions require coordination and may lock up data records awaiting the transaction’s outcome.  As a distrusting fiefdom, no way am I going to lock up MY database records awaiting YOU!  

Without trust, we have no distributed transactions.  Each fiefdom uses database transactions INSIDE its belly.  There is no way is it going to share a transaction with some miscreant business partner knocking at the gate of the castle. 

Fiefdoms are a design pattern for long-running interactions across trust across boundaries.  Work happens with a sequence of related messages over time to perform cooperative work.  This is how it was done centuries ago and it’s how it’s done today.

2.2.        Collaborations for Long-Running Work

A collaboration is an abstraction for a set of messages into and out of a fiefdom for a single long-running business operation.  This is not a new idea.  

When I was a kid in the 1960s, there were no computers in our daily lives.  Sure, large companies had them in the back rooms and the government and military had big mainframes.  We had no interaction with computers day to day.  Instead, we had paper.  When shopping, going to the doctor’s office, or getting something repaired, you filled out forms that controlled the activity.  I vividly remember the multi-part and multi-colored forms required to get something done.  

Sometimes, I would accompany one of my parents on some errand, dropping off dry cleaning, getting the car repaired, or ordering something at the department store.  A specialized form was pulled from below the counter and my parent would fill out Part-1 on the front page being careful to push hard with the pen so the writing appeared on the last page.  

Each of these forms was pre-printed with a serial number in the upper right corner.  When my parent finished filling out Part-1, the back page of the multi-colored form was torn off and handed back to them.  The rest of the pages were kept at the store or repair shop for internal use.  Different pages (with their unique colors) were kept within the departments, so every participant had a record.  These forms knit together the work of the internal departments of the business and tied it back to the customer.

The second from the back page was for the front desk.  It was torn off and filed by serial number into a file cabinet and the rest of the form went into the outbox to be routed to the business’ internal department.  They did some work, filled out Part-2, tore off the back page of the form, and send the form off on its journey.  The front desk’s file folder was organized by form’s serial number.  When work was completed and my parent picked up the purchase, dry cleaning, or repaired item, the paper form was filed by its serial number into the “completed work” file cabinet.

Each multi-part paper form is a collaboration.  It captures the request, tracks ongoing work, and ensures everything is done before the paper form is retired into the “completed work” file folder.

Doing work across trust boundaries frequently requires multiple interactions.  Correlating these interactions used to require paper forms.  In computing interactions, multiple messages must also be correlated and tied to earlier or later work.  This is the collaboration pattern.

Collaborations are implemented within most applications by tracking a unique number within each message. This is used to find the related messages in the collaboration and move the long-running work forward. This is how the abstraction becomes reality today.

Using Reference Data to Fill Out Fields in a Collaboration

One of the highlights of my mom’s year was the twice annual Sears catalog.  This was a massive book with hundreds of pages of stuff available for sale.  Dresses, kitchen items, and tools, you name it, and it was in the catalog. 

When the catalog arrived, many of us in the household would study the wondrous array of possible purchases.  Included was a form to fill out with item-numbers and prices.  These were diligently copied into the form to enumerate the desired stuff.  Mom would enclose the form in an envelope and send it to Sears along with a check for payment.   Weeks later, it was like Christmas when a delivery truck brought you all these things that were not easily attainable in your home town.

The information in the Sears catalog was, in my nomenclature, reference data.  Its sole purpose was to help you fill out the order form.  Since it only came twice a year, it was somewhat stale with passing time.  The catalog clearly stated how long the item-numbers and prices were valid.

We used reference data to fill out a collaboration to do work across distrusting boundaries.  In this example, Sears mail-order was a fiefdom.  We had no idea what internal departments within Sears were involved in fulfilling the order.  Both the reference data and the collaboration had a bounded lifetime.  They were created, spread across the trust boundaries, used for a while, and then retired.  Eventually, an expired Sears catalog became a doorstop or got fed into the fireplace.

2.3.        Emissaries: Helping the Interaction with Fiefdoms

I remember buying my first home in 1979, a tiny crappy place, too small for a family of six.  To get the mortgage, we went to a mortgage broker.  They are paid to be nice and make it easier for the borrower.

The mortgage broker was NOT employed by any bank.  Typically, they helped you get a loan from one of many banks.  They had information about various banks including rate sheets, the needed qualifications, and lots of stuff barely understandable to a 23-year-old first time home buyer.

When a bank was selected, we filled out lots of forms using the reference data cached in the mortgage broker’s desk.  When this stuff was presented to the bank, they did not trust it.  A credit rating and employment verification were ordered by the bank. Everything in the forms was checked by the distrusting bank.  The bank found this convenient since the mortgage broker knew how to fill out the forms correctly making bank’s job easier.

The mortgage broker is a real-life emissary.  They are not trusted by the bank but do a heck of a lot of useful work.  Unlike some emissaries, mortgage brokers can be the front-end to many different banks.

Within computing systems, we see many uses of the emissary design pattern.  Shopping at large eCommerce sites is done using an emissary as the front-end.  In this case, the emissary is implemented with thousands or tens of thousands of servers supporting shopping carts, product catalogs, images of products, recommendations, reviews, and much more.   Everything before the shopper pushes “submit” is an emissary pattern.  After you push submit, the request is sent to the backend system for payment processing, inventory check, shipment scheduling, and more. 

Complex and distributed back-end processing implements the eCommerce fiefdom.  Indeed, there will likely be many internal fiefdoms inside the big eCommerce back-end.

Sometimes Many Emissaries; Sometimes Many Fiefdoms

Consider your mobile phone and its applications.  Email comprises both a back-end fiefdom implemented by your mail-server(s) and an emissary on your mobile phone.  I have my phone’s mail connected to my work’s email and two personal accounts.  Browser-based mail clients may interact with the same mail servers or a different overlapping set.  The protocol between each emissary and its backend fiefdoms is a fancy collaboration for each of the emissary-to-fiefdom pairings.  This may seem like a shared database with optimistic concurrency but it’s not.  It is a protocol to add information, including possible tombstone denoting the intention to delete a mail message.  Mail messages are never really deleted.  If you doubt that, ask any FBI agent.  Instead, they are archived with tombstones indicating they’re not to be shown.

Emissaries are not trusted by fiefdoms.  Everything they do is verified behind the castle wall and inside the trusted computing environment.  Emissaries may provide a convenient front-end for many different fiefdoms unifying how the user sees them behind a single mortgage broker or a single mail client front-end.

Emissaries and Their Data

Emissaries may have reference data, perhaps in bulk form like the Sears catalog or perhaps in offline copies of stale email messages.  In addition, an emissary may have significant per-user state capturing your abilities as a borrower, your shopping cart containing proposed purchases, or your view of the downloaded email messages on your phone.

Emissaries are a design pattern that makes working with fiefdoms easier.  They are not trusted, execute outside the fiefdom they represent, and specialize in simplifying the multi-message collaboration with the fiefdom.

The key to the pattern comes from how data is used within the multi-message collaboration between the emissary and the fiefdom it is designed to support.

2.4.        What Is Offline Processing?

On one hand, offline processing is pretty easy.  Just buffer up enough reference data, take it offline, add messages to the shared collaboration, and squirt it over to the fiefdom when you reconnect.  Sitting at my mother’s kitchen table filling out forms for the Sears catalog is offline processing.  Working with the mortgage broker at their office is offline processing.  So is reading and writing email using my mobile phone.  

Of course, some applications have additional challenges.  Let’s address some of the easier problems first.  How can you know what data to bring along? Of course, that’s both application 
(or domain) specific and may depend on the user’s preferences or their history using the application.

Recurrent Reference Data

There’s a notion of recurrent reference data which is something you sign up for on a regular (or irregular) basis.  My mom’s biannual Sears catalog was offline recurrent reference data.  

Email is also offline recurrent reference data.  Most of us have multiple email accounts held with different mail providers.  In each case, an email account has a notion of the messages in each account.  A browser may access my email via one mail provider in a synchronous fashion. The mail client on my laptop, tablet, and/or mobile phone caches the offline state of my messages.  Each emissary (my device’s mail client) collaborates with its fiefdoms (one of the mail servers) whenever it can.  The intermittently offline emissary (my mail client) adds information to the collaboration shared by this mail client and a specific mail server.

This pattern of recurrent reference data is increasingly common as the complexity of our work increases.  We see many different shared folders, channels, groups, and team-blather-sessions to facilitate teamwork. Application-to-application usage of recurrent reference data is nascent and emerging.

Using Collaborations for Offline Work

Like a paper form, a collaboration provides limited communication across trust boundaries.

Collaborations may be implemented with some buffering within the emissary.  Unfortunately, implementing buffering is usually the responsibility of an application developer.  The autonomous computing pattern is usually hand-crafted within each application.  Allowing asynchronous delivery of the messages from the emissary to the fiefdom supports one piece of the puzzle needed for offline work.  Unfortunately, many of these mechanisms are re-implemented over and over for different applications.

Offline processing is simply asynchronous and buffered changes to a collaboration shared with the fiefdom.  Of course, some fiefdoms must also reconcile concurrent requests from many offline emissaries working with the fiefdom over multiple collaborations.  Some of these patterns are discussed in a longer version of this paper.

Complex Long-Running Business Work

Collaborations provide ordered full-duplex messaging within a single collaboration.  Across separate collaborations, all bets are off and no guarantees are made.  Within a collaboration, there may be ongoing work for minutes, hours, days, or months.  This implies some form of durable storage on each end, both within the fiefdom and within the emissary.  Many collaborations ongoing at the same time.  Each domain-specific application defines 
its notion of a single ongoing piece of work and leverages the collaboration’s ordered full-duplex set of messages to get the job done.

When you can’t do distributed transactions, you need to manage related messages.  

Collaborations simply group related messages for a single job over time.  How you do this within the pattern will vary with different implementations.

Richer partnerships for long-running work require richer message patterns.  Negotiating for the delivery of thousands of parts in different shipments scheduled to span months is complex.  It may need many messages before any shipment happens, during the timeframe of delivery, as well as to resolve the payment schedule and the closure of the work.  These are typically correlated with an identifier strongly analogous to the serial number in the upper right-hand corner of the paper forms from my misspent youth.  

Within the collaboration and its many messages, we may see messages from the participating fiefdoms or emissaries written into different “Parts” of the collaboration.  These are simply classes of messages sent by a collaborator for a specific purpose.  These may flow in a logically full-duplex fashion with each collaborator loosely-coupled from the other.  

All collaboration-based work is offline!

Collaborators (fiefdoms and/or emissaries) don’t share transactions, they are ALWAYS offline. Semantically, the work is not atomic and it must ratchet its way forward step-by-step to complete the business task.

2.5.        Rethinking Data across Trust Boundaries

There are special roles for data in the nether world between these collaborators.  Like all data flowing outside a trust boundary, this data is identified, possibly versioned, immutable (per version), and has descriptive metadata bound to it when created.  This is outside data as described in my 2005 paper Data on the Outside versus Data on the Inside.

In each case, data outside the fiefdom uses identifiers to knit it together:

• Collaborations have their messages associated by an identifier (e.g., an order-id). 

• Reference data will likely have products, prices, and options tied by one or more identifiers.  Email is knit together using internal unique message-ids.  In most cases, this is versioned over time.

• Single user data may correlate the ongoing business work to both the active collaboration and the reference data.  Shopping carts are single user data.

Inside the fiefdom, identifiers tie the collaborations and the ongoing work with internal state.

Both inside and outside the fiefdom, these identifiers may be kept in a relational database or may be kept in some other durable storage.  They must be durable to ensure they are ready for the next interaction with a related collaboration.  See my 2019 paper: Identity by Any Other Name.

3.  Working ACROSS Fiefdom Boundaries

Now, let’s look at work across distrusting fiefdoms.  Collaborations are used to cooperatively complete work while bounding the trust in partners outside the fiefdom.  Fiefdoms accept uncertainty in their plans and engage in an ongoing dance of accepting uncertainty and risk and resolving that uncertainty and risk.

3.1.        Working without Shared Transactions

You can’t count on distributed transactions across boundaries.  Transactions may happen on either side of a collaboration but may not span across boundaries.   If you don’t have shared trust, you don’t have shared transactions!

The alternative to a shared transaction is a shared sequence of messages.  That is the collaboration we define here.  The bi-directional sequence of messages is correlated and understood by both collaborators to be related as work proceeds over time.

This implies identity for each of the two collaborators as well as their on-going collaborations.  These identities must be long-lived to continue the work.  In real-life business interactions, there’s also some mechanism for ensuring payments by a collaborator.  For large businesses working together, we may see a contract with a threat of legal enforcement.  For B2C (business-to-consumer) work, the customer’s credit card ensures payment to the business.  The customer may challenge any wayward charges.

Each interaction in a collaboration starts by digging deeper into the solution and completes by digging back out.  When shopping at a large eCommerce site, you browse, check reviews, look at similar products, and add stuff to your shopping cart.  The retailer’s emissary enhances the shopping experience.  The quality of this offline (or pseudo-offline) experience contributes a LOT to the retailer’s profitability.

The emissary for eCommerce shopping is effectively offline because it’s not sharing a transaction.  You may see: “USUALLY SHIPS IN 24 HOURS” which tells you nothing at all but is incredibly useful.   It is a probabilistic statement with no transactional guarantees. Still, I’m always adding or removing items from the cart based on this phrase as I shop for the grandkids.  It’s useful!

When the shopping cart is full and the user pushes SUBMIT, lots of steps begin. Usually, the backend work is asynchronous over seconds, minutes, or days. Here are some typical steps:

• Emissary starts the collaboration: The front-end emissary combines the shopping cart, the user information (including addresses and credit cards), product-ids, pricing information, gift wrapping requests, and more into a single message. This message is enqueued to the backend system at the eCommerce retailer for order-processing.

  Async but frequently fast: Normally, you hear a “bleep” as an email comes to the human user seconds after the SUBMIT. Sometimes, this “bleep” happens 30 minutes or so later if the backend order-processing system is busy, and its work queue backs up.

• The collaboration begins: This starts a collaboration to implement this order. The order-ID correlates all work for this ongoing request. Payment is extracted from the credit card. Messages, sometimes via email, advise the consumer of shipment, delays in shipment, out-of-stock problems, and completion of the order.
  The collaboration completes: When the stuff is delivered and the credit card charged, that usually completes the collaboration. In reality, it is kept alive for a while in case the customer cancels the order. Only after 30 to 90 days will the collaboration be complete.
  

In this example, email messages to the human fulfill some of the collaboration’s role. The emissary’s reification is a bit fuzzy. Still, the pattern is identical for many business operations.

Collaborations involve tentative work, their possible cancellation, and their hopeful completion over time. Cooperative work by distrusting parties involves multiple steps within a framework for financial damage to the other party if necessary. Correlating related messages is essential.

The use of an order-id or some other identifier to knit together the collaboration is an example of the general concept of using identifiers to connect work in distributed environments.

3.2.        Collaborations, Uncertainty, and Reconciliation

It is common for distrusting fiefdoms to accept and resolve business commitments.  The nature of these varies based on the domain of the business, their protocols, and their appetite for risk.  Some enterprises go out on the limb to get business, accepting occasional loss as a cost of business.  Others, only want strong assurances to move forward.

In all cases, sequences of correlated messages flow between the prospective collaborators.  

It is the nature of these correlated messages, their identity as a set of messages, and the patterns of their use that shape the autonomous computing pattern.

Using a sequence of messages, the communicating fiefdoms (or trust boundaries) establish some form of limited trust, usually by ensuring financial compensation should it go wrong.  Time passes and messages flow to deepen the relationship, accomplish the goals, and back their way out of this single collaboration.  Commitments may fail and the businesses recover.  

It is the correlated sequence of messages we call a collaboration that empowers this work across fiefdoms, both B2B (business-to-business) and B2C (business-to-consumer).

Inside a fiefdom, the business manages its risk, balancing between commitments made via its collaborations and its challenges meeting those commitments.

Work using collaborations is contractual and may involve financial penalty. The fiefdom sets rules and regulations for cooperating over the collaboration including various contingencies.  This sequence of events takes time (perhaps months or longer) and time-based exceptions are the norm.  See my 2009 paper Building on Quicksand for discussion of overbooking, over provisioning, and coping with uncertainty in long-running autonomous computation.

4.  Working WITHIN a Fiefdom

So, how do folks design an autonomous fiefdom?  How can it support the long-running work necessary to meet its collaborative commitments over time?

Typically, the work is broken down into a couple of different roles within the fiefdom.  

• Activities are data and computation used to track the fiefdom’s work on for a single collaboration, or part of the work for a single collaboration.

• Resources are code and data used to manage shared things coordinated across multiple activities such as widgets in inventory or space on a truck needed for a shipment.  

These patterns support external collaborations and are frequently composed using many internal collaborations.  

4.1.        Inside a Fiefdom: Activities and Activity Data

When an incoming collaboration come into a fiefdom, an internal data structure is allocated to track the collaboration’s messages, work stimulated by these messages, and work’s completion.  These activity data structures are encapsulated by fiefdom specific activity code.

Work advancing this activity is stimulated by any of:

• An external message arriving on an external collaboration.

• An internal message on an internal collaboration used to drive intra-company work.

• A timer advancing the activity to a new state and perhaps taking new actions.

Fiefdoms create mechanisms to manage their activities’ workflows.  There are many ways to make this pattern work.  Here, we focus on the pattern and its implications.

Activities do not live forever.  Their lifecycle is driven by the workflow needed to successfully complete business with the collaboration’s partner.  They are created in response to collaboration messages, live for a while (perhaps seconds, hours, or months), are retired into a read-only state, archived, and eventually deleted years later.

4.2.        Inside a Fiefdom: Resources and Resource Data

Tangible things are managed using resources such as inventory, shipments on a truck, passengers booked for a single flight, king-sized-non-smoking-rooms booked for a particular night, billable dollars per customer for a single month.  All of these are examples of resources.

Frequently, a resource and its surrounding resource manager must deal with uncertainty.  Resources may be allocated for a customer but need payment before shipping.  Scheduled space on a truck goes unused if an incoming truck is delayed.  A resource manager for outgoing shipments may place a waiting box on an outgoing truck but only if the activity controlling the waiting box confirms the change.

Resource managers work with time, incoming resources, outgoing resources, over-provisioning (to ensure customer happiness) or overbooking (to manage expenses).  They cope with an ever-changing world across many competing activities.  Sometimes, they fail to meet obligations to one activity due to the demands of another activity.  

Inside each resource manager are little activities.  These track the single allocated resource (or pending resources) and correlate back to a larger scale activity tied to an external collaboration.  These, in turn, impact the allocation of the precious resources for other activities.

Resources see increasing and decreasing uncertainty, especially when overbooking their managed resource.  Only when the flight flies away do we really know who’s on it!

Many collaborations and their messages connect these many activities and resources.  This can provide a unified way to wake up activities, resources, and collaborations in response to incoming events or timers. 

5.  Conclusion: Trust, Collaborations, and Data

Autonomous computing is a pattern for business work using collaborations to connect fiefdoms and their emissaries.  

This pattern has been used for centuries based on paper forms.  

How can we make it easier for folks to follow this pattern as they solve business problems with computers? We should help them focus more on their business and less on hooking stuff together!

Open Questions

• Why do distrusting business and departments choose to NOT allow transactions with outside business partners?

• What incentive do fiefdoms have to do these long-running operations?

• Why do computer scientists reject this USEFUL pattern and say “That’s just an application issue.” Is it too hard for them to think about? Do they think this is not computing? Do they think this is not science?

• What services to help this pattern could be provide below the application? Can this be made easier?