As someone who has the word "architect" in his software job title I feel like pretty much everything I read on the topic only serves to confirm that nobody knows exactly what software architecture is. I felt that way after reading "The Architecture of Open Source Software," which was essentially comprised of a set of discussions of how various popular applications were put together at varying levels of abstraction and without unifying themes of any kind. I feel that way after browsing this PDF of architectural "patterns" too. When "layered" and "event driven" are presented as sibling patterns at a common level of abstraction I don't think there is any underlying principle at work that makes sense. Or at the very least, if there is someone will have to point it out to me.
Right - it's like a book about designing buildings that has chapters on 'skyscrapers', 'doors', 'shopping malls', 'fire escapes' and 'space hotels'. Yes, those are all topics of relevance to architects, but I can't help feeling the table of contents is lacking organization...
I agree with the "layered" and "event driven" problem. I would characterize them as concepts on orthogonal dimensions, and not things to be compared or contrasted (after skimming over those sections)
But AOSA is a book of case studies, which is of enormous value. I don't see the problem there.
The authors don't give you the unifying themes, because each chapter was written in isolation. You have to fill in the blanks.
But really reading alone isn't enough. That book gives you a taste, but if you really want to understand an architecture, you have to make changes in the codebase. There's no book that can give you that information.
And I feel like I know what software architecture is. It's about 1) how a piece of software is divided, and 2) the relationships between those parts. This book and I would say any other book about architecture can be described like this. Whether the architectures are good or described well is a different matter.
That doesn't mean it's easy, or application-independent, or that every piece of software even has an architecture. But software architecture is quite well defined.
The word 'architecture' formally means "the art or practice of designing structures". So a 'Software Architect' is one who identifies (or defines) the structure of a software system based on various rules and constraints. In this context, the design of the structure could be the identification (or definition) of various components that make the system and how they interact with one another to achieve the intended result.
The one thing that I think everyone can agree on about software architecture is that it involves abstraction - and often copious amounts of it.
I've heard "the job of architects is to add abstractions to a design; the job of developers is to remove them"... possibly in reference to this article:
That's a horrible description. The best people with "software architect" in their title that I have worked with have focused on total system quality through striving towards simplicity mainly by focusing on development and tooling and using their position as the arbiter of technical decisions to guide the system under development to coherent whole that fullfills the business requirements in a technically sound way.
The most complex design tool outside of an IDE I've seen these guys use is plaintext and simple diagrams. They grok the thing that is being built in their heads from the CPU caches to the end-user abstraction.
The most horrible architects I've observed deliver UML:s, search for the most complex technical thing their mind can think of to solve a problem and then after saving the UML to disk think their job is "done" and hand-wave through the rest of the development pointing to the UML boxes.
The mediocre architects are a mix of these two.
An architect who is not participating in hands-on coding is a serious red-flag about the quality of the development organization in most instances to me. I'm sure there are counter-examples :)
> That's a horrible description. The best people with "software architect" in their title that I have worked with have focused on total system quality through striving towards simplicity mainly by focusing on development and tooling and using their position as the arbiter of technical decisions to guide the system under development to coherent whole that fullfills the business requirements in a technically sound way.
Thanks for the this. This paragraphs sums up perfectly what I strive for in my day to day work. It's clear and concise.
I think that what is being presented here is analogous to the basic types of bridge design (e.g. http://www.design-technology.org/bridges.htm ). Knowing what's presented here does not make you a civil engineer, and knowing patterns to a level presented in this book (and in most other accounts) doesn't make you a software engineer / designer / architect.
So what would make design patterns more like real (physical) engineering? My best guess would be a formalization of the design contracts that they imply exist between the components implementing them.
Speaking as an author of one of the articles in AOSA: What would you write if you were the author? Software architecture is very much just a bag of tips and tricks and rules of thumb. The result is, not surprisingly, pretty disparate.
>> 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."
I definitely support direct linking to things on the Web, but since O'Reilly probably meant for this to only be grabbed via an initial landing page, I figured I'd link to it too in case anyone wants some background separate to the PDF: http://www.oreilly.com/programming/free/software-architectur...
It's a good overview. But you can only touch on things at an introductory level in 45 pages, so don't expect all the issues to get explored.
I had one of those "So THAT'S what he was trying to do" moments when I realized that the architecture of an Android API layer that a client was having trouble with was attempting to be a microservices architecture. Instead it bollixed up the way Cursor objects work by trying to pass them across an AIDL-based remote API.
I bet that's not the last time I see that misapplication of a pattern.
Software architecture is difficult to learn. Unlike "small scale" programming, you don't have instant feedback on the validity of your solution and you can't easily experiment with different solutions. Actually, as a student, I don't think I ever had a class on this topic.
I think what could be great is to have a tool that allows you to "program" and analyze architectures. And then exercises to experiment with varieties of architectures.
A little offtopic, but does anyone else think a 5MB+ PDF for 55 pages of mostly text is unusually large? I was expecting somewhat more content for that size... it also doesn't appear to be of the "every page is an image of the text" type.
