Lecture review: A truly great perspective on Software Architecture

My impressions of lectures given by Juval Lowy, Hayim Makabee and how they relate to my own experience

I had the fortune today to sit in a lecture given by Juval Lowy on Software Architecture (Zen of Architecture). This lecture was eye opening, because it showed both what is wrong with the common methods and why and how to do things right while drawing from examples from both the software domain and other domain, all in a humoristic manner including expected reactions from management.

The highlights of the lecture are do not design per requirement or per feature, instead identify the truths of the domain, what is constant, what will change and design a solution that is open to changes that are likely to happen while closed to changes that are irrelevant.

This lecture also reminds me of a lecture I've been to in the past by Hayim Makabee (Adaptable Design Up Front), which also discussed the open/closed design principle and the quantity of design necessary up front.

Both Lowy and Makabee give advise for how to identify points for change and see the wider requirements. Lowy's advise included identifying the age-old truths, that are not likely to change vs. the latest trends that are likely to change and to look at the business' competitors as test cases for your design, as if the design can't easily be adapted to work for them, then it isn't flexible enough. Lowy also added that practicing these principles on both past and present and even non-software related problems can help you master this skill. Makabee's advise included looking not at the product you need to design, but instead at the product line to which this product belongs when designing the architecture.

Will these approaches make the architecture process take longer? Probably. Will these approaches make the implementation take longer? No, since you do not need to implement all the options at once, or usually at all, until they are needed. Will these approaches enable your architecture adapt to changes and enable the implementation to accommodate to changes rapidly? Yes. If your architecture is designed to accept changes, then the implementation of changes should be local and not system wide.

From my own experience, do these approaches hold out in the real world? Yes. While my experience is definitely not be as vast as Lowy's, all of the architectures I designed or have seen that took into account both what the product should do and what similar products do and probably will need to do ended up adapting quickly to the vast changes in requirements, enabling both high reuse and rapid replacement of components with new components when the current requirements justified a replacement. Whereas, all the products I have been involved in or have seen that assumed a set reality that was set by current requirements and not the truth of the domain ended up either being completely replaced after they failed to be changed to keep up with the changing reality or ended up crippling the business, if management refused to commit to their replacement.

I highly recommend you attend the lecture "Zen of Architecture" if possible, as it can provide you with a toolset for analyzing the domain and coming up with a good architecture.