One of the simplest and most useful user-facing functional structures for software, the Submit-Respond-Observe pattern often masquerades under different names. It’s ubiquitous and often hidden under layers of gold-plating, aesthetic frippery, and scaling (read: corporate/enterprise) features. Sometimes it’s camouflaged by useful, yet showier, features. It’s also susceptible to unimaginative user experience and user interface design. Let’s dive in.

Intent

Store and maintain information durably and externally to the information originator.

Motivation

• Information needs to be available to (the same or other) people or systems.
• Information is provided to and stored in some form of storage system. There is some response to the submitted information.

Applicability

Use this pattern whenever some information needs to be stored durably so that it, or its condition, is available at a different time or place, or by different participants.

Pattern Functions

Submit

An agent (person or system) provides some information to a receiving system. The information may be new to the receiver or a change or addition to information already known to the receiver.

Respond

*The receiving system stores the information or changes existing information. It may also provide feedback to the Submitter.

Observe

• An agent (person or system) can see the stored information's condition (age, completeness, correctness, integrity, etc).

Cautions and Pitfalls

• The pattern doesn't require a software system. For example, a submission made by writing on a piece of paper (the storage system) is a rudimentary example. The observe function in this case would be satisfied, for example, by tasks on a to-do list that are either unmarked or checked/crossed off to make each item's condition available to inspection.
• The pattern doesn't require software. Each function may be performed by either software or people. For example, a person might type information into a form and a system might respond by saving the information and providing feedback about that operation.
• The pattern doesn't require a person at all. A client and server communicating via an API is one example. A controller that sends a single to a vale that responds by opening or closing is another.
• The existence of different functions does not imply any particular solution in terms of technology. In a software system, the pattern doesn't prescribe or imply interfaces, storage technology, platform, medium, permissions or access control structures, and so on. Those choices are all either user experience design or software or system design choices.

Known Uses

• To-Do List
• Calendar
• Bug or Defect Tracking System
• Map or Navigation System
• Business Systems (such as billing)
• Manufacturing Systems (such as CNC)

Why It's Not…

…CRUD

CRUD is an acronym in software development that stands for Create Read, Update, and Delete (corresponding to database operations). CRUD could be chosen to implement this functional pattern. Other software design choices are possible, however, such as Command-Query Responsibility Segregation (CQRS).

…Personas

The pattern elements of Report-Respond-Observe don't correspong (necessarily) to any class or group of software users and don't imply anything about those user characteristics. You might identify multiple personas that all need or want to report information (such as people who want to report or problem vs people who want to complement a service provider). There could also be a single persona who performs all the functions (as, for example, in the paper-and-pencil to-do list described above).

…Permission or Access Control Groups

Whether there are multiple participants or just one, the pattern does not imply or prescribe any differentiation in the availability of any function to any participant. There may be a separation of capabilities so that one participate physically can't perform one or more of the functions.

However, additional patterns (such as Gatekeeper) may be combined with this pattern to differentiate actions and access. This will be more typical when also combined with the Review-Correct, Review-Approve, or other functions .

Related Patterns

• Write-Reply
• Instruct-Perform and its variations
  
  • Instruct-Perform-Review-Correct
  • Instruct-Perform-Observe
• Create-Consume and its variations
  
  • Create-Edit-Consume
  • Create-Publish-Consume
  • Create-Retrieve
  • Create-Edit-Organize-Maintain
  • Create-Review-Correct
  • Create-Review-Correct-Publish-Consume
• Gatekeeper
• Review-Approve

---

#FunctionPatternGuide