What do you think?
Rate this book
Paperback
By the time I’m writing this, I have about eight years of experience in software engineering. For a big part of it, software architecture has been a major concern for me. One of the earliest questions I pondered was the difference between software architecture as it’s practiced by the community and described in the canon and just developing some proper OOP. This distinction, although it started to clear early on, remained a bit vague for me. One of the longest-standing questions was the relationship between agile development and software architecture.
This book, as far as I can tell, is an acknowledged reference on the subject. It covers a lot of the related topics of software architecture and investigates the mutual interactions between them. The book covers a lot of theory and delves deeply into methods. I regard this as my official introduction to the field.
For several reasons, I’ll not dive into analysis. Instead, I’ll list some key takeaways:
Software architecture is the first step in guaranteeing the quality attributes of a system. It’s not alone, and the details of implementation have a significant part to play here, but the software architecture lays out the big directions.
Software architecture, if properly done, can play a great part in easing and guaranteeing many functions on the lifecycle of a software project. Starting from requirements gathering and elicitation, to testing and deployment. It operates within many contexts, such as the organizational context and the business context.
The software architecture is an abstraction. A single architecture can lead to different implementations.
Although it’s hard to draw a defining line between them, quality attributes and functional attributes are two different things. A some-what basic definition is that the functional requirements define what needs to be done, and quality attributes define how this is done.
The elicitation of most quality attributes is the job of the software architect.
Agile and software architecture can co-exist. In fact, software architecture can contribute many capabilities that are crucial for agile development, mainly quick prototyping and predictability about the system.
Documentation is just like any other kind of writing, it has to have its intended audience and expected uses while it’s being written.
The architecture is a set of views, where each view is concerned with a certain aspect and describes a set of elements and the connections between them. This approach is important while developing an architecture and while documenting it.
While explaining the software product lines, it was explained that the best cost-effective way for code reuse is sharing the full artifacts of a software, starting from the requirements, to the architecture and implementation and down to the testing artifacts. It means that quality concerns, deployment environment, organizational structures, and more, have a lot of effects on any developed software. Using any such software means adopting all these factors. That’s why the compromise is made during requirements elicitation between the expected economic gain from reusing a product line (or reusing an architecture) with the possible feature or requirements to drop that can’t be supported by this architecture.
Speak the right language. We, engineers, when we transform into hardcore nerds, tend to forget that a lot of other factors affect the project, and some factors that play a bigger role than technical aestheticism into the success of a project. The architecture’s main strong arguments are its economic and life cycle gains. Speaking about these effects is what’s likely to change the organization’s directions towards adopting a software architecture.