Tuesday, February 17, 2009

How Business Goals Drive Architectural Design

How do quality attributes affect the architectural design of a software solution? If we only cared about the functional requirements of a software solution, then any architecture and any implementation would suffice. Further, how business goals drive architectural design?

The topic of translating business goals into architectural drivers merits a separate post, however this article from the August 2007 edition of the Computer magazine (IEEE Computer Society) eloquently demonstrates how the architecture of a software solution changes as business goals are refined into quality attribute scenarios. Application of architectural patterns and refining tactics significantly alter the architecture of a software solution.

Constantin K.
Firebrand Architect®

Tuesday, February 10, 2009

Architecting Software Intensive Systems: A Practitioners Guide

In summary of chapter 5, The Work of an Architect, the author notes that "… this is not intended to be a definitive statement on how to architect. Architecture design is guided by the intuition and judgment of the architect. The purpose here is to provide principles and guidance for how tot think about decomposing a system, what to consider when decomposing the system, and how to capture key design choice and rationale." This chapter alone is worth the price of the book, Architecting Software Intensive Systems: A Practitioners Guide, as it proves invaluable guidance in a clear and concise manner.

Make space on your bookshelf that's located closest to your desk. Buy this book. Use this book.

Few practitioners have the level of depth and breadth necessary to eloquently capture and explain the practical aspects of the software architecture discipline. The author, Anthony J. Lattanze, explains the critical need for separating perspectives (static, dynamic, physical), explains architectural drivers, and provides guidance for architectural design. The rest of the book covers the Architecture Centric Design Method - a practical approach that you can use from concept initiation to solution sunset.

Constantin Kostenko
Firebrand Architect®

Monday, February 09, 2009

The process of learning the principles of software architecture

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™.

Constantin K.
Firebrand Architect®

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...