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.
David, whether it is a line in a speach or design of system or your blog, every thing is done under certain conditions and circunstances which are relevent to the specific event or fact.
Every thing will depend upon what is the condition and circumstance the specific thing is said, done, operates in etc. so every thing will of course have a context and these condition and circumstance is called context.
From defining architechural principles the importance will be how clear and unambiguos they are so that all people interpret the same way. From the building anology that you described in another of your blogs, in a building the design principles involved are related to basic strength of walls, coloumns and these can be determined. similarly system is the same.
Would it be appropriate to consider the concept of workstation as an evolution similar to the evolution of differentiated cells such as skin cells, digestive system cells, brain cells etc from an undifferentiated stem cell? The first generation systems like Unit Record Machines or tape and punched cards based IBM 1401s were like the single cell amoeba and SAPs or Oracle Application Implementations are like fully evolved animals but with extremely limited intelligence, and the workstation based architecture as an self evolving animal like human being!
Vishnu, thanks for your intriguing comment. I think it’s an interesting analogy. As you observe, evolution has lead to increasingly complex organisms with highly differentiated and modular subsystems. In some sense, that’s what we’re seeing here: a gradual process of refactoring functionality into separate subsystems.
The usefulness of the analogy may be limited, however, since natural evolution is an unplanned, non-forward-looking process without goals, while the evolution of system architectures is guided by explicit goals. Part of what is happening here is, I think, a change in the goals: rather than focusing on static efficiency and centralization, we’re aiming for dynamic efficiency (i.e., evolvability) and decentralization.
Indeed, the human being may actually resemble traditional enterprise systems more than the information assembly lines about which I’ve been theorizing. After all, a human being is highly centralized (cut the spinal cord at the neck and it’s game over!) and very difficult to modify.