Like many web developers, I learned the art of writing code by trial and error, rather than through formal instruction. I’d look at examples on the Internet, read forum and blog posts, and occasionally consult a book or two. This worked surprisingly well — I’ve made a career out of it, and gained a lot of knowhow through hard-won experience.
You can’t learn everything by trial and error, though. Sometimes the experiments take too long to run, or you can’t afford to have the results blow up in your face. Although I’d figured out basic software architecture principles by observing what worked about past projects and what didn’t, I wasn’t very systematic about it. But hey, I could scribble a boxes-and-arrows diagram on a whiteboard and talk folks through it, and that was enough for most web applications.
My current employer, EPAM, takes software architecture seriously. I found this out when I was invited to serve on an assessment panel for Solution Architects seeking promotion, and I developed a bad case of impostor syndrome. It turns out that there are names for the different kinds of diagrams I’d been doodling, and methods for determining which customer requirements were architecturally significant. You could subject these ideas to analysis and evaluate tradeoffs in a systematic way instead of, you know, by gut feel.
My spidey-sense for software project disasters is pretty well attuned by this stage in my career, so I think I was able to ask reasonable questions of our crop of upcoming architects. But I could tell that several of our candidates were winging it, and I wondered if it was obvious that I was groping my way along as well.
So I decided to do something about it. After a bit of Googling, I found out about TOGAF and the SEI, and the fact that there’s an international standard for software architecture, ISO/IEC 42010. Neat. And then I found the book Software Architecture in Practice.
I’ve spent the last few weeks reading it through, chapter by chapter. As textbooks go, it’s well-written. It’s also (as befits a book about architecture) very well-structured, so it’s something I plan on using as a handy reference when I want to know about tactics for improving performance, or about tradeoffs between usability and security.
It’s also interesting to see a bit of what software architecture looks like in other domains. As a web developer, I don’t often need to think about the constraints imposed on real-time or embedded systems. But I do think a lot about scalability, availability, and some of the other quality attributes described in the book. It’s nice to have these cataloged, with approaches for how to address these needs and what the implications are.
I agree with the authors that the term “quality attributes” is much better than the more commonly used “non-functional requirements.” Most people seem to assume that the non-functional requirements are non-interesting and non-important, when in fact they mark the difference between unicorn and fail whale.
Later chapters address documenting and evaluating software architecture, and software architecture’s relationship to modern software development methodologies, like the various flavors of Agile.
I was really glad to have found a book that captured so much of what I’d learned in the school of hard knocks, and that offered a few new ideas and tools for me to apply to future projects. Naturally, I loaned it out to one of my coworkers and immediately recommended it to another Solution Architect I’d been mentoring at EPAM.
“Oh yes,” he said, “I know that book. It’s on the curriculum for EPAM’s Software Architecture University. That’s a good one.”
On the curriculum…? I guess I still have a way to go before I can ditch that impostor syndrome.
Dean Thrasher 