> Architecture is the relationships between systems
I find that somewhat limited. A part of architecture “can be” the relationship between systems. As with anything expressing relationships, representing them using diagrams is helpful. Given the textual nature of our tools, storage and change systems, I like the idea that a diagram is based on code. However, it’s no panacea, as future maintainers still need to understand and learn the syntax and rules of that diagramming code. Can code and diagram changes be automated? I suggest no.
I prefer to think that software architecture is the set of decisions made about how to implement the functional and non-functional requirements of a project.
Diagrams capture and represent abstract and/or high level concepts. Their goal is to provide a kind of mental map of how specific aspects of a project are organized in order to help developers form their mental models. This means placing the focus on key constructs and downplaying the importance or relevance of other components. There isn't an objective way to provide a one-to-one mapping between what bits of a software project are of critical importance to form mental models, and what bits are irrelevant.
> IMNSHO, the reason is that we don't have a way to express architecture in or as code.
Not true. We have more than plenty of ways to represent software architectures. That is trivial and a solved problem. So is mapping representations of software architectures to (some) source code, at least in the form of skeleton code. The problem lies in mapping software projects to a software architecture, even when the software project is clean and a textbook example of a very specific software architecture.
> I dunno, I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation.
I think this is the one mandatory part of software architecture which is giving developers information to help them make their own design decisions without constantly deferring to the authority.
But the exact place where architecture ends and development starts varies a lot.
I like to think that architecture itself decides what is important from the architecture standpoint. If architecture decides a certain low level application detail is important, then it becomes an architecture detail.
In fact, in most organisation architecture controls at the very least some top level design like components, communication patterns, APIs and technology in use.
In some organisation architecture goes as far as individual classes. Not all classes, but maybe classes modelling the domain of the problem especially, if that model is used as a language for multiple project or even implemented as a shared artifact.
I think C4 is suitable for those organisations where architecture is concerned with more low level structure than just listing applications and their integration interfaces.
> The biggest problem I've seen with architecture diagrams is they fall out of sync with the code base. In my opinion, automatic generation of these diagrams is necessary.
Architecture diagrams document how the software is expected to be organized. They represent the goal, not the current state. The code needs to comply with the diagram, and not the other way around.
The only scenario where it makes sense to generate diagrams from code is when we have people trying to onboard to a project that's not documented, and even then these diagrams are only generated once, polished to remove noise, and from that point onward serve as the reference.
> You generally can’t auto-generate useful [architecture diagrams] from code,
The question is: why is this the case?
IMNSHO, the reason is that we don't have a way to express architecture in or as code. Instead, we have to compile the actual architecture of the system into one that is expressible using the call/return architectural style that our programming languages support.
That's a lossy process.
When we can program with actual architectural connectors, auto-generating useful architectural diagrams becomes trivial.
> Really you have little choice in how to do things as the current structure dictates your options.
I really like this framing. The architecture of the code should reflect the flexible and rigid parts of the domain, and how they interact. A good design will let small changes in the domain become small changes in the codebase -- and large changes in the domain will at least not be arbitrarily larger in the codebase.
Software architecture feels like a very code-centric and technical thing -- and it's not like it isn't, exactly -- but it's really driven by a solid understanding of the system into which the software will be placed. Often, the pre-existing system is a bunch of humans, and people who previously interacted with humans will now interact with software. Also often, the pre-existing system is some mix of humans and software. And even if the pre-existing system is pure software, some of the internal or external boundaries will undoubtedly shift.
> But it’s really challenging reaching that point.
We as a profession need to acknowledge that not everything is "solved" by software, and that we really need people with design experience, human factors experience, and the ability to distill the domain into something that can be addressed by software engineering. I think "reaching that point" is predominantly led by these factors, and not technical excellence in the strict sense.
> This is like saying only carpenters should be able to design houses
No, it's really not. For that analogy to work, architecture (house design) would have to be a skill best learnt via carpentry (i.e. hands-on house building), when there's pretty clearly minimal connection. If there were, we'd see many successful architects who'd started in the building trades, just as we DO see many developers rise up through the ranks to become seasoned veterans capable of architecting complex systems.
The thing is, most software system requirements could be translated into many proposed alternate architectures (decompositions, inter-module interface definitions, technology choices, etc, etc). They may all look viable on the white board, but it takes years of experience to understand what works and what doesn't - what the consequences of those design choices are, and how they will impact development, debugging, operational support, future changes/extensions, etc.
> So I guess one could ask, why should it be any different in software?
Since the software world does not generally work this way, we could also ask why the architect/brick layer model should be applied in this world. The decider/implementer model might be a common organizing principle in other industries; that does not mean that it's useful to software.
Brick layers cannot manipulate more than small chunks of a building at a time. Software engineers in contrast can perform the equivalent of turning the Empire State Building on its head.
Software architecture is difficult to get right and too important to leave to one or two senior folks who may or may not have the insight required to make the right decisions.
> how can you possibly formulate a consistent and sensible architecture?
Similar arguments could be made about actual architecture: "If you can't have well-designed and consistent houses, how can you possibly have a well-designed city?"
The best architectures I've seen, by far, had the worst code. Code is not a systemic level issue. The way the pieces fit together is.
A sad fact of good architectures is they actually enable bad code to exist without severe consequences, because that badness is localized.
I have recently had the thought that this is mostly what software architecture is...at some level.
It's about where we draw the boundaries around code to make it easy for humans to understand.
Imagine taking an existing repo, and extracting every block of code into a function, and then moving them into their own separate file in one big folder. You could extend it to all the libraries of your code, and of those services we communicate with over the network too.
This would look a bit like a debugger symbol table. It's closer to how the computer understands the program.
The app still runs. It's just hard for people to understand what is going on.
Software architecture is simply the grouping of these functions to some extent.
It's not a foolproof analogy, because there are some decisions to be made about implementation details of things, but at some level of abstraction you would find the same operations need to be run.
Just an interesting thought.
> The question of how to architect such software is still an open one.
I find a problem we face with architecture discussions is that its always about tradeoffs that are not immediately apparent.
And it takes a lot of mental effort to remember why something is a bad idea.
The way we discuss it is limited by plain text. It's hard to demonstrate a system evolving over time in a concise manner.
Architecture should be evaluated by throwing a spec at it, and then changing every part of the spec (including adding perf requirements) and seeing how long it takes to make the changes, and how many bugs it has.
> and everything seems like it was written by a beginner.
So many developers are afraid of their code being described that way. People are weird.
I'm starting to have the opinion that you shouldn't give software architects the title of software architect because they'll feel as if they're not doing their job if things are simple rather than architecty.
I say that because a software architect is really just a developer with broad scope, but I suspect most of the software architects I know would be offended by that description (I myself hold the title software architect).
> it is the exact kind of architectural choice you're saying one should decide on.
While I can't speak to what the OP had in mind, architectural concerns are definitely not inside a function. Even connecting individual functions/procedures barely registers at the smallest, most granular scale of architecture.
Of course, our programming languages for the most part don't let us express architectural concerns...so here we are.
> Connectors are what really matter when it comes to de-risking a project.
Yes, they define the architectural style and thus what architectures you can build.
This is getting more and more important because the default architectural style of the vast bulk of our programming languages, call/return, is unsuited for build most of the types of systems we are trying to build.
> Components aren’t all that interesting.
Yes and no. The architecture is defined by the connectors, but in day-to-day programming, your functionality is going to be mostly in the components.
> And at any scale I think about in my work, there’s components and connectors
Yes.
Which is why I created an architecture-oriented programming language that lets you deal with components and connectors
> I think one of the major reasons that all these massive software companies grind to a halt with innovation is because of bad software architecture and a bad choice of programming language contributes to that.
I see social structures having far more influence on architecture than any underlying technical details so I feel your thesis is built on false premise
> I can't help to think that no software project is ever going to so neatly conform to having a structure imposed upon it
That's the problem with prescribing an architecture ahead of time. That's why you learn the basics and improvise/draw on established architectures as the project evolves.
"[architecture is] about knowing that you need a bathroom near the dining room, or that a flat roof doesn't work where you get a lot of heavy snow, or using a database to hold what is essentially log data, or encryption as a part of the data structure layout. I always think 'systems analysis' rather than 'software architecture.'"
And I would argue that I expect every member of the dev team to be able to realize those things. Perhaps not right away (you're not birthed from the womb knowing proper database indexing) but absolutely as a person moves up the developer ladder they are expected to know and implement proper architecture.
_Not_ expecting those things merely turns a developer into a fancy sort of typist that does exactly what they're told (implement this spec). And it's been my experience that those sorts of programmers (and the companies that birth them) produce pretty boring, uninspired, miserable to use products.
> ...you draw architectural diagrams. ...Which allows us to interpret the high level architectural diagram to a low level program, by telling what exactly the nodes and arrows do
This is not a new idea at all - I'm strongly reminded of the whole Model Driven Architecture brouhaha back in the 1990s and early 2000s. Needless to say, it didn't work. You can't do "code generation" from a high-level architectural diagram and expect to end up with a functioning system! At best, if you really do it right, the high-level design might enable you to specify type-like properties that constrain the low-level implementation in a broadly helpful way[1]. But you still have to write all the low-level code!
[1] And this is in actuality incredibly optimistic - MDA and UML didn't even manage that! Instead, all the pretty diagrams (1) were inherently fuzzy, so they did not embody any actual constraints on the implementation, and (2) even in the best of cases, got immediately out of sync with the ground-level truth of the actual implementation.
> I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.
I concur with the spirit of this gripe. While architecture certainly might be ripe for fruitful parallels, I think it might be over-emphasized because most discourse is derivative regurgitation. Most people are not generating original insights from their own experiences, but regurgitating (at best mildly extending) Christopher Alexander (or other derived work). Christopher Alexander tied to mine architecture for systems metaphors (because that was his background), and a group of software folks back in the day tried to map that to software development -- in other words, a lot of it was purely incidental. And they were all barely scratching the surface; there are likely many other fields with many other interesting analogies. Fresh perspectives that try to mine new lessons (from different domains) would be really interesting.
I find that somewhat limited. A part of architecture “can be” the relationship between systems. As with anything expressing relationships, representing them using diagrams is helpful. Given the textual nature of our tools, storage and change systems, I like the idea that a diagram is based on code. However, it’s no panacea, as future maintainers still need to understand and learn the syntax and rules of that diagramming code. Can code and diagram changes be automated? I suggest no.
I prefer to think that software architecture is the set of decisions made about how to implement the functional and non-functional requirements of a project.
reply