Abstract
One of the key aspects of the software architectures is the choice of the decomposition principle – how the software is divided into parts and via which interfaces these parts communicate to each other. There are several factors influencing the decomposition of software, some of them are technical or logical by nature, others are not related to computer science (such as politics, time and budget constraints, etc). In this post, I’m discussing yet another factor influencing the software architectures.
Prior Work
M. Conway stated in 1967:
Organizations are to produce software architectures which are copies of the communication structures of these organizations.
Before reading this law, I didn’t know that software architecture can be influenced by factors not related to its purpose (stated in technical and business terms). Even after reading it, I was sure that it was just some cynical rant and in reality, most of architectures are not influenced by it. I was wrong and you were right, Mr. Conway.
Still, I think I have noticed yet another non-CS factor influencing architectures – unrelated to politics and organizational charts.
The Law
Software architectures are decomposed using the same interfaces between the modules, that the software developers are using to communicate with their computers.
Examples
The punch cards generation
Software developers who have used punch cards as the primary user interface to their computers, tend to think in terms of memory maps. You can in fact visualize the memory map of computer code by putting several stacks of punch cards on top of each other in the right order. So, the typical interface between the modules either uses some well known RAM address location to pass parameters and to receive the results, or uses concepts like stacks or decks or ring buffer, which can also easily be modeled using the punch cards.
Typical programming language: Assembly.
Typical architecture decomposition tool: a big piece of paper hanging on the wall representing the memory map, with pencil marks on it defining the usage of each memory cell.
The command line generation
Software developers who worked with terminals in the command line see their computers as something accepting a command with some parameters. So their typical programming language is C – a C function is more or less a command with some parameters. In the UNIX world it is indeed often the case that an API C function and the command line executable bear the same name, so having learned how to use it in the shell you could easily use it exactly the same way in your C program.
Typical programming language: C
Typical architecture decomposition tools: structured programming, functions, modules with several related functions, ony some of them are publicly available to other modules and build the formal “interface” of the module that can be statically checked by the linker.
The GUI generation
Software developers who think about computers as something having a GUI, tend to think in terms of objects and containers of objects. The desktop is a container of windows, and each window is a container for other UI elements, and an UI element is a container of methods that are to be executed on mouse click.
Typical programming language: Smalltalk, C++, Java, C#, a lot of others
Typical architecture decomposition tools: OOP, polymorphic classes with virtual methods and inheritance. The modules can now contain several classes, and only some of them are publicly available to other modules. There is a granular control of what parts of software are visible to whom and what can be overridden. One or several modules can be put together in a package, and be installed and managed by package managers. They are versioned, have explicit dependency tracking, and semi-automatic documentation.
The web generation
Software developers who spend most of their time in the web browser or in the mobile apps like chats and social networks, tend to think in terms of hosts and resources available on that hosts.
Typical programming language: NodeJs, PHP, but actually they don’t matter that much any more
Typical architecture decomposition tools: RESTful web services (like web pages) and Message Busses (like Chats). Just like the computer device doesn’t matter for the web generation (as they interact not with their device, but with some web site somewhere in the cloud), their software can both run in a 1 inch by 1 inch small device on their wrist, or have its parts running in 10 different countries all around the globe – without changing anything in the architecture.
The generation Future
Observing the exponential growth of artificial intelligence and virtual reality, we could assume that the next generation of software developers will neither interact with a computer, nor interact with some internet resource. Instead, their own cognitive abilities will be augmented by silicon-based intelligence and some combination of local and global information networks. We can imagine that this augmentation could be seamless, so that they don’t even recognize, whether their order of a salad instead of a burger was their own decision, or an advice of their health monitor, worried by the blood sugar levels. The will not interact with any hardware, software or resource – these things will be just parts of the peoples personalities.
Typical programming language: actually, not a programming language, but a machine learning framework. Probably, something implementing the Neural Turing Machine.
Typical architecture decomposition tools: something from the areas related to AI psychology, AI parenting, AI training, education, self-control, self-esteem etc.