Showing posts from 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®

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 reme…

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 y…

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®

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 Languagebook, 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: Arc…

Don't mix up architectural perspectives

No real world system consists of a single [software] architecture pattern. Most systems are a combination of multiple patterns (a.k.a. styles) that together make up a solution. A common mistake that some architects make, when documenting software architecture, is mismatching different perspectives. For example, showing a layers pattern coupled with a process threads pattern within the same perspective makes no sense since layers is a static perspective and threads are associated with a dynamic perspective. It’s like mixing apples and oranges. In some cases it’s beneficial to show how a static (modules) perspective maps to a dynamic (run time) perspective, but such composition can occur when you already have two other perspectives.
Constantin Kostenko
Firebrand Architect®

In software engineering we’ll never reach a plateau

On March 12th and 13th I attended the 20th anniversary of the Masters of Software Engineering Program at Carnegie Mellon. It was great to reconnect with alumni and learn about the continuing progress of the professional software engineering program.
The Saturday program included a talk by Bill Scherlis, a professor of Computer Science at Carnegie Mellon University and Director of the Institute for Software Research, who talked about the current and future state of the software engineering practice.
Key points: - There is constant struggle for order & predictability, but the more we struggle the less we succeed. -Productivity paradox – economists still cannot clearly measure impact of software / IT. -Constant innovation is the mantra of the software world – we’ll never reach a plateau. As soon as we reach a "stable" state we'll have various pressures requiring us to innovate. -Disruptions happen all the time. Change is constant. -Conway’s law is still the law. -More’s law …

The Design of Design: Essays from a Computer Scientist

Fred Brooks has always been ahead of his time; about 20 years ahead to be precise. His new book, The Design of Design: Essays from a Computer Scientist, goes on sale soon. Pre-order it now.
It will be a timeless classic. If you need to ask why such a bold statement then you need to read The Mythical Man-Month: Essays on Software Engineering.

Constantin Kostenko
Firebrand Architect®

Sun Tzu

“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.” -- SUN TZU

Constantin Kostenko
Firebrand Architect®

Follow the money

An idea or a software project is only as strong as availability of funding. In times of crisis the source of funding and executive sponsorship may change quickly. Business owners and software architects must plan for this; architects must persistently take this fact into account when they design and when code is written.

At times of instability it's paramount to show continuous progress. From design perspective decoupling, as a quality attribute, becomes very important. If a source of funding or ownership changes and a core component (that delivers desired business functionality) needs to shift from project A to project B, it must be done quickly and successfully. A highly modular design will allow uprooting a logical segment of a system and reviving it as part of another project. In these situations strictly adhering to solution architecture during implementation is imperative, because when funding is cut you have little time to wrap things up. Developers must understand the impor…