I looked for my own definition to see whether I still agree with myself…. and I find that the only copy available seems to have been translated into Korean.
Clearly from the plethora of definitions the very concept of “Software Architecture” is fuzzy to the point of utter uselessness.
Missing from many of the definitions is the empirical fact of many working systems that lack what they would call a “Software Architecture”.
I suspect a large measure of the confusion arises from overloading multiple meanings on the term.
A lot of folk here actually mean…
That peculiar consistency and homogeneity of Design that would give rise to ease of use and reuse, which is wished for by the Developer who calls himself “The Software Architect”.
The natural implication of which is… that consistency and homogeneity immediately implodes on the appointment of a second Software Architect. :-)
Which is very different from…
Here is an existing vast and complex, mostly working, system. How is it structured? What are its control flows? What are its main data stores and data flows? What is it’s data model? How is it built and deployed? What are the “Happy Paths” through it?
Another source of confusion I have spotted in the definitions is the desire to map Business functionality onto subsystems.
That may be an admirable desire… but seldom is a Good Design. Thus in most well designed working systems business domain functionality may be splattered, for excellent technical implementation reasons, across multiple subsystems.
The compiler and the test team keep a programmer honest. His flaws are soon discovered.
No one and nothing holds a Software Architect accountable.
Architectural documents are 99% irrelevant dreams having no grip on the reality of the code. So the equal degree of fuzziness in what is Software Architecture is no surprise. Until we have a standard exact and daily “round trip engineering” of Architectural Documents to and from the code, we will lack an accurate definition of it.
So far the best definition I have read in this forum so far is… Chris Verhoef’s… “The software architecture of deployed software is determined by those aspects that are the hardest to change.”
Having given one total negative definition let me attack the problem laterally… Software Architecture is the process of reducing coupling and improving cohesion at every level of granularity and from every perspective.
“The one and only criteria for Good Modern System design should be how little you need to read and understand before you can make a good and beneficial change to it.”
No other criteria scales to the mammoth multi megaline monsters we maintain these days.
Also, I have not discovered “connascence” so far. Interesting.
Maybe it does not make sense to talk about some thing called “software architecture”. Instead we should talk about “structural decomposition of systems”, “decision documents”, “behavior descriptions” or whatever else an architect might produce. None of these is necessary to exist when we build large systems although they might help. Maybe what we call “architecture” is just pareidolia.
While it’s not bad going around the definition of what software architecture is, I’d be a lot more interested about what you think a software architect actually does.
Software is ready when it’s shipped and in production. Planning is important, as well as implementation, testing, deployment, maintenance and addressing real-world problems, such as load, latency and others. Iterating on software, following new feature requests or outages is equally so.
I see two main schools of thoughts: companies where engineers own all of the above end-to-end, as these phases are connected. And there are places where architects - who are considered the most experienced engineers - are heavily involved in planning and communication with other teams, but less so in the other parts. I only worked at companies with the first type of setup and would be interested to learn about the latter, which, I assume, the author is more experienced with.
Another interesting area would be to talk about prototyping versus heavyweight planning. With large projects involving many teams and 20-100+ engineers, I have seen the building a quick and dirty prototype “swarming” approach in a few weeks’ time over months of negotiation and document circulation play out quite successfully - this prototype serving as an architectural blueprint for the next phase. The best people I look up to as architects are fantastic prototypers, turning their ideas into code that is easy to reason about.
One reason to write this down is to figure out for myself what a software architect is supposed to do. I do a lot of things at work which I would not consider architecture work.
Example: For the final release certain warnings of our code analysis tool must be fixed or have a deviation record. Currently, I have one or two meetings with one or two engineers to discuss such warnings. It requires some experience to really understand the warnings and find ideas on how to fix them. Once you have a potential fix in mind, the question is if fixing is worth the cost. If you need to redesign central data structures it is probably not since the project is already a lot behind schedule. What I do could be done by any senior developer, but it came to my desk because I already have a role which spans across all the teams. The only aspect which I consider architecture is the central collection of deviation records. This is “shared understanding” and useful to be shared across the project.
I consider prototyping versus heavyweight planning as two possibilities to establish a shared understanding. If you target developers then a prototype is probably great. If other roles are involved (managers, testers, requirements engineers, safety, security, etc) then a prototype of some communication middleware would probably not be helpful.
Here are my thoughts. I’d be curious to know what others think of them?
Perhaps the question of what is Software Architecture can best be considered through what a Software Architect does.
That role (which may or may not be a formal one in a particular Project), makes decisions about how requirements should be implemented in a software solution. In addition, a Software Architect may make decisions about how those requirements are discovered and managed.
In this regard the role can be considered to be the technical complement in a software project of decisions made by a Project Manager, which typically involve those related to the management of scope, units of work over time, milestones, resources, cost, stakeholders and risk.
It is common that these architecture decisions are limited by constraints, which can be typically considered to be already made decisions or requirements which limit the choices of the Software Architect. Examples of constraints include:- functional requirements must be represented as Use Cases; the corporate Oracle database must be used for data persistence; the solution must be be Sarbanes-Oxley compliant etc.
Decisions include those related to both functional and non-functional requirements (subject to constraints). There are a large number of ways functional requirements might be discovered, managed, represented and implemented. A good Software Architect knows the relative merits and deficiencies of different alternatives when applied to differing requirements and circumstances. Likewise, one should know (or delegate to one/those that know) the relative merits and deficiencies of alternative decisions related to non-functional requirements which may include those related to:- maintainability, scalability, reliability, usability, security, compliance etc.
While the Software Architect role may not formally exist in a software project, consider that the role is always actually performed. How such decisions are made, and when they are in a non-trivial undertaking, are directly related to a project’s success.
Given this, perhaps consider that a software architecture is the result of decisions made to meet the software’s requirements and constraints. These results can be considered the software’s architecture.
It might be useful to consider this against another domain …
Consider that a building or bridge architecture is the result of decisions made to meet the structure’s requirements and constraints. These results can be considered the structure’s architecture.
My article intentionally focuses on the software architecture instead of the architect. There are so many things an architect should do that it hardly fits into a blog post. My employer has a 10 page document. An example would be that the architect should influence the organization because Conway’s law.
I would say that the primary role of an architect is to ensure that the software architecture is designed intentionally. The assumption is that an intentional design is better than an emergent architecture with respect to whatever metric the business desires.
Well, that was funky…
I looked for my own definition to see whether I still agree with myself…. and I find that the only copy available seems to have been translated into Korean.
Fortunately the wayback machine exists and produces…
=====================================================================
Clearly from the plethora of definitions the very concept of “Software Architecture” is fuzzy to the point of utter uselessness.
Missing from many of the definitions is the empirical fact of many working systems that lack what they would call a “Software Architecture”.
I suspect a large measure of the confusion arises from overloading multiple meanings on the term.
A lot of folk here actually mean…
The natural implication of which is… that consistency and homogeneity immediately implodes on the appointment of a second Software Architect. :-)
Which is very different from…
Another source of confusion I have spotted in the definitions is the desire to map Business functionality onto subsystems.
That may be an admirable desire… but seldom is a Good Design. Thus in most well designed working systems business domain functionality may be splattered, for excellent technical implementation reasons, across multiple subsystems.
The compiler and the test team keep a programmer honest. His flaws are soon discovered.
No one and nothing holds a Software Architect accountable.
Architectural documents are 99% irrelevant dreams having no grip on the reality of the code. So the equal degree of fuzziness in what is Software Architecture is no surprise. Until we have a standard exact and daily “round trip engineering” of Architectural Documents to and from the code, we will lack an accurate definition of it.
So far the best definition I have read in this forum so far is… Chris Verhoef’s… “The software architecture of deployed software is determined by those aspects that are the hardest to change.”
Having given one total negative definition let me attack the problem laterally… Software Architecture is the process of reducing coupling and improving cohesion at every level of granularity and from every perspective.
=====================================================================
So I wonder, do I still agree with myself?
Mostly I agree with myself… I’d only add….
“The one and only criteria for Good Modern System design should be how little you need to read and understand before you can make a good and beneficial change to it.”
No other criteria scales to the mammoth multi megaline monsters we maintain these days.
Thanks for SEI link.
Also, I have not discovered “connascence” so far. Interesting.
Maybe it does not make sense to talk about some thing called “software architecture”. Instead we should talk about “structural decomposition of systems”, “decision documents”, “behavior descriptions” or whatever else an architect might produce. None of these is necessary to exist when we build large systems although they might help. Maybe what we call “architecture” is just pareidolia.
So often we only view coupling as declaration / reference level coupling….
Once you open your eyes to connascence you start to see what a massive problem it is.
So many Architects will tell you “Reuse is Impossible”… and then when you look at their work, they have introduced connascence everywhere.
https://connascence.io/ is a wonderful resource.
While it’s not bad going around the definition of what software architecture is, I’d be a lot more interested about what you think a software architect actually does.
Software is ready when it’s shipped and in production. Planning is important, as well as implementation, testing, deployment, maintenance and addressing real-world problems, such as load, latency and others. Iterating on software, following new feature requests or outages is equally so.
I see two main schools of thoughts: companies where engineers own all of the above end-to-end, as these phases are connected. And there are places where architects - who are considered the most experienced engineers - are heavily involved in planning and communication with other teams, but less so in the other parts. I only worked at companies with the first type of setup and would be interested to learn about the latter, which, I assume, the author is more experienced with.
Another interesting area would be to talk about prototyping versus heavyweight planning. With large projects involving many teams and 20-100+ engineers, I have seen the building a quick and dirty prototype “swarming” approach in a few weeks’ time over months of negotiation and document circulation play out quite successfully - this prototype serving as an architectural blueprint for the next phase. The best people I look up to as architects are fantastic prototypers, turning their ideas into code that is easy to reason about.
One reason to write this down is to figure out for myself what a software architect is supposed to do. I do a lot of things at work which I would not consider architecture work.
Example: For the final release certain warnings of our code analysis tool must be fixed or have a deviation record. Currently, I have one or two meetings with one or two engineers to discuss such warnings. It requires some experience to really understand the warnings and find ideas on how to fix them. Once you have a potential fix in mind, the question is if fixing is worth the cost. If you need to redesign central data structures it is probably not since the project is already a lot behind schedule. What I do could be done by any senior developer, but it came to my desk because I already have a role which spans across all the teams. The only aspect which I consider architecture is the central collection of deviation records. This is “shared understanding” and useful to be shared across the project.
I consider prototyping versus heavyweight planning as two possibilities to establish a shared understanding. If you target developers then a prototype is probably great. If other roles are involved (managers, testers, requirements engineers, safety, security, etc) then a prototype of some communication middleware would probably not be helpful.
Here are my thoughts. I’d be curious to know what others think of them?
Perhaps the question of what is Software Architecture can best be considered through what a Software Architect does.
That role (which may or may not be a formal one in a particular Project), makes decisions about how requirements should be implemented in a software solution. In addition, a Software Architect may make decisions about how those requirements are discovered and managed.
In this regard the role can be considered to be the technical complement in a software project of decisions made by a Project Manager, which typically involve those related to the management of scope, units of work over time, milestones, resources, cost, stakeholders and risk.
It is common that these architecture decisions are limited by constraints, which can be typically considered to be already made decisions or requirements which limit the choices of the Software Architect. Examples of constraints include:- functional requirements must be represented as Use Cases; the corporate Oracle database must be used for data persistence; the solution must be be Sarbanes-Oxley compliant etc.
Decisions include those related to both functional and non-functional requirements (subject to constraints). There are a large number of ways functional requirements might be discovered, managed, represented and implemented. A good Software Architect knows the relative merits and deficiencies of different alternatives when applied to differing requirements and circumstances. Likewise, one should know (or delegate to one/those that know) the relative merits and deficiencies of alternative decisions related to non-functional requirements which may include those related to:- maintainability, scalability, reliability, usability, security, compliance etc.
While the Software Architect role may not formally exist in a software project, consider that the role is always actually performed. How such decisions are made, and when they are in a non-trivial undertaking, are directly related to a project’s success.
Given this, perhaps consider that a software architecture is the result of decisions made to meet the software’s requirements and constraints. These results can be considered the software’s architecture.
It might be useful to consider this against another domain …
Consider that a building or bridge architecture is the result of decisions made to meet the structure’s requirements and constraints. These results can be considered the structure’s architecture.
My article intentionally focuses on the software architecture instead of the architect. There are so many things an architect should do that it hardly fits into a blog post. My employer has a 10 page document. An example would be that the architect should influence the organization because Conway’s law.
I would say that the primary role of an architect is to ensure that the software architecture is designed intentionally. The assumption is that an intentional design is better than an emergent architecture with respect to whatever metric the business desires.