Showing posts from April, 2008

Tough crowd: architecting in a shadow of a challenged project

The human feelings is a decision making variable that software architects must consider when architecting or more importantly – when strategizing a software system. This is especially important in environments where users have technology based scars.Situation: Users had (or still have) a bad experience with implementation, deployment, and support of an enterprise grade solution. The system was adopted by a large (7000 people) organization through a mandate – people use it on a daily basis because they are forced. This brute force approach has done a tremendous damage to users’ trust and any new IT investment will be severely challenged. Potential solution1.Recognize the pain your future users are feeling right now. Study the situation and learn their existing environment. Understand the challenges of that system – you may face them as well.2.Clearly understand the business problem you will solve with a software solution. You must, absolutely must, get different perspectives on the pro…

How mature is the software architecture discipline?

In 1996 Professors David Garlan and Mary Shaw of the Carnegie Mellon University published an influential book: “Software Architecture – Perspectives on an Emerging Discipline”. In chapter 1 the authors discuss a model for the evolution of an engineering discipline. The diagram can be found here.Before discussing the diagram let’s establish a few key concepts. With respect to maturity of engineering disciplines based on pure sciences (e.g. chemical engineering) the software engineering discipline and to a greater extent software architecture discipline is generally considered to be very immature. But why? The authors state that “engineering practice enables ordinary practitioners create sophisticated systems that work … reliably.” Has the software architecture reached this state? It’s important to note that engineering discipline practitioners make the bulk of money by solving routine design problems. Routine design aims at “solving familiar problems” and designing solutions by using t…

Software Architecture is about people

At its core the software architecture discipline is about people and our obstacles are a figment of our imagination.

Constantin Kostenko.
Firebrand Architect®

Microsoft’s Architecture Journal 15

The latest issue of the Microsoft’s Architecture Journal is bound to rekindle the topic of maturity and purpose of the software / enterprise / technical / infrastructure / data architecture discipline. The issue is fresh off the press. Microsoft is correctly anticipating the onslaught of responses by setting up a special discussion forum. As of writing of this post the forum is not yet active, but once it becomes active the phrase tra-ta-ta-ta-ta will take on a whole new meaning.Constantin K.
Firebrand Architect™

Software Architecture Assessment

Assessment of software architecture is necessary to judge its utility and applicability to the goals a system aims to achieve. Every architecture design should be assessed by a non-partisan resource, but this practice has been adopted only at organizations with a very mature software engineering processes. There are no industry wide accepted methods for evaluating software architecture, but the Architecture Tradeoff Analysis Method (ATAM), developed by the SEI, is a well structured & rational approach for conducting architecture assessments.Benefits of a structured tradeoff analysis methodThe principal benefit of the Architecture Tradeoff Analysis is an ability to see if a proposed overall software structure will live up to the user expectations. The tradeoff analysis helps one understand the strengths and weaknesses of a system. The ATAM method not only helps evaluate the current system architecture, but also helps with the design of architecture for a new system. This methodolog…

Boundaries between "Architecture", "Design", and "Implementation" formally defined

Insightful paper by Rick Kazman & Amnon Eden, presented at ICSE 2003, that defines the boundaries between "Architecture", "Design", and "Implementation" by formalizing the ‘Intension and the Locality criteria, which imply that the distinction between architecture, design, and implementation is qualitative and not merely quantitative.’ Basic understanding of formal notation (esp. Zed) is necessary for enriched reading experience.Download the paper from or SEI.Constantin K.
Firebrand Architect™

Microsoft's Architecture MVP Changes

In late February of 2008 Microsoft dissolved the Microsoft Architecture MVP award as part of realignment of the MVP program to be more product oriented. Dissolved is a wrong word … so read on. This came as a surprise to many award recipients - including myself – who lost a “nice to have” title. This development, however, had a very positive impact on the Architecture MVP community, because it forced the architects ask themselves some hard questions about their role in the community and the role Microsoft plays in the software architecture discipline. This post features some highlights from the ferociously bubbling listserv.At first there was confusion. Participants understood the reasoning behind moving towards a product oriented approach, but they couldn’t fathom the disappearance of the architecture competency. Then there was anger – well summarized by one of the participants: “I believe the shutdown of the MVP Architect program is just one more piece of evidence that … Microsoft do…