This is my second year serving as the distance education instructor for Carnegie Mellon's Principles of Software Architecture course. The distance education course is aimed at working professionals and has the SEI Software Architecture paradigm as a backbone. The course is based on the same material taught in the Masters of Software Engineering program at the Carnegie Mellon by David Garlan and Anthony J. Lattanze.
I spend time interacting with students through conference calls, class bulletin board, emails, and assignment grading. It's very interesting to see how professional software engineers and architects with many years of experience learn new ways of thinking and reasoning about software architecture. This experience offers me a unique perspective to see how people learn about a disciplined way of thinking about the art and science of software architecture.
Experienced software engineering professionals who design and build non-trivial software systems as part of their day-to-day responsibilities have no major problems adopting to the SEI Software Architecture paradigm and other software architecture topics taught in the course. But what about those with little design experience? On the topic of architectural patterns, architectural styles, design patterns, and design in general the biggest problem is judging the scope and applicability of a given pattern or a style. When asked to indentify the most appropriate architectural style for a given system implementation students become confused. Would SOA be an appropriate style? Or may be the MVC pattern? But wait, a software system may be a heterogeneous composition of multiple patterns and styles. So how can there be a single overarching pattern? In other words the students with less experience appeared to have trouble focusing the lens (of the "right" answer) on the problem.
Does this mean time and experience is the only way to become a better architect? Absolutely not. After taking this course the students who didn't have an ideal level of experience will look at every single software architecture challenge from a different perspective. They will question their decision and decisions of others. They will demand to understand why decisions are made one way or another. As they learn and experience different design patterns and architectural styles they will see get the "aha!" of the questions asked in the weekly homework reading questions.
If you're just beginning to learn about software architecture please understand that it's a journey and not an event. While the Software Architecture course from Carnegie Mellon's School of Computer Science can make you think about software architecture in a disciplined way it will not make you an expert architect. Learn and read everything you can from diverse sources since it's still a maturing discipline. Take everything that you learn with a grain salt. Ask "why?" on major decisions and think like a firebrand™.
I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...
Great blog post by Agile Journeyman about Martin Fowler's Design Stamina Hypothesis & the Technical Debt Quadrant. Constantin K...
Agile processes give you an ability to do something faster. Often agile approaches give you an ability to deliver smaller chunks of software...
From the SEI podcast series: "We know from existing SEI work on attribute-driven design, Quality Attribute Workshops, and the Ar...