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.
This is the first of what I intend to be a series of short posts focusing on a few important aspects of the information factory perspective that I’m starting to develop. In the previous iteration of this work, I defined Contexts as elementary subsystems where tasks are performed. In this iteration, in keeping with the information assembly line metaphor, I’ve decided to replace Contexts with workstations. The basic idea doesn’t change: a workstation is an elementary subsystem where a worker, in a role, performs a task. I’d like to add a few nuances, however.
First, at least for the time being, I’m going to rule out nesting of workstations. Workstations can be daisy-chained, but not nested. A hierarchical structure similar to nesting can be achieved by grouping workstations into modular sequences, but these groupings remain nothing more or less than sequences of workstations. Conceptually, workstations divide the system into two hierarchical levels: the organization level (concerned with the configuration of workstation sequences) and the task level (concerned with the performance of tasks within specific workstations). This conceptual divide resembles, I think, the structure of service-oriented architectures, in which the system level (integration of services) is conceptually distinct from the service level (design and implementation of specific services).
The purpose of the workstation is simply to provide a highly structured and controlled environment for performing tasks, thereby decoupling the management of task sequences (organization level) from the execution details of specific tasks (task level). Workstations are thus somewhat analogous to web servers: they can “serve” any kind of task without knowing anything about the nature of its content. Each workstation is provisioned with only those tools (programs, data, and personnel) required to perform the task to which it is dedicated. The communication protocol for a workstation is a pallet interface, by which the workstation receives work-in-progress and then ships it out to the next workstation. Pallets may also carry tools and workers to the workstation in order to provision it.
An implementation of the workstation construct requires an interface for pallets to enter and leave the workstation, hooks for loading and unloading tools and workers delivered to the station on pallets, and perhaps some very basic security features (more sophisticated security tools can be carried to the workstation on pallets and installed as needed).
David, requesting you to kindly clarify what do you mean by workers when you say in “Pallets may also carry tools and workers to the workstation in order to provision it”?
Vishnu, thanks for your question. With respect to tools, the answer is fairly simple, I think. As I understand it, the tools are simply data or executables (like apps or browser plug-ins) required to perform the task assigned to the workstation.
For example, consider a workstation that computes interest due on a late payment. The pallet entering the workstation carries the input parameters, probably including the amount of the payment, days overdue, the late payment interest formula, and so forth, as well as an empty slot for the interest due. The workstation has already been provisioned with a simple app (a sort of virtual robot, in essence) that knows how to take such a pallet, compute the interest due, and insert it in the appropriate empty slot. The app had been brought to the workstation on a pallet previously, installed, and configured to perform this task.
The reason for going to all this trouble is to introduce discipline and control into the preparation of the assembly lines, rather than allowing them to be constructed ad hoc. Assembly lines are build by setting up workstations, bringing the necessary tools to the workstations, and installing the tools according to a well-defined protocol. After the fact, we can audit exactly how the line was constructed and who installed which tools where.
With respect to people, the answer is a bit more ambiguous, since obviously real people cannot actually travel physically on virtual pallets. I think the idea is to control the virtual entry of people into workstations (essentially accessing the workstation via a user interface) in much the same way that we control the entry of data or code. So a person does not connect to a workstation directly in an ad hoc way; instead, the access occurs via pallets carried along an assembly line that targets the workstation of interest. This allows for a high level of discipline and control, as well as redundant logging.
Hi David, you are confusing between origination processes and lending core modules. Origination process is like building a car but core lending (the example you gave about interest calculation) is about running the car. these are two totally different scenarios and can not be interlinked. there is no pallet or station required when you talk about lending core function (example you gave). but yes if you talk about origination yes there as stages or stations etc.
I believe that confusion is quite possible if you do not have experience is the relevant field. in this case basic lending processes.