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.
It’s hard to have a conversation with Jay without the issue of “context” coming up–often in a sharp rebuke along the lines of “the problem with him/her/them/it/you is that the context is missing”. Clearly context plays a critical role in Jay’s design philosophy, but I’ve had considerable difficulty understanding what this important, easily-overlooked ingredient actually is. In the last iteration of my theory, I equated context with elemental subsystems where tasks are performed (in this iteration, I’ve relabeled these elemental subsystems workstations and defined them slightly differently). I’m not sure the context-as-elemental-subsystem formulation is entirely misguided, but I now think it’s only halfway correct (at best) and possibly misleading. So, in this post, I take another stab at articulating the meaning of context with respect to enterprise software architecture.
To describe the concept of context, Jay often uses the example of a computer booting up and recognizing its configuration. The operating system detects the processor, memory, storage devices, network interfaces, and other peripherals that define its physical structure. Thus the operating system becomes aware of its context; that is, the environment within which the system operates.
During my last visit to Shinsei, I had a discussion with Pieter Franken that helped clarify the role of context in enterprise systems. Pieter walked me through the architecture of the funds transfer system. The behavior of this system, he explained, must be decided within a sequence of environmental constraints. First, there are the rules and regulations that define the space of allowable transfers. Then, there are the restrictions on the sender, which depend on the characteristics of the sender and the bank’s relationship with him or her. Next, there are restriction on the recipient, similarly contingent on the recipient’s identity and relationship to the bank. Finally, there are restrictions associated with a given transfer depending on characteristics of the transaction. These constraints, Pieter explained to me, represent the context within which an actual transfer of funds takes place (or not).
Thus the funds transfer process must “boot up” much like a computer, becoming aware of its context by recognizing first the regulatory environment within which it operates, then the sender who seeks to invoke the process, then the proposed recipient, and then the characteristics of the transaction. Only once the process has constructed an orderly model of its environment is it prepared to carry out the work.
Defined in this way, context represents a set of constraints in the action space within which a system operates. In the case of an operating system, awareness that the computer is not connected to a wired network invalidates a large number of possible actions, such as sending or receiving data over the wired network interface. Similarly, in the case of the funds transfer system, awareness that that regulations forbid transfers to a particular country rules out actions associated with performing such transfers.
Restricting the action space has several possible benefits. First, the system can figure out what to do more easily, because it searches for an appropriate action within a smaller and simpler space. Second, errors and rework may be avoided, since the system is less likely to choose invalid actions if these actions are placed off limits a priori rather than detected post hoc by filters applied a posteriori. Third, simplifying the action space reduces the number of potential security vulnerabilities.
It seems, then, that awareness of context may be understood as the possession of a well-structured model of how environmental conditions constrain or otherwise influence the space of actions available to the system.