The title of the post, and consequently the HN submission, should say "Software Architecture". If you omit it, most people would think you're talking about bricks and buildings.
Both the book, the blog post, and this HN submission are deeply wrong on one thing: it should be called "software architecture", instead of simply "architecture".
You might say: the audience would think of software, it's unnecessary to specify... Perhaps you're right. I still think that a distinction would serve us well.
That's like calling a bike shed "civil engineering". I don't know what point you're making with the term "software architecture" other than trying to make it sound burdensome.
yes, except i think for a vast vast majority of people the word architecture does not bring up thoughts of IT. the title of this post doesn't do a good job of that. whats wrong with 'IT systems diagrams should be code'
? Article does not talk about pitfalls of architecture, proceeds to talk about hierarchical processes in organization. Guess it's a failure to uphold and implement layers of abstractions. Good thing there is a software engineer to distribute knowledge on software development process engineering. The failure of the article is the article.
Now I am conflicted. I agree with this article just as much as I agree with this one that says "Architecture has no place in software", also posted today: http://hhgttg.de/blog/?p=352
Actually, our approach is not that different in principle, to most architecture guides.
This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.
The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort.
You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.
Software architecture is the process/skill of breaking down problems/solutions into systems and subsystems that are appropriately modular, encapsulated with well defined interfaces.
It's not quite that simple, you need to decide on centralise, distributed etc especially in regard to your known scalability requirements, but these might end up being different than you foresee.
Way off the mark. "Software architecture" is about how you make the disparate parts of a software system work together towards a common goal. Most of these parts aren't code: hardware, programmers, tech support, HR, licensing and legal, etc.
>> Software architecture is very much just a bag of tips and tricks and rules of thumb.
I think that agrees with the spirit of my original comment. To answer your specific question: I'm not sure. If a book about software architecture is going to look at two implementations - say, Audacity and Bash to take two examples from the first book - then it has to work very hard to find an architectural language that applies in common to both. If it does not, then all that has really been accomplished is to peel the onion on some interesting applications, and while that is valuable and makes for an enjoyable read, I don't feel like it gets us any closer to actually understanding what the "architecture" of a software implementation is. The word has to mean something more than "things we've done in the past."
Asked GTP4-32k to make an article summary of 10 important points.
And then applied the summary to the software architecture
---
Public and Shared Nature of Software Architecture: Just like physical architecture, software architecture is inherently public and collaborative. A well-designed software system should be intuitive and user-friendly as it is used and experienced by a broad range of people.
Traditionalist vs. Modernist Debate: In software architecture, the debate between traditional monolithic systems and modern microservices architectures echoes the debate in physical architecture. This leaves some developers ideologically homeless as they see the benefits of both approaches.
Misleading Term of 'Traditionalism': The term 'traditionalism' can be misleading. In the context of software, it might suggest sticking to older technologies or methods, even though modern approaches have become traditions in themselves, with their own pioneers and best practices.
'Goodism' and the Value of Good Software Architecture: The concept of 'goodism', favoring good works over bad ones, applies to software architecture. However, the sheer quality of the work is not all that matters; considerations such as scalability, maintainability, and usability are also crucial.
Easy vs. Challenging Architectures: Easy software architectures are those that can be understood and utilized without much effort, whereas challenging architectures require significant work to comprehend and navigate. This distinction is orthogonal to the good/bad dichotomy.
Rise of Complexity in High-Status Software: Just as there's been a rise in difficulty in high-status arts, software systems have become increasingly complex, with architectures like microservices and event-driven architectures challenging to comprehend and implement effectively.
Software Architecture as a Background Art: Software architecture often serves as a 'background art' to the user's primary task. Therefore, it should be designed in a way that enhances user experience without unnecessary complexity.
What Makes an Easy Software Architecture?: An 'easy' software architecture is one that is intuitive, scalable, and maintainable, with clear documentation and well-defined interfaces for interaction. It involves a combination of architectural patterns, use of appropriate technologies, and following best practices.
The Role of Simplicity in Software Architecture: Similar to the concept of 'tonality' in architecture, 'simplicity' plays a crucial role in software architecture. The software system should be as simple as possible to meet its requirements, enhancing usability and maintainability.
Flexibility in Choosing Software Architectural Styles: There's no strict need to choose between traditional monolithic architectures or modern microservices. There are many strands of modern software architectures that are accessible, and there's no general reason why we have to stick to old styles or always adopt new ones.
Agree, but I would go further. The term "software architecture" is one I actively disdain. Architects build buildings. If there's anything we learned from comparing civil engineering to software development it is that they it is harmful to draw parallels. So while using architectural metaphors is sometimes ok, this term is not.
Software design, on the other hand, is something everyone who writes software is involved with. It is not an act reserved to few and disseminated to the "great unwashed coders" like they are some kind of construction crew who just read blueprints while typing the source (another crappy parallel drawn from the same place as the term 'software architecture')
reply