Wednesday, December 28, 2011

Re-post: "Importance of Well Designed Software"

Great blog post by Agile Journeyman about Martin Fowler's  Design Stamina Hypothesis & the Technical Debt Quadrant.

Constantin Kostenko
Firebrand Architect®

Friday, October 21, 2011

Microsoft Application Architecture Guide, 2nd Edition

This book, Microsoft Application Architecture Guide, 2nd Edition, has a few sharp edges, but it's a good place to start with the intention to continue learning about the discipline from other sources.

Sunday, July 10, 2011

Teaching is learning

Seeing people learn is exciting. I really enjoy my part-time gig working as a Distance Education Instructor supporting the Software Architecture eLearning course at the Carnegie Mellon University. It’s exciting to see students, who are many years into their professional careers, learning about a disciplined way of thinking about software architecture. These students are not there because they have to be there, they are there because they (and their employers) see value in learning and applying a disciplined approach to building software intensive systems.

During the semester long three phase project it’s interesting to see students get to the “Aha!” moment when they try to reason about system decomposition and fail because the quality attributes they specified were not defined in a precise manner. Since quality attributes define the behavioral properties of the system they (along with business and technical constraints) impact the selection of architectural patterns and tactics. It’s the students’ desire to go back and re-work a previous phase of the project that shows they understand their mistakes and want to learn from them.

What helps students learn is detailed feedback on their project and their responses to the lecture and reading material. For students this course is an opportunity to learn how to think about analyzing software architecture now and in future. It’s a place to learn, make mistakes, and get effective feedback. And for me it’s an opportunity to reflect on my professional experiences and learn about myself by teaching the software architecture discipline to others.

Constantin Kostenko
Firebrand Architect®

Friday, April 15, 2011

CASCON 20th Anniversary - First Decade High Impact Papers

From the CASCON site: "Conference of the Center for Advanced Studies on Collaborative Research [published] First Decade High Impact Papers as part of the 20th anniversary past papers presented at CASCON which had delivered high industrial and academic impact are being recognized. Headed by Hausi Müller, the specially created CASCON First Decade High Impact Papers (FD-HIP) Selection Committee selected 14 papers from the 425 papers published during the first decade as winners. The selected papers are featured in a special CASCON proceedings volume. As well, the authors celebrated through the First Decade High Impact Papers will be recognized during the Monday, November 1st keynote at 1:00 p.m, and will also be on hand to attendees during the Technology Showcase Reception on Monday, November 1st to discuss their influential works."

Link to the listing of papers.

Constantin Kostenko
Firebrand Architect®

Tuesday, April 05, 2011

2011 Outstanding Research Award from ACM SIGSOFT

David Garlan and Mary Shaw win the 2011 Outstanding Research Award from ACM SIGSOFT.

"This award is presented to an individual who has made significant and lasting research contributions to the theory or practice of software engineering."

Constantin Kostenko
Firebrand Architect®

Monday, October 18, 2010

Highly anticipated & somewhat overdue

This book needs no introduction to serious software architects ... Documenting Software Architectures: Views and Beyond (2nd Edition) is finally here.

“This new edition is brighter, shinier, more complete, more pragmatic, more focused than the previous one, and I wouldn’t have thought it possible to improve on the original. As the field of software architecture has grown over these past decades, there is much more to be said, much more that we know, and much more that we can reflect upon of what’s worked and what hasn’t—and the authors here do all that, and more.” —From the Foreword by Grady Booch

Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Saturday, May 22, 2010

Domain specific patterns

One way to become a recognized expert in your line of work is to become versed in your organization's domain specific design patterns. You will gain an exponential level of recognition if you contribute to codifying these patterns. Be proactive in documenting and sharing design patterns specific to your problem (business) domain. Few organizations invest resources into codifying the non-standard design patterns even though they are implemented often (hence the name). If you're the one recognizing and documenting domain specific design patterns you'll become a recognized expert.

By now many organizations have internal wiki-like collaboration tools. That’s the best place for you to start documenting these domain specific design patterns. Use that collaboration space to involve others. To be effective select an existing (or create your own) framework for describing design patterns. Many frameworks and approaches exit, pick one that works and modify as you go along. Just remember that design patterns apply to different level of design granularity.

Why is this important? Reuse at architectural level. Further, domain patterns may lead to reference architectures. This will help you and your organization reuse design concepts. Reference architecture (specific to your domain) may then result in an implementation framework (again, specific to your domain) that may contribute to development of product lines.


Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Have a clear exit strategy

When are you done architecting? How long should the architecting phase take? These are very common questions that often don’t have a common answer. Your answer depends on what you’re trying to achieve and your operating environment.

The first step is to understand your environment and your constraints. Both technical and organizational. As Fred Brooks said in his new book The Design Of Design: “constraints are friends.” Constraints bound you and the scope of your work. You must still understand and feel the difference between a real constraint and a perceived constraint (often political) and a requirement.

The second step is to define your exit strategy. This must and can be defined shortly after you understand the general nature of the problem and your role in defining a solution. This requires understanding the role of downstream designers and implementers (even if you may be playing those roles as well). Without clearly defining the success (and failure) criteria before you invest your time your work is never going to be good enough. It’s a given fact that your success criteria and your exit strategy may change through the design process, but having a baseline will make it easier for you to handle changes in the future. But most importantly you’ll know when you’re done.


Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Thursday, May 20, 2010

The most costly defects are design defects

In software the most costly defects are design defects. If you play the role (or carry the title) of a software architect be sure that you’re explicitly architecting your systems versus letting the designs emerge. The design shall emerge whether you want it or not, but you may not like the results. Further, be sure you understand and document your design decisions in the context when they were made. Undisciplined system design is irresponsible and is only appropriate for experimental solutions and throw away prototypes (that are guaranteed to be thrown away).


Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com

Wednesday, May 12, 2010

What's this pattern's level of abstraction? It depends.

In building architecture we often easily recognize when one pattern fits into another pattern. Perhaps this is because physical things are easier for us to touch, feel, see, and sense. For example, in A Pattern Language book, Christopher Alexander clearly shows how building and city planning patterns fit with each other. Take the Activity Pockets pattern as an example. The essence of this pattern captures the fact that in order for an open public space to be vibrant and lively it needs to have a set of activity pockets at its edges. As the number of activity pockets expand the whole open space becomes lively. So if an urban designer’s design goal is to create a lively public space he or she may choose to apply this pattern. This pattern (#124) “helps complete the edge of all these larger patterns … Promenade (#31), Small Public Squares (#61), Pedestrian Street (#100), Building Thoroughfare (#101).” At the same time this pattern is further refined by the following downstream patterns: Arcades (#119), Trellised Walk (#174), Sitting Wall (#243), just to name a few. It’s easy to see the granularity level of the Activity Pockets pattern in the context of a city and a building.

The above mentioned pattern makes sense, especially when combined with a topology map, but what about software patterns?

In the software architecture world the granularity of a given pattern is not always obvious. In case of well known patterns, such as client server or its derivative N-tier, everyone knows that they represent a systemic level of abstraction. But less known patterns may confuse architects, especially if some patterns is widely recognized as systemic, but is encapsulated inside of some other systemic pattern. For example, a 3-tier overarching architecture may have a data repository pattern (also known to sit at a systemic level of abstraction) hidden at the next level of decomposition in the data tier.

The key to dealing with potential confusion is to clearly explain (and document) patterns used and why. Further, maintaining a proper perspective (i.e. dynamic, static, or physical), as mentioned in the previous post, is critical when showing how one patterns supports another pattern.



Constantin Kostenko
Firebrand Architect®
SoftwareArchitectures.com
FirebrandArchitect.com