Showing posts from 2008

The Bus Problem

Software engineering practitioners joke about this all the time, and it’s a classic management problem that is deeply rooted in the software engineering folklore. There exists a person who singlehandedly built software program that supports some important business function (in production environment of course). Everyone knows that there is virtually no documentation, no one else knows the code, there is no source control, and this is the only person who can maintain the program. And if that person gets hit by a bus and dies there will major issues, but it’s better not to think about it.

Even in the organizations that have mature software engineering processes the bus problem persists. This is because all organizations have opportunistic projects (programs) developed by a person or two. These programs, usually developed as unofficial side projects, support informal business processes that provide significant benefit to the end users at little cost. These opportunistic projects are usual…

Taking care of your people

This post is about taking care of your colleagues and employees. With holidays rapidly approaching many people scramble to say thank you and congratulate their subordinates and colleagues. This behavior often leads to awkward moments and superficial exchanges of gratitude. Don’t do it.

If you haven’t been taking care of your people through the year consider changing your behavior. By saying “taking care” I don’t mean buying expensive gifts or giving superficial awards. What I mean is enabling your colleagues and employees to support you in the most productive way possible while operating in a professional environment. In life it’s the small things that leave a lasting impression that make people happy.

Let’s say your new team members all have standard company issued laptops with 1 GB or memory. The software tools they use to model architecture and conduct analysis functions result in thrashing and frustrating usability experience. Closing Outlook and IDE makes the modeling software run …

Architecture evaluation attititude

When faced with a task of architectural evaluation of an existing system a software architect may make an assumption that something must be wrong with the architecture. Of course if someone asks you to perform such task your first question is to understand what is implied by “evaluating the software architecture of an existing system.” Before any work of technical nature commences the business purpose of the evaluation task needs to be established.

The goal of an evaluation is not to determine what is right or what is wrong. The goal of an evaluation is to gain an understanding of how a system is constructed. It’s always healthy to be skeptical – we advocate this strongly as it’s the mantra of the Firebrand Architect® blog – but also give a “benefit of the doubt” and try to understand why a solution was architected one way or another. Remember that the system was designed and implemented under constraints that may no longer be true today.

As a public service announcement, please do your…

Architect-as-contractor model in building architecture

In the October 10th 2008 Wall Street Journal article, House Designers Don Hard Hats, the author describes the architect-as-contractor model called design-build. This approach is the unquestionable standard in the software engineering world. This article vividly demonstrates some well known parallels between building and software architecture.

Some points to note. The design-build model works only when the design documents are extremely detailed - down to the last screw or caulking decision. There are upward of thirty different architectural views for a $5M project. And of course an architect is playing the role of a developer by participating in the day-to-day building activities.

The article offers interesting reaction to this approach from former customers. Since there has been some isolated discussions in the software architecture community of the separation of high level design from implementation it’s worth a look.

Constantin K.
Firebrand Architect®

An expert is ...

My definition of an expert in any field is a person who knows enough about what's really going on to be scared.
- PJ Plauger

Constantin K.
Firebrand Architect™

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…

Frank Lloyd Wright

Frank Lloyd Wright, one of the most famous American [building] architects of all time, worked on over 500 structures and left a few notes of wisdom for us to consider. While the comparison between software and building architecture breaks down pretty quickly, the quotes below apply to both disciplines.

A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.All fine architectural values are human vales, else not valuable.An architect's most useful tools are an eraser at the drafting board, and a wrecking bar at the site.Every great architect is - necessarily - a great poet. He must be a great original interpreter of his time, his day, his age.Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.Get the habit of analysis - analysis will in time enable synthesis to become your habit of mind.Less is only more where more is no good.The architect must be a prophet... …

Static, Runtime, Physical

For the spring 2008 semester I function as a distance education instructor for the Principles of Software Architectures course offered by the School of Computer Science at the Carnegie Mellon University through the Institute for Software Research International. As I reviewed the course I fondly remembered the lectures by Prof. David Garlan and Tony Lattanze while pursuing my Masters in Software Engineering (IT) degree some years ago. At the same time I reflected on the architecture representation practices employed on some of the recent projects I’ve reviewed and sadly the state of affairs is looking pretty grim. It is still common to see software architecture designs mix incongruent design elements together, such as combining message flow process with a class diagram. As a gentle reminder, architecture of a software system is represented through a number of views that describe some angle of a system. There are many different views that can be chosen by an architect to represent some …

Evolving Opportunistic Solutions

Opportunistic projects (software solutions) are the essence of the progress in all organizations. These projects provide valuable ad-hoc gains in productivity to the people who need help the most. Such projects usually don’t have a formal budget, have one or a few people running it, and usually reside outside of enterprise architecture environment or go against the formal way of doing things. But these projects exist because they provide the benefit the core IT organization cannot. One example may be auto generation of pre-canned reports for a loan processing clerk. In this case an existing FICO score provides good information about the risk level of a potential borrower, but a loan procession clerk may get an additional level of insight, and reduce risk to the bank, by looking into additional publically available information. Usually opportunistic solutions target a small specialized niche, such as pre-canned reports for farm machinery loans. But as loan officers across bank division…

Edward Hopper - Communicating the Essence

It’s the architect’s job to decide and communicate which quality attributes need to be emphasized in order to achieve the overarching mission of a solution. Similarly the iconic American artist Edward Hopper, in his paintings, captured the essence of a scene while abstracting the negligent elements of the situation. In painting Haskell’s House you clearly see that the artist chose to omit the wires from the electrical poles. The busy harbor behind the house is not depicted in the painting: the core emphasis is on the house. Also notice how the sun rays draw your attention on the house and you can almost forget about the mundane details of trees, landscaping, and electrical poles. A software architect has a similar job: capture the big picture (e.g. security, environment constraints, composition of services), but note the critical solution qualities (e.g. usability, performance). In the infamous painting, Nighthawks, Edward Hopper uses light and shadows to concentrate viewer’s attentio…

Enterprise Standards

What kind of hardware & software environment exists at company Foo and how do they handle similar challenges? How will organization Foo evolve over time? Few organizations publish their enterprise architecture specifications; after all, a refined purposeful architecture is a competitive asset. But some organizations publish such information. If you search for MS Word or PDF documents for keywords such as “Enterprise Architecture principles”, “enterprise standards”, “to-be EA”, you will find a few valuable resources. One example is an IT Standards document for the US state of Kentucky. The freshness of the resources will vary, but discovering and learning from other organizations is a good way to gain new perspective and judge your organization’s software and enterprise architecture approaches.Constantin K.
Firebrand Architect™