The software industry seems to be now a bit obsessed with what is called ‘Software Architecture’, although there is no clear consensus on what it is, what it represents, and how it is practiced. Not long ago, I read the article “Software Architecture: it might not be what you think it is”, where the authors seek to advance on the definition of Software Architecture, from the point of view of the decision making process when evolving software systems. The term Software Architecture has gone through some redefinitions in the last 30 years, and it is still debated today. Perhaps one of the main problems is the word ‘Architecture’: it lays down a basic framework of ideas, based on the analogy with the discipline of Architecture, although there is nothing of such discipline in Software Architecture, which may seem then that we are dealing with a very specific myth¹.
In the context of agile development, software architecture is often considered unwanted. The common view is that agile practices are too dynamic for something as static and slow as the practice of software architecture, and it is also a reminder of a period that was too bureaucratic regarding software development processes. The agile manifesto is ambiguous enough to be misinterpreted, even more if professionals are not acquainted or concerned with the different levels of abstraction that a software system can present. The agile community has indeed tried to build software in a short-sighted way, giving preeminence to individuals and interactions, working software and responding to change instead of any kind of planning, documentation or processes. On the other hand, the definition of ‘software architecture’ is also ambiguous, riddled with problems and even professionals do not agree on their basic principles².
Architecture, on the other hand, has a very well defined set of principles, which have evolved through history, a project is always based on processes, there is a plan (and a planning) and there is extensive documentation. When software practitioners, speaking about software architecture, recall the saying “the map is not the territory”, it is just a sign that Architecture (the one about buildings), as a discipline, has not been understood for what it is; it just shows a lack of understanding on what Architecture is about. And yet it is true, software with poor ‘architecture’ breaks often and is hard to maintain; but I would rather use the word structure, or design. Badly structured or designed software breaks. Some professionals in the software industry hope that there might be a middle ground between these two attitudes, the lack of interest in software architecture by committee and just bad architecture. But I don’t think there is a middle ground between these two poles of ‘pointlessness’, because they might not be on the same ‘axis’, or on the same ‘dimension’. The ‘valueless meetings and irrelevant documentation’ of design by committee finds its opposite in ‘valuable meetings and relevant documentation’. The opposite of ‘poor architecture’ is good architecture. But poor design can emerge from valuable meetings and extensive and relevant documentation, and good design can be done through valueless meetings and put into irrelevant documentation. The point is: documentation and meetings might be irrelevant and lack value to some people, to some others not. If we have this kind of atmosphere in our profession, it is probably because there is no real consensus on the processes and knowledge we deal with. It might be that we are just designing software systems, because there is no architecture, just design, in a discipline that is fundamentally different from Architecture. As a new discipline, Software does not need to desperately find analogies in any other human activity.
The word ‘architecture’ is, indeed, an inappropriate analogy for building software systems. It could work, to some degree, as a metaphor, but never as an analogy. Software is not like buildings, their fundamentals are totally different. As soon as we take a look at how software behaves and is written, and how buildings are planned and executed, all analogies are gone. The worst analogy is that of the floor plan: many professionals think that a floor plan for a building ‘tells’ the architecture of the building, and so in the same way we draw ‘structure diagrams’, and that has to be the architecture of our software system. A floor plan is not architecture, it is just a floor plan, one of many, many, documents an architect must produce in order construct a building. Likewise, a ‘structure diagram’ for a specific view of a software system is just one of the many documents a software designer can produce³.
It is argued sometimes that one problem with the ‘architecture’ metaphor is that buildings are static, and software is dynamic. But this is not true, buildings are not static, and the work of an architect is not done just once. It is also not true that software, by nature, is dynamic in its writing and structure. Buildings evolve over time, they decay, they suffer from changes in internal distribution, usage, and structure. A building is not the same now and a 100 years from now. The problem is that the time scale of buildings is measured in years or decades (but could also be in months), due to the very physical nature of buildings. Software, on the contrary, is just text. But software can also be ‘freezed’ for centuries: the software loaded into a machine that never gets an update is such an example. We, as human beings, build our language based on metaphors, and for our new invention, Software, there are no good metaphors.
Of course, going back to the origin of things, to how they are defined, gives clarity to our thoughts. Indeed, etymologically speaking, the word ‘architect’ comes from ancient Greek and means ‘principal builder’ (supposedly the one guiding the construction of a building). But architecture is not ‘created’ by people building things, Architecture is a discipline that historically has had its only focus on constructing buildings for human beings, it is a human activity deeply related to the city, to the political life of societies, to sociology and philosophy. That sense of ‘building’, of ‘creating’ something (a building) hasn’t been lost, it just got more complex over the centuries. The problem, again, with the metaphor of the ‘architect’, is that people often think as an architect as someone how makes a collection of drawings about a building, completely disconnected from the real act of constructing it. But any architect, at least to a basic understanding, has to know about structural engineering, heating, heat transfer, different materials and their properties, even furniture design, and anything that goes into constructing a building. Design and building are not separated, because the architect must clearly draw everything so other people can execute the plan. This biased idea about the detachment of planning and construction is the one that the software industry used. If one only sees a floor plan, that’s not even half of the whole documentation an architect must hand to a construction company or their clients. In Architecture, just as in software, the way something is built directly affects what is built, and vice versa. The software industry took the naive idea that an architect just draws floor plans, together with a very narrow etymological definition of the word ‘architecture’, and defined its own term (software architecture), and in the way forgot about all the history of Architecture, the evolution of its theory, the treatises produced since the Renaissance, the discussion about aesthetics, space and form, its sociological and political implications, its ties to philosophy and cultural theory…
The building analogy has made a lot of damage to the software industry. Some (or maybe, too many) software ‘architects’ focused too much on specific structures and behaviors: ‘structure’ having a complete different set of fundamentals in Architecture and in Software, behaviors not having a direct translation to Architecture. Some professionals argue that in order to properly document the structure and behavior of a software system, the decisions and rationale behind every important aspect of the system must be documented, for example using ADRs (Architectural Decision Records). Structure and behavior are indeed the result of a though process, but here lies an important difference between a software system and a building: there is no need for any kind of explanation about why a building is built in this or that way, as long as the building follows some basic principles of Architecture⁴. On the contrary, since there are no ‘basic principles of software systems’, one needs to see the ‘why’, read the explanations, about why a software system is the way it is. I say ‘basic principles of software systems’ and not ‘basic principles of computation’ since the latter are pretty well defined. But a software system is something that humanity has not seen before: there are no direct analogies or metaphors, there is no one human activity that closely resembles the construction of software systems⁵. The current state of academia focuses on how a system computes (processes information), or how a system is ‘engineered’ (how to efficiently and optimally reach a solution). But there is no consensus on how to correctly design and structure a software system⁶. In this regard, it would be really beneficial for software teams and companies to document the motivation behind each design and structure decision when building software⁷.
The lack of documenting the design decisions cannot be attributed, in any case, to the nature of those decisions. In Software, like in any other creative field, each decision is a compromise between competing alternatives. It is the same in Architecture, civil engineering, industrial design and any other design or engineering related field. But in Software it is not clear when a decision is ‘architectural’, ‘structural’, or just a programming decision: I would say that most of the time decisions are not documented because the people that make those decisions do not know how to frame the decision, that is, don’t know which context to apply⁸. But this is not people’s inability to frame a decision into context, but the lack of fundamentals in Software that may guide programmers and software designers to know in which context a decision is operating⁹. If one has to document every decision that deems important (and it is then a purely subjective effort), and has to constantly apply experience (which again is highly subjective), then any two randomly taken software professionals would hardly agree on how to design a system. That, at least to me, means that there is no clear guide on how to do work. It is only craft. The discipline of Architecture, on the contrary, has strict and clear guides on how to solve problems and address certain situations, and sill leaves room to the architect to be creative. Given two randomly taken architects, they will apply the same knowledge and the same criteria to solve the already known problems, while designing something completely different based on their creativity and cultural background: there is no need for them to ‘write down’ an explanation for the decisions they made, those ‘why’s are codified into the building.
“Architects should write code” is a common saying nowadays. I find some trouble with this way of thinking. On the one hand, if one takes the ‘Software as a building’ analogy, then this is like asking an architect to lay bricks at a construction site, or to install a heating or sewage system herself or himself. That is just not an architect’s duty. On the other hand, if one just drops the analogy and recognizes that buildings and software are completely different things, then one also has to drop the word ‘architect’, drop the role of ‘Architect’, and think of teams of developers with varying degrees of expertise when building a software system. The phrase ‘Architects should write code’ is completely meaningless and cannot hold any value of truth. But something similar occurs when we say that ‘software architects’ must still be developers: if one thinks of being a developer as having the competence of developing software, then a ‘software architect’ will never cease to be one (unless one can become a software architect without never ever having been a developer…). But if one thinks as being a developer and a software architect, then we are thinking about roles: one designs the system, the other develops it. But here again we face the problem of the ‘Software as a building’ analogy, and in that case maybe it is better to just drop the analogy and the word ‘architecture’ and any related word to it. The way software is built is just not the way an Architect plans a house. Software is different from buildings, it demands then a complete different set of competencies to develop. The mere act of writing code creates the structure of a system, so when is someone ‘designing’ the software or just ‘building’ it?
If the analogy of Software as a building (or a city, or a garden…) is not representative of what Software really is, then any use of any word related to ‘architecture’ is missing the point. One could not use the word ‘architect’ to designate the person building a software system as an analogy to the person designing, for instance, a house or a hospital. One could not use either the verb ‘to architect’ since this is nonexistent in the traditional sense. Again, the problem is that Architecture is a discipline, a field of study, not a synonym of structure or processes. The majority of the time, the word ‘architecture’ is used in the software field to designate the structure of a system and all related tasks regarding the analysis of such system and its quality attributes. Here is exactly where the analogy breaks: the architecture of a building is not its floor plan, nor its quality attributes, it is all that and much more, comprising the construction style, the historical moment, the distribution of spaces, the way it fits in the city, the meaning and intention of it, the realization of an idea related to society, the building itself. None of these attributes and characteristics are present in software. A building does not have ‘an architecture’, a building is architecture¹⁰. Software is different, has other concerns, other uses, other qualities. The idea of software being similar to a building is so pervasive that a great deal of books on software architecture have a building or architectural element in the front cover… as if there were no good representations of actual ‘software architecture’ to illustrate the front cover of a book (and desperately we need to call for help to Mother Architecture)¹¹.
The usage of the title Software Architect just misses the point of what Software is, and confounds the industry practitioners. Due to the nature of software, it is software developers who shape the design and structure of software systems. In this regard, it is said that developers are the ones already doing ‘architectural’ work. But what is ‘architectural’ work, anyway? As noted before, ‘architecture’ in software is normally though of as focusing on structure and quality attributes, like scalability, performance, security, maintainability, and so on. But these concerns have already a name: engineering, and that name fits perfectly, since engineering is the activity of creating optimal solutions to a problem. Structure, on the other hand, is a concern in itself that either emerges from designing a system or is planned beforehand under the constraints of other requirements. Structure and engineering go hand in hand, and any software can be successfully described in terms of its structure and engineering capabilities¹². It is worth noting that ‘structure’ is defined as _the way in which the parts of something are connected together, arranged or organized…_, and so a definition like ‘a higher-level abstraction of a software system’ or ‘the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them’ are just a rephrasing of the definition of ‘structure’, but do not add anything meaningful outside the concepts of ‘arrangement’, ‘connectivity’ or ‘organization’. In this regard, the word Architecture cannot be loosely applied to other disciplines, simply because its meaning is tied to a very specific activity that gave its name. Furthermore, the meaning of Architecture evolved through the years, since its first uses of the word, every time theorists analyzed the concepts behind the discipline of architecture. Using the word Architecture to denote anything beyond the discipline itself is like using the word Medicine to define things in a field completely different from it, no one would take it seriously. ‘Architecture’ is not a thing that can be pointed at, or named, it is a discipline, it is a complex human activity. It is rather strange that the meaning of the word ‘Architecture’ has been and it is been constantly thought of and redefined inside its own discipline, but defined in just three sentences in the software industry, and then it almost immediately finding consensus, even if it is a very flawed definition¹³. There is a considerably amount of publications using the word ‘architecture’ in the context of software, but almost every time the word is defined it is just a repetition of a very poorly defined concept from 30 years ago. It is also worth noting that the word ‘architecture’ used in the context of software is just a redefinition of ‘structure’, or ‘design’, but nothing more.
But Architecture is something else. Unless, of course, one wants to redefine the term and strip it of all real meaning just to use it in a different field of knowledge. I wonder why would anyone want to do that.
Some authors refer to Software Architecture as the set of decisions that produce a software system, but then we would be using a narrow definition of the term, and we might find several problems operating with such definition. First, using this definition reinforces the myth of Software Architecture, it takes the term (Architecture) even further away from its original meaning. Then there is the problem of the lack of a unifying vision: if the decisions are important, then the a priori idea or sketch of the systems is of lesser importance, and the system, being the result of a chain of individual decisions, cannot be taken into account as a whole, but only a posteriori. Since the analysis of the qualities of the software must be done a posteriori (because the focus is on the decisions taken, and decisions can only be accounted for a posteriori), the system might or might not accomplish a certain level of quality or excellence. It could be argued, though, that the decisions are taken before the actual system is built, and the resulting design (the result of such decisions) is tested against a desired level of excellence or quality, but this is just design process, there is no need for a new name for that activity, and the process itself would be called ‘software design’¹⁴.
Then there is the problem of the ‘locality’ of such decisions: since each decision taken when building software affects that specific software being built, its context and requirements are, so to say, ‘local’ to that specific project or software. Thus the chain (or body) of decisions are taken in a ‘local’ or ‘specific’ context, which makes it really difficult to transfer to other scenarios, thus rendering almost useless the lessons learned (the information acquired about how to solve certain problems in certain scenario), and requiring subjective experience and even more decisions to apply that knowledge to other systems or contexts. This means, a body of knowledge is built, that is hardly or no transferable, and by that, non comparable (one could hardly or not at all compare two systems, since one would have to compare its decisions, which are specific and ‘local’).
In turn, this approach does not account for a place, a discipline, to discuss structure and form of software in a generic and theoretical way. If Software Architecture is about decisions, and decisions are always specific to the problem at hand, and the knowledge built by those decisions cannot be transferred from one system to another, then there must be some other discipline that we could use to reason about software systems in a more general way. If that discipline is Software Engineering, which looks at the fundamentals of software systems (since Software Architecture does not look at fundamentals because it focuses on specific decisions of specific systems), then applying Software Engineering through a design process would yield the same actions as Software Architecture; in this case, either Software Architecture is just a re-naming of design, or there are some other software fundamentals that must be addressed somehow (and probably Software Architecture is where that should happen). Yet another problem with Software Architecture as a set of decisions is that there is no systematized way to transfer knowledge to other practitioners or to teach to new ‘architects’, since many or almost all decisions during a project are based on specific context and prior experience.
The above means that ‘Software Architecture’ is heavily based on experience, which means that it cannot elevate as an autonomous body of knowledge, that can be ‘detached’ from its ‘experienced’ practitioners. In this regard, one sees some parallelism with oral architectural tradition during the Gothic period¹⁵.
The use of the word ‘architecture’ in the context of software is, indeed, too vague, meaning different things in similar contexts or similar things in different context. Often times the concepts of ‘monolithic architecture’, ‘service oriented architecture’ or ‘layered architecture’ are used. Here, the definition of ‘architecture’ seems inconsistent, since it is defining a type of deployment in one case (monolithic and service oriented) but a way of organizing code on the other (layered architecture). The word ‘architecture’, used to describe the components and their arrangement (this is actually the definition of ‘structure’), fails to correctly name two different things, since in one case is referring to software delivery techniques, but in the other a technique for organizing code. Furthermore, a ‘monolithic architecture’ could be organized, at the code level, in a ‘layered architecture’, and so we could not use the word architecture in such a system, because of its ambiguity. To me, these concepts are not ‘architectures’, but a typology: a collection of types of, for example, deployment structures, code structures, component structures. Architecture, in the traditional sense, refers to the practice of constructing buildings as well as the building as a whole, from concept to product, but never to the structure or ‘form’ of a building. Similarly, one could imagine a discipline that accounts for all aspects of Software, from the perspective of human beings, not machines: Software Engineering will (probably) always deal with efficient solutions and for that, it has to be a discipline that is measurable in all aspects, and thus it always has to do with machines. Buy Software is written by humans, for humans. Software Engineering is just one aspect of Software.
I am not saying that there are no inherent problems in appreciating and analyzing software systems, or that software systems are not as complex as buildings, or that the Software discipline is inferior to Architecture. What I am saying is that Architecture is so different from Software that any comparison, analogy or metaphor is useless and meaningless. But at the same time, I do believe that Software has its own fundamentals, and those fundamentals are completely different from any other knowledge discipline or human activity. And I say ‘believe’ because I have the impression that we do not fully comprehend those fundamentals yet. The industry and the academia seemed to become so obsessed with using the word ‘architecture’, so obsessed with the analogy of buildings, that it forgot to look at software from other perspectives. Are there principles behind the way we think about problems and the way the transfer them into code? Can software be though of as a gradient of structures, or are there clear boundaries in structures, regardless the way we split a system? How does the psychology of a software developer affect the structure of a system? As software is described in text, could it be analyzed from the perspective of reception theory?
We may certainly bring knowledge from Architecture into Software, but there is no need to imitate or copy. For example, Aldo Rossi’s theory of the city can bring light into how software evolves, without necessarily comparing a software system to a city. Christopher Alexander’s book on patterns can inspire a similar way of building software, without actually comparing buildings to software. Vitruvius’ idea about the practicing architect can be though of as a metaphor for the software designer involved in the coding process, and Sebastiano Serlio’s treatise or Ernst Neufert’s Architects’ Data might inspire a body of knowledge for all software designers.
What would be interesting, though, is to have a theory of Software, a body of knowledge, of methods, that helps us understand software using reason and experiments. Software engineering is already there to help us create our systems based on efficiency and constraints, a theory of computation is already in place for thinking about algorithms, but we lack a way to reason about and analyze the structures of our software systems in a reliable and repeatable way, based on principles of reason and science, not just definitions from disciplines that are worlds apart, or pure subjective experience. A theory of software would deal with the inter-relationships between code and the different levels of abstraction and structures, the execution of a system, the role of subjectivity in developers and other stakeholders, and the impact of software on society.
Notes
[1] The idea of Software Architecture as myth, that strips all meaning from the word ‘Architecture’, can be analyzed from the definition of myth by Roland Barthes (Roland Barthes, Mythologies, 2013, Hill and Wang).
[2] Even the ‘basic principles’ of software architecture are ambiguous and highly subjective, to the extent that the books written on software architecture dispatch its definition in a couple of short paragraphs, and concentrate the majority of its contents on explaining techniques to ‘build’ or ‘reason’ about such architecture. But there is almost no explanation, discussion, analysis, or rebuttal of any fundamental or principle.
[3] This might actually be one of the few analogies between the two disciplines: the idea the in Architecture there is one person (or a studio) that has to produce a considerable amount of documents in order to command the construction of a building, likewise, in Software, a person or a team must produce a considerable amount of documents to build and operate a system.
[4] The ‘basic principles of architecture’ vary over time, and each artistic period throughout history has a slightly different set of principles. One has to understand that these principles are not laws (in the scientific sense), or physical principles, but agreements at a cultural level. The consensus is that Architecture deals with spaces that are inhabited by human beings, and to accomplish this it makes use of specific techniques, materials and methods. This discussion, about ‘what Architecture is about’ started taking place during the Renaissance, but the general form of such principles of architecture remain: a building has to fulfill a purpose, has to please the eye, and has to stand firm. It would be incorrect, though, to reference Vitruvius’ treatise (De Architectura), and specifically his so called ‘triad’, firmitas, utilitas, venustas, as a definition of architecture or must-have qualities of a building.
[5] It is possible some kind of far fetched analogy to the mega-machine described by Mumford, which consisted somehow of code (law) and a machine that executed the code (the slave population). See Lewis Mumford, The myth of the machine.
[6] Could it be because the appreciation and analysis of structures is highly subjective if we go outside the realm of network analysis? Software can and it has been seen through the prism of network analysis, but has that perspective really informed the industry and academia in a better way? Why is it that any graduate, after 5 years of software engineering, is not guaranteed to know exactly how to build a mid-sized system? Why would two different graduates from software engineering build the same system in a complete different way?
[7] It is actually not true that there is no need to explain certain architectural decisions in Architecture, but good decisions are normally codified either in consistent engineering solutions or consistent visual languages, or both. The idea that an architect does not have to explain the rationale for his or her decisions is based on the ‘experience’ resulting from the building, something that is completely nonexistent in Software (except if we think of usability of source code or software tools, but ‘experience’ in Architecture and ‘usability’ in Software are not comparable).
[8] Assuming that people are willing to document the software they design and produce. Documenting software is a huge topic, involving problems in logistics (where and how to store the documentation), writing style, outdated information, and probably the core problem: documentation and code are two separate entities (even if the documentation is written in the code).
[9] If that would be the case, that there are clear fundamentals in Software, then I would hope for these fundamentals to be taught at University, and software professionals with a Masters degree in Software would all of them apply the same criteria, analysis and tools to any and every software problem out there. But this is not the case.
[10] The verb architector (latin) means ‘to build, to construct, to procure, to invent’. Then the word architectura (latin) would mean ‘what is built’.
[11] Indeed, there is no ‘image’ that represents software. The only way of representing software through images is to draw diagrams of the (arbitrary) different ways of de-constructing software.
[12] Until the late 80s, there is almost no reference of ‘software architecture’ in the literature, and all the same concerns that are now attributed to it, where then attributed to software engineering and software design. Most probably, the tipping point came when Object-Oriented software design came to prominence, since apparently as Object-Oriented design took hold of the concept of designing code, there was no way to refer to the idea of ‘designing’ whole systems. So the idea of ‘architectural level’ began to be used to speak about whole systems design (Mary Shaw, Toward higher-level abstractions for software systems, 1990).
[13] I might need to apologize here for the rant, and indeed the concept of ‘software architecture’ is under discussion nowadays, but its core meaning and applicability are not put in doubt. It keeps its hollow meaning about structure, or decisions, or intent. The discussion mostly revolves on the idea of how to solve past failures and delusions, not on questioning the very nature of software, it refuses to abandon Architecture as a role model, and keeps bringing metaphors and analogies from it. As far as I know, no one yet asked: why ‘architecture’ ?
[14] Such process was indeed called Software Design. Some author used the term Software Design to talk about the partitioning and coding of the system, while using the term Software Engineering to deal with data flow and design, execution environments and quality attributes.
[15] For a brief account of the nature of architectural knowledge transmission during the Gothic period, see Mario Carpo, Architecture in the Age of Printing: Orality, Writing, Typography, and Printed Images in the History of Architectural Theory (The MIT Press, 2007)