Mainframe computers. They’re big, powerful, expensive. Kind of like senior management, aren’t they? In many organizations this is what it looks like, and my theory is that early mainframe computers became what they are because of the organizations that made them (and not the other way round).
In the first post of the series I described Conway’s Law, and what you may learn on your organization by looking at your products. In this post I am describing a very high-level of mainframes, and how organizations may keep doing mainframe architectures, regardless of the product they are attempting to make.
The diagram on the right shows a typical mainframe computer high level architecture. There is a large central computer, a communication network, and end-points, or terminals, to access the computer.
Using this mainframe architecture, let’s describe some basic everyday scenarios:
- Person A, taking an order from a client, needs to get a price quote from person B, working on the catalog. In a mainframe world, the data entered by person A must go through the network to be processed in the mainframe in order for person B to get it.
- Person A, needs authorization for a discount from person C. They could be sitting next to one another, and yet the operation itself must be actioned on the mainframe.
In an analogy to organizations:
- Person A working on the application’s front end needs help from person B, the back-end expert. Person B needs permission to help person A. Since they don’t have a shared manager, the organization’s “mainframe” has to get involved. Even if they did share a manager, if it’s not in the company’s policy, the “mainframe” will have to authorize the operation and re-plan.
- Person A that needs authorization from person C to enhance an API, should get permission that involves the “mainframe”.
Let’s take this to a practical example:
The three individuals, A, B and C, are working on different aspects of an e-commerce website. Let’s imagine for a moment that the teams are feature and cross-functional teams. So person A is part of the “Accounting” team (front end, back end, testing, programming, UX – the full monty), person B is in the “Catalog” team, and person C is in the “DB and Performance” team.
As long as the “Accounting” team is working only on accounting features, and nothing else, things would probably work more or less smooth. When plans need to be adjusted there is a two-way communication with the “mainframe”, but that’s OK, apart from some time-sharing and context-switch issues when the “mainframe” is busy.
The trouble begin when the “Accounting” team needs to synchronize with the other teams. The “mainframe” is too busy to deal with petty issues which aren’t on its execution plan. The “DB and Performance” and “Catalog” teams are not too eager to change their plans for the very same reasons.
And so the “Accounting” team find itself finding “creative solutions” to the existing structure. The result:
The “Accounting” product (source code, tests, …) becomes secluded from the other products, and vice versa. rigid boundaries are being formed, and Hey Presto! Congratulations! You have a mainframe-like product, entrenching the mainframe like organization.
Not that there’s anything bad about it – if that’s what you’re looking for.
From the early days of computing, Von Neumann defined what a typical computer system looks like. This is not much different today – for any given computer system. True, the processor has many more functions, but the concept is the same. The difference is that there are many systems like this, not just one. Neumann’s concept borrows from Open System’s theory. See the images on the right, and how they resemble one another.
A mainframe architecture views the entire universe as a single open system, and everything outside it is its inputs and outputs. Other architectures do they same, AND all subsystems as open systems, too. So, for example, if an e-commerce website has an Accounting, Commerce, Catalog and Payment functions, a mainframe architecture sees the entire universe as a single system; a more distributed architecture may see these four elements as additional open systems.
This is a highly simplified description – of course software architecture running on a mainframe computer is (hopefully) more robust than this. My argument is to draw attention to the concept of a large mainframe and the functions it carries, and how this analogizes to organizations.
One major thing to realize in order to reduce the “mainframe” architecture effect is the power of the boundary.
In a mainframe culture the boundary is only around the mainframe itself. Whether the rest of the teams are part of the mainframe or not is irrelevant – this kind of system has little or no appreciation to the inner boundaries of the various systems.
So in order to better enable self-organized interactions between the team of person “A” and that of person “B”, the broader system needs to firstly appreciate that teams have boundaries, then to respect them, and only afterward to encourage a culture in which teams interact with one another – and not only with the “mainframe”.
Such a change should start at the “mainframe” level, and to keep investing in it.
In subsequent posts in the series I will describe how organizations are structured to do this, and how architectures reflect such structures.