> 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.
> 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.
> 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.
> 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.
> 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.
> Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot.
That's fair, but shouldn't we strive to make the best possible guesses in the absence of said theory and science?
> we need to go back to the idea that software can be like building a building where there are basic building blocks that can be purchased from many vendors and let each vendor decide how to improve the blocks and let the architects and engineers decide what blocks to use
Isn't that just libraries and APIs? There's friction when interfaces aren't standardized, but it's certainly a good deal of the way there.
> 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).
> 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.
> 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.
> 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.
> My suggestion for learning software architecture is to practice. Obviously you can't practice it by doing hundreds of projects, because each one of them takes too long, but you can easily design a hundred architectures for problems which only exist on paper, and where you strive to just get the solution to work on paper.
But, how do you get feedback to tell you if you're making the right or wrong decisions?
> When you find out that the architecture is wrong, do you fix it? Or do you just hack it to get the next bit to work?
That's very project and organization dependent. Some projects are short lived prototypes (I'm working on one now) that are for internal use only, so it makes sense to try and get the damn thing finished without worrying too much about architecture.
Other projects are built to last, or have very high quality requirements, so you want to really get the architecture right, even if that means costly rewrites.
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.
> I think this article places too much emphasis on input devices and hardware constraints, and not enough on software architecture.
No it does not: it clearly makes the point that due to device, hardware, OS, and framework latencies your application has very little time budget in which to respond and still feel fast to users. This will necessitate considerable effort in terms of architecture. I don't see how that's under-emphasising it.
To have a useful discussion on architecture within the article they'd have to talk about the specifics of different software and applications, which obviously vary considerably according to the requirements for said software and applications.
The danger with that sort of thing is that some people will say, "well, if we use architecture X then our application will feel fast," disregarding many of the detailed requirements of their domain that mean X won't always (or possibly even ever) perform well.
To some extent that's unavoidable but I think this article was absolutely on point in that it makes clear the constraints within which software developers must operate, and sensibly leaves architecture as the responsibility of those software developers.
> Except that isn’t what software engineers largely do, we aren’t building the nth copy of the same building with a slightly different skin.
That’s exactly what most developers do.
There is far greater variation in boring bridges spanning small streams than most web applications and yet after more than 20 years we still can’t figure it out without some giant framework to do most of it for us.
> I think that one of the fundamental principles of software engineering is to code in such a way that future change is contained
Uff...that's a heavy statement. There is no such hard and fast rule. In fact its mostly the opposite, I argue. 90% of the abstractions don't ever get used. Write twice and then make an abstraction.
I think you're doing software engineering the wrong way, sorry to say.
> On the other hand, frameworks are like using common tools, foundations, scaffolding, and (literally) frameworks to build a custom architectured house.
This is exactly the problem, you are trying to use a standardised blurprint, to build a custom architectured house. Where you should probably make a choice here, either go standard or custom.
> Of course, building your own home is possible but that could be a shack made up of sticks and mud or a stack of bricks and mortar with no base/foundation which can fall apart at any moment.
Why would a highly skilled builder build a shack of sticks and mud, or a house without foundation? Why do we assume that every software developer is an incompetent clown?
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.
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.
reply