Contexts as elementary subsystems

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise architectures.  It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license.  I am indebted to Jay Dvivedi and his team at Shinsei Bank for sharing with me the ideas developed here.  All errors are my own.

Contexts are the elementary building blocks in Jay’s system architecture.  I’ll define Contexts precisely below, but let me begin with a passage from The Sciences of the Artificial that provides a frame for the discussion.

By a hierarchic system, or hierarchy, I mean a system that is composed of interrelated subsystems, each of the latter being in turn hierarchic in structure until we reach some lowest level of elementary subsystem.  In most systems in nature it is somewhat arbitrary as to where we leave off the partitioning and what subsystems we take as elementary.  Physics makes much use of the concept of “elementary particle,” although particles have a disconcerting tendency not to remain elementary very long.  Only a couple of generations ago the atoms themselves were elementary particles; today to the nuclear physicist they are complex systems.  For certain purposes of astronomy whole stars, or even galaxies, can be regarded as elementary subsystems.  In one kind of biological research a cell may be treated as an elementary subsystem; in another, a protein molecule; in still another, an amino acid residue.

Just why a scientist has a right to treat as elementary a subsystem that is in fact exceedingly complex is one of the questions we shall take up.  For the moment we shall accept the fact that scientists do this all the time and that, if they are careful scientists, they usually get away with it. (Simon, 1996, 184-5)

For Jay, the Context is the elementary subsystem.  Like an atom, the Context is in fact a complex system; however, designed properly, the internal structure of the Context is invisible beyond its boundary.  Thus, system architects can treat the Context as an elementary particle that behaves according to relatively simple rules.

What is a Context?

A Context is a logical space designed to facilitate the performance of a small, well-defined set of actions by people acting in a small, well-defined set of roles.  Metaphorically, Contexts are rooms in a house: each room is designed to accommodate certain actions such as cooking, bathing, sleeping, or dining. Contexts exist to provide environments for action.  Although Contexts bear some resemblance to functions or objects in software programs, they behave according to substantially different design rules (see below).

Defining the Context as the elemental subsystem enables us, by extension, to define the elemental operation: a person, in a role, enters a Context, performs an action, and leaves the Context.  All system behavior can be decomposed into these elemental operations, I’ll label them Interacts for convenience, where a person in a role enters, interacts with, and leaves a Context.  The tasks performed by individual Interacts are very simple, but Interacts can be daisy-chained together to yield sophisticated behavior.

Design rules for Contexts

Creating Contexts that can be treated as elementary subsystems requires adhering to a set of design rules.  Below, I describe some of the design rules that have surfaced in my conversations with Jay.  These rules may not all be strictly necessary, and they are probably not sufficient; refining these design rules will likely be an essential part of developing a highly-evolvable enterprise software architecture based on Jay’s development methodology.

  1. Don’t misuse the context. Only allow those actions to occur in a Context that it was designed to handle; do not cook in the toilet or live in the warehouse, even if it is possible to do so.  Similarly, maintain the integrity of roles: allow a person to perform only those actions appropriate to his or her role.  The repairman should not cook; guests should not open desk drawers in the study.
  2. Physically separate contexts. Locate Contexts on different machines.  Never share a databases among multiple contexts.
  3. Only Interacts connect a Context to the rest of the system. Data enter and leave a context only through Interacts, carried in or out by a person in a role.
  4. There is no central database. Every Context maintains its own database or databases as necessary.
  5. Each Context permits only a limited set of simple, closely related actions. Contexts should be like a European or Japanese house where the toilet, bath, and washbasin are in separate rooms, rather than like a US house where all three are merged into a single room.  If a Context must handle multiple modes of operation or multiple patterns of action, it should be decomposed into multiple Contexts.
  6. Avoid building new Contexts. If a required behavior does not appear to fit in any existing Contexts, decompose it further and look for sub-behaviors that fit existing Contexts. Build new Contexts only after thorough decomposition and careful consideration.
  7. Only bring those items–those data–into the Context that are required to perform the task at hand.
  8. Control entry to the Context. Ensure that only appropriate people, in appropriate roles, with appropriate baggage (data) and appropriate intentions can enter.
  9. Log every Interact from the perspective of the person and the Context. The person logs that he or she performed the action in the Context, while the Context logs that the action was performed in the Context by the person.  This creates mutually verifying dualism.

Why bother?

The purpose of establishing the Context as an elementary subsystem is to simplify the task of system design and modification.  As Simon points out, “The fact that many complex systems have a nearly decomposable [i.e., modular], hierarchic structure is a major facilitating factor enabling us to understand, describe, and even “see” such systems and their parts.” (1996, 207) Establishing the Context as an elementary subsystem in enterprise software is a technique for rendering enterprise software visible, analyzable, and comprehensible.

Bounding and restricting the Context vastly simplifies the work of implementors, enabling them to focus on handling a small family of simple, essentially similar actions.  The Context can be specialized to these actions, thereby reducing errors and  increasing efficiency.

Contexts hide the complexity associated with data and problem representations, databases, programming languages, and development methodologies, enabling system architects to focus on higher-level problems.  In discussions with Jay, he almost never mentions hardware, software, or network technologies, since he can generally solve design problems without considering the internal structures of his Contexts and Interacts.

Since myriad organizational processes are assembled from a relatively small library of simple actions combined in different ways, systems that support these processes exhibit similar redundancy.  Thus, Contexts designed to handle very simple actions can be reused widely, decreasing the cost and time required to develop new systems.

Finally, it is possible that Contexts, by explicitly associating people and roles with all actions, may help clarify accountability as organizational action develops into an increasingly complex mixture of human and computer decision-making.

Concluding thoughts

In essence, Contexts and Interacts are artificial constructs intended to allow high-level system design problems to be solved independently of low-level implementation problems.  The extent to which the constructs achieve this goal depends on the effectiveness of the design rules governing the constructs’ behavior.  Positing Contexts and Interacts as the elementary subsystems in Jay’s development methodology establishes a theoretical structure for further inquiry, but neither guarantee their fitness for this purpose nor implies the impossibility of other, perhaps more effective elementary subsystem constructs.

On several occasions, I’ve been asked how this approach differs from service-oriented architectures.  I’ll explore this question in a subsequent post.

Share on Google+Share on LinkedInTweet about this on TwitterShare on FacebookPin on Pinterest

6 thoughts on “Contexts as elementary subsystems

  1. Zahoor ul Islam

    Excellent Post. It would be great if in future post, you can further explore the motivation behind each rules, though they seems obvious but may you give them more meaning with some formal descriptions.

    I tend to disagree a little bit, to consider context as elementary structure in jay method, I more see that as a something similar to conscious activity of human mind with selective attention. It is more likely imposing a forced conscious shell for humans to make decision and act quickly.

    For machines context are bit irrelevant though can be applied, they work with simple input and produce expected outputs.

    It has always been challenging for design system for humans to work. That includes computer-human interaction, information representation etc. Traditional system design with application having so many options, menu and myriads of reports result in comprehensive but inefficient systems, moreover designed to be derive by humans. Jay has inverted that paradigm.

    Breaking up system in to elementary components make it possible for the Jay to execute it through machine (computer orchestrated – the orchestration includes driving machine components and as well as human components ), the decomposition of operations in to fine level of activities results in most of the activities can be executed and managed by the system, however considering the current state of technology we require humans to perform certain activities, we can replicate knowledge, document rules, however in case of fuzzy situation where some decision need to make, we require humans to use the experience, the experience represent that unstructured or disconnected knowledge which can’t be represented in the system. The other case where we do require humans, is to make them responsible. We can’t hold machine responsible in the court of law for some error, nor designer of such system want to get into it.

    Once put under machine control and machine based activities, a context to me a composition of human, role and information which then presented to targeted humans to make the decision, irrespective to higher concept the machines are operating. The simplification and restriction of context make the human respond immediately without thinking much or delaying it. As output is also controlled by machine, humans can’t delay or make wrong decision or it can be detected (mutually verifying dualism).

    So I think elementary component still are those decomposed elements. A human context precisely represents a gap in current computer technology, not to simulate or integrate with the external world operations.

    More philosophically we are restricting the choices and reducing the information to make the person act as efficient as possible without demystifying the illusion of free will. 🙂

    Zahoor

  2. MA

    Hi david, i just keep wondering what is the difference between what you are describing and SAO. as SAO has similar design principles.

  3. David James Brunner

    MA, I’ve been spending some time thinking about this and recently debated the question with a brilliant computer scientist friend of mine (who works for a tech company in the US, no affiliation with Shinsei). I’ll describe my thoughts in detail in a forthcoming post, but here’s a very quick answer. The principles of SOA are very broad, and cover almost all architectures that define modules in terms of input and output. As such, I think that Jay’s architecture can be classified as a kind of service-oriented architecture. However, Jay’s design rules impose a number of important additional constraints on the behavior of individual modules and the structure of module interactions. Although I do not yet fully understand these constraints or their implications, it is my current working hypothesis that these additional constraints make Jay’s architecture easier to modify and hence more “evolvable”.

  4. David James Brunner

    Zahoor, thanks for your thoughtful observations. It is my intention to further investigate and elaborate the design rules for Contexts. Also, I will clarify the role of people in a future post, since the description above may cause some confusion. Although Contexts can be used to frame interactions with human users outside the system, Contexts are also used for performing internal operations that do not involve direct interaction with external users.

  5. PA

    Thanks for the brilliant analysis. I have to say I’m all new to this. However, if we made sure that any complex system can be represented as a hierarchy of contexts or (nearly decomposable systems), can we automate the interacts? Say, for some contexts, the interact can be algorithms rather than people. If we wish to connect 5 different contexts in serial – whereby the bigger context composed of those 5 is represented by a user interface – the first context is used by a human, however the input from the first context is passed onto the second one, where the interact is a subroutine or an algorithm to transform such an input to another output.
    I know this might pose as a trivial question, but its always worth enquiring

Comments are closed.