Most Software Architects Are Charlatans
Unless they provide strong justification of what they do and why
Charlatan (Czech: Šarlatán) is a 2020 Czech-Polish-Irish-Slovak drama directed by Agnieszka Holland based loosely on the healer Jan Mikolášek (1889–1973), who cured hundreds of people using plant-based remedies. It was selected as the Czech entry for the Best International Feature Film at the 93rd Academy Awards making the February shortlist. It won five awards including Best Film at the 2021 Czech Lion Awards.
Mikolášek's diagnostic methods and notorious healing got the attention of Czechoslovakia's government. He was finally arrested after strychnine was found in the bodies of two men he had treated. In real life, Jan Mikolášek was tried and convicted in 1959 of tax and other offenses, but not for murder by strychnine poisoning, was released in 1963, and died in 1973.
For this post, I am after Software Architects, just like the Czechoslovakia government. The post argues that:
Most Software Architects Are Charlatans … Unless they provide strong justification of what they do and why.
The way this article proceeds is analyzing the following Architecture Tower:
Solution Architecture
Computational Architecture
Hardware Architecture
Computer Architecture
Each of the above architecture is prcisely defined and there is strong justification. This tower could have been:
Solution Architecture
Computational Architecture
> Software Architecture
Hardware Architecture
Computer Architecture
But, Software Architecture is deliberately omitted. That is this article about:
Software Architecture is omitted since often there is no strong justfication. What we typically witness is Fog of Software Architecture
Computer Architecture
The von Neumann architecture—also known as the von Neumann model or Princeton architecture—is a computer architecture based on a 1945 description by John von Neumann, and by others, in the First Draft of a Report on the EDVAC. The document describes a design architecture for an electronic digital computer with these components:
A processing unit with both an arithmetic logic unit and processor registers
A control unit that includes an instruction register and a program counter
Memory that stores data and instructions
External mass storage
Input and output mechanisms
The term "von Neumann architecture" has evolved to refer to any stored-program computer in which an instruction fetch and a data operation cannot occur at the same time (since they share a common bus). This is referred to as the von Neumann bottleneck, which often limits the performance of the corresponding system.
The Harvard architecture is a computer architecture with separate storage and signal pathways for instructions and data. It is often contrasted with the von Neumann architecture, where program instructions and data share the same memory and pathways. This architecture is often used in real-time processing or low-power applications.
It is not accidental that two examples of Computer Architecture is provided which are diamentrically opposite in styles. This is to make the following point:
Computer Architecture Has Very Strong Justification
For example:
Digital signal processors (DSPs) generally execute small, highly optimized audio or video processing algorithms using a Harvard architecture. They avoid caches because their behavior must be extremely reproducible. The difficulties of coping with multiple address spaces are of secondary concern to speed of execution. Consequently, some DSPs feature multiple data memories in distinct address spaces to facilitate SIMD and VLIW processing. Texas Instruments TMS320 C55x processors, for one example, feature multiple parallel data buses (two write, three read) and one instruction bus.
Hardware Architecture
Belive me on this claim:
Computers are not made of only Computer Architecture
Why?
Remember that Computers need to interact with outside world - like:
Input
Mouse
Microphone
Keyboard
Brain (Neuralink)
API / Network
Output
External Storage
Display
Sound
So we have Hardware Architecture, defined as:
In engineering, hardware architecture refers to the identification of a system's physical components and their interrelationships. This description, often called a hardware design model, allows hardware designers to understand how their components fit into a system architecture and provides to software component designers important information needed for software development and integration. Clear definition of a hardware architecture allows the various traditional engineering disciplines (e.g., electrical and mechanical engineering) to work more effectively together to develop and manufacture new machines, devices and components.
Hardware architecture design is a crucial aspect of the technological landscape that often goes unnoticed by the average consumer. Behind every electronic device and computing system lies a complex hardware architecture that determines its performance, efficiency, and capabilities. For example, In an era where energy efficiency is critical, hardware architecture design aims to reduce power consumption while maintaining performance. By minimizing power usage through smart circuit design and low-power components, devices can achieve longer battery life and reduced environmental impact.
Typically Hardware Architecture is followed by Hardware Engineering similar to Naval Enginnering follows Naval Architecture. The point again here is:
Hardware Architecture Has Very Strong Justification
Computational Architecture
Given a Computer Architecture and Hardware Architecture, the Computational Architecture determines what is possible to compute. For example In computer science, I/O bound refers to a condition in which the time it takes to complete a computation is determined principally by the period spent waiting for input/output operations to be completed, which can be juxtaposed with being CPU bound. This circumstance arises when the rate at which data is requested is slower than the rate it is consumed or, in other words, more time is spent requesting data than processing it.
A great eample of Computational Architecture is in the following news:
Computing the Ninth Dedekind Number using FPGA-Accelerated Supercomputer
The article reveals novel use of Field Programmable Gate Array (FPGA):
To calculate D(9), the scientists used a technique developed by master's thesis advisor Patrick De Causmaecker known as the P-coefficient formula. It provides a way to calculate Dedekind numbers not by counting, but by a very large sum. This allows D(8) to be decoded in just eight minutes on a normal laptop. But, "What takes eight minutes for D(8) becomes hundreds of thousands of years for D(9). Even if you used a large supercomputer exclusively for this task, it would still take many years to complete the calculation," Van Hirtum points out. The main problem is that the number of terms in this formula grows incredibly fast. "In our case, by exploiting symmetries in the formula, we were able to reduce the number of terms to 'only' 5.5*10^18 - an enormous amount. By comparison, the number of grains of sand on Earth is about 7.5*10^18, which is nothing to sneeze at, but for a modern supercomputer, 5.5*10^18 operations are quite manageable," the computer scientist said. The problem: The calculation of these terms on normal processors is slow and also a use of GPUs as currently the fastest hardware accelerator technology for many AI applications is not efficient for this algorithm.
The solution: application-specific hardware using highly specialized and parallel arithmetic units - so-called FPGAs (field programmable gate arrays). Van Hirtum developed an initial prototype for the hardware accelerator and began looking for a supercomputer that had the necessary FPGA cards. In the process, he became aware of the Noctua 2 computer at PC2, which has one of the world's most powerful FPGA systems.
Conclusion: Intimate knowledge of Computer Architecture and Hardware Architecture informs us of the Programming Strategy to achieve certain Computational Goals.
Solution Architecture
With the advent of Cloud (Infrastructure as a Service), Solution Architecture has become a key skill. Just as hardware architecture refers to the identification of a system's physical components and their interrelationships - Solution Architecture refers to the identification of a system's comoutational components and their interrelationships.
Here is a great example:
Amazon Prime Video team throws AWS Serverless under a bus
Amazon Prime Video has dumped its AWS distributed serverless architecture and moved to what it describes as a “monolith” for its video quality analysis team in a move that it said has cut its cloud infrastructure costs 90%. The shift saw the team swap an eclectic array of distributed microservices handling video/audio stream analysis processes for an architecture with all components running inside a single Amazon ECS task instead. Here is the revelation from the Amazon Prime Video team:
As we can see, a cost effective Solution Architecture has become a critical skill which can make or break companies.
Software Architecture
So is there Software Architecture or not? Of course there is Software Architecture! This article bemoans the fact that often Software Architecture is not formally applied with strong justifications.
Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.
The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as the blueprints for the system and the development project, which project management can later use to extrapolate the tasks necessary to be executed by the teams and people involved.
Software architecture is about making fundamental structural choices that are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of the software. There are two fundamental laws in software architecture:
Everything is a trade-off
"Why is more important than how"
Linux Kernel is a great example of Software Architecture. Here are few examples with strong justifications:
Linux Kernel is purposely designed to be Monolithic. This architectural choice was made intentionally by Linus Torvalds, the creator of Linux, to prioritize performance, simplicity, and ease of development. The high performance of monolithic kernels stems from their direct interaction between kernel components, eliminating the need for IPC mechanisms.
Linux Kernel does not use C++. This architectural choice was made intentionally by Linus Torvalds, the creator of Linux, since he is aware of the fact that C++ Language itself is defective (allows undefined behavior) and C++ compilers generate defective or inefficient code. However Linus is quite open to porting Linux Kernel to Rust given the safety properties of Rust code.
What Makes Software Architects Charlatan?
Applying Software Architecture principles to impress or ging by impressions without strong justification. Here is a good example:
To Microservices and Back Again - Why Segment Went Back to a Monolith
In 2013, Segment started with a monolithic architecture. This provided low operational overhead, but lacked environmental isolation. Segment's functionality is based around integrating data from many different providers. In the monolith, problems connecting to one provider destination could have an adverse effect on all destinations and the entire system.
The lack of isolation within the monolith was addressed by moving to microservices, with one worker service per destination. Microservices also improved modularity and visibility throughout the system, allowing the team to easily see queue lengths and identify problem workers. However, microservices came with increased operational overhead and problems around code reuse.
The decision in 2017 to move back to a monolith considered all the trade-offs, including being comfortable with losing the benefits of microservices. The resulting architecture, named Centrifuge, is able to handle billions of messages per day sent to dozens of public APIs. There is now a single code repository, and all destination workers use the same version of the shared library. The larger worker is better able to handle spikes in load. Adding new destinations no longer adds operational overhead, and deployments only take minutes. Most important for the business, they were able to start building new products again. The team felt all these benefits were worth the reduced modularity, environmental isolation, and visibility that came for free with microservices.
In Segments case the strong justification was made apparent over Software Development Lifecycle from the challenges in scaling. In many cases software systems are simply overengineered with architectural styles (such as microservices) or Design Patterns simply due to the fact that such choices will impress Architecture / Design / Code reviewers.
Would you not call such Software Architects Charlatans?
What To Do With These Charlatans?
Ban use of the following phrase:
“Best Practice”
For every Software Architeture decisions these charlatans make, ask for:
Lifecycle Justification
Here is an use case:
You observe a Software Architect has made use of the Visitor Pattern:
Ask the following question:
Will there be different kinds of Visitors over Software Lifecycle?
If the introduction of a new concrete visitor is desired, a new class will be created to implement the Visitor interface, and new implementations for the Visit methods will be provided.A lot of code has to be written to prepare the use of visitors: the visitor class with one abstract method per class, and a accept method per class. This code is tedious and boring to write. If we add a new class, the visitor class needs a new method. Furthermore, it is indeed likely that a new visiting method will need the definition of a new visitor pattern, as seen in point 1. At the least, several patterns have often to be written.
Ask why Visitor Pattern is being used which makes Software Maintenance difficult?
Conclusion:
Without hard Software Lifecycle justifications, Software Architecture decisions often feels like Impressionism:
Beautiful in apperance but practically useless - imagine Architectural Drawings along the line of Impressionism! Any highrise based on Impressionistic Architecture will crumble before opening ceremony.
There Is No Such Thing As Software Engineering
Why is writing software not like engineering? The answer lies in a single fundamental difference with far-reaching ramifications: engineering is constrained by the real, physical world and software is not. While obvious, this is the crucial difference that explains why software development is harder to get right.
Writing software is most similar to writing fiction novels. Writing novels is also an act of creation in an unconstrained and ethereal medium with few well-established construction rules. We know good writing when we see it, but it is hard to teach. Experience writing and feedback from better writers (coders) is the most reliable means of becoming a good writer (coder). Without a well understood process, software will remain more an art than a science. The term "software engineering" is more a goal than how we actually write software.
As we all know Engineerng follows Architecture. So if we agree that there is no Engineering in Software then where does that leave Software Architects??
Is Software Crafting A Scientific Activity?
So if software development is not like engineering, what is it? We call the discipline computer science, but I am not sure that term is completely appropriate either. You may recall the old joke, "If a discipline has 'science' in the title, it probably isn't." In my view, science is about discovering and describing physical phenomena using a scientific method. Merriam-Webster describes the scientific method as:
Principles and procedures for the systematic pursuit of knowledge involving the recognition and formulation of a problem, the collection of data through observation and experiment, and the formulation and testing of hypotheses.
That description smacks of debugging more than the act of writing software. Computer science is about building things like engineering but without the luxury of a toolbox and components taken from the physical world. No one has worked out reliable and effective procedures for building large pieces of software as the engineers have done for physical project. As Alan Kay puts it, software is "engineering of a sort...but just done by brute force".
We do have the fundamental theorem of software engineering (FTSE) is a term originated by Andrew Koenig to describe a remark by Butler Lampson[ attributed to David J. Wheeler:
We can solve any problem by introducing an extra level of indirection
The theorem does not describe an actual theorem that can be proven; rather, it is a general principle for managing complexity through abstraction.
The theorem is often expanded by the humorous clause "…except for the problem of too many levels of indirection," referring to the fact that too many abstractions may create intrinsic complexity issues of their own. For example, the use of protocol layering in computer networks, which today is ubiquitous, has been criticized in ways that are typical of more general disadvantages of abstraction. Here, the adding of extra levels of indirection may cause higher layers to duplicate the functionality of lower layers, leading to inefficiency, and functionality at one layer may need data present only at another layer, which fundamentally violates the goal of separation into different layers.
We conclude unmistakably then that:
Software Crafting is a highly opinionated activity towards an approximation of Computational Architecture
As we learnt earlier in this article, there is a precise definition of Computational Architecture. Software Crafting done in an informal or semi-formal way approximates a stated or unstated Computational Architecture.
Is There A Better Way To Craft Software Than Charlatanism?
A better way to do Software is to base on the following tower:
Software Lifecycle Quality Attributes
Computational Architecture
Hardware Architecture
Computer Architecture
What are Software Lifecycle Quality Attributes? Here is an example:
The Erlang runtime system is designed for systems with these traits:
Distributed
Fault-tolerant
Soft real-time
Highly available, non-stop applications
Hot swapping, where code can be changed without stopping a system
Erlang supports language-level Dynamic Software Updating. To implement this, code is loaded and managed as "module" units; the module is a compilation unit. The system can keep two versions of a module in memory at the same time, and processes can concurrently run code from each. The versions are referred to as the "new" and the "old" version. A process will not move into the new version until it makes an external call to its module.
Only when receiving a message consisting of the atom code_switch
will the loop execute an external call to codeswitch/1 is a preprocessor macro for the current module). If there is a new version of the counter module in memory, then its codeswitch/1 function will be called. The practice of having a specific entry-point into a new version allows the programmer to transform state to what is needed in the newer version.
Successful hot code loading is exacting. Code must be written with care to make use of Erlang's facilities.
Strongly Justified Software Architecture
There are situation where use of Erlang comes with strong justification. In 2009, Jan Koum came up with an idea. What about an internet-based messaging system for the iPhone?
The iPhone was launched in 2007 and the App Store in July 2008. The first version of Android was released in September 2008.
iPhone and Android users could send text messages to each other, but doing so was costly, with charges on a per-text basis. By contrast, the amount of data used for each message was tiny, even in the context of the small data transfer allowances granted to users at the time.
Koum was joined by Brian Acton, who he’d met whilst working at Yahoo!1
Koum and Acton set out to build a system where users could send each other messages using their data allowances. This would dramatically undercut the pricing of the telecoms operators. With dedicated apps on each of the new mobile platforms, they could also build in more features to make using the application more useful and fun.
The underlying software base to power the ‘back end’ of this system was already available in the form of ejabberd. Koum and Acton took the open-source messaging system and adapted it to provide the underpinnings of the product that they envisaged.
So, WhatsApp was born in January 2009.
I leave you there Dear Reader. Don’t be a charlatan or don’t be under the spell of charlatan Software Architect.
I’m no SWE, but no charlatan either, because I listen to the advice, guidance, and wisdom of Soumen Sarkar.