Minimalist Architecture

Big Failures
When a bridge or a building fails, who do we hold accountable? If it is a problem with the design, then clearly we look to the architect. We expect the architect to have ascertained the requirements correctly, and to have designed a solution that addresses the requirements. We do not excuse the architect if failures occur because the requirements were not properly understood, or if the interaction among requirements was improperly accommodated.

Wind-induced vibrations caused the Tacoma Narrows suspension bridge to collapse; Clark Eldridge was responsible for the initial design, which was modified by Leon Monseiff to reduce costs. Eldridge accepts some of the blame for the bridge’s failure. [1]

Pedestrian motion caused vibrations on the London Millenium footbridge resulting in the bridge being closed 3 days after opening for several months, and retrofitted at a cost of Ł5 million (the total cost, then, being Ł23.2 million, or Ł7.2 million over budget). Arup (structural engineer), Foster and Partners (architects) and Sir Anthony Caro (sculptor) are accorded honor for the elegance of the design, and some degree of derision for its failure (Foster is known by the British tabloid newspapers as "Lord Wobbly", due to structural problems with the footbridge design). [2]

The Economist reports that the IRS wrote off $4 billion on the failed Tax Systems Modernization (TSM) initiative. Software Magazine reports an $8 billion write-off. What is more, the IRS restarted the TSM initiative with an expected cost of $10 billion, and an annual budget of $500 million. With some sleuthing, we find that Richard Spires replaced Fred Forman as head of the IRS Business Systems Modernization effort on September 17, 2004. Reading between the lines, we might come to the conclusion that at least Forman was not viewed as a success. There is no mention of the chief architect.

A Ł5 million bridge debacle and we know who is accountable. A $4 billion to $8 billion debacle in computing systems and we have to work to find out who managed the initiative, and find no mention of the architect(s) involved. More work and we could scratch this up, presumably. But the point is that the press is not naming names. It is true, too, that system architects are not being awarded honors or knighted (“Lord Wobbly” was knighted in 1990) for their successes.

Accountability

This raises an interesting question: should we hold architects responsible for their architectures, so they succeed along with their architectures, and face a career threat when the tracks of failure lead clearly back to them.

When a product fails to measure up to expectations, who do we think is accountable? How about a humidifier that is impossible to fill without getting wet? The problem is localized to one component yet I doubt I am alone in looking to the architect to step to the plate and take the dousing.

How about a BMW 7 series that requires a special instruction booklet in the glove compartment so that valets will be able to park it ([3] Rust et al, 2006)? This is a usability issue, but again I would look to the architect as having overall responsibility for driving feature/usability tradeoffs.

When the business sets direction and IT fails to align with that direction, with debilitating impedance mismatch between the computing systems and the business processes they are supposed to enable, who do we hold accountable?

We would like to say the product, the system and the enterprise architects are accountable. But herein lies the rub: in the examples above, was there an architect? If so, was the architect (or team of architects) responsible for the design, or simply a consultant, giving advice? And was the architect chartered with understanding stakeholder requirements and negotiating the tradeoffs between cost, features and properties of the system? Cost, features and properties interact, yet they are often treated as a requirements consideration driven by business analysts or marketing and passed over the wall to the architecture team at requirements sign-off.

Authority before Accountability

Understanding the problem to be solved is an act of interpretation, and this is best done by the person or team who understands the interaction between what is possible, at what cost, and what is needed and desired. Tradeoffs must be made on both sides: the user faces a utility envelope where there is a tradeoff between features and properties, and cost or timing; and on the development side, where there is a tradeoff between features and properties on one hand and complexity driving cost and development time on the other. These are not best dealt with as separate balancing acts, yet this is what many organizations are forcing, by separating requirements specification from architecture design, and creating separate islands of activity to create these two bodies of work.

When we stand back from the problem, we know that, for example, within certain parameters a capability may be reasonably cheap, but beyond those parameters the cost may be an order of magnitude more. We do not expect the system user or business analyst to be aware of these factors; we expect the architect to be aware of them. Yet we do not typically charter the architect with leading the product definition phase and integrating product definition (requirements specification) with architecture definition. In the building architecture field this separation would be considered ludicrous, I'm sure.

It is in vogue to say the architect is "the ultimate design authority," but what is generally meant is that the architect is the design guru who developers can go to for advice, not that the architect has authority over design decisions. We need to get to the point where the architect really does have authority over design decisions before we can hold the architect accountable.

Once we are clear about what the architect is responsible for, we are also clear when the architect is not responsible, in particular when he has been overridden by higher powers, or when his design is compromised by failure of a component to perform to spec. Remember, Eldridge only assumed “some of the responsibility” for the Tacoma Narrows disaster, but he was not responsible for drawing tight lines on cost nor the decision to go with Monseiff’s cost-reducing modifications to his design.

References

[1] http://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge

[2] http://en.wikipedia.org/wiki/London_Millennium_Bridge and http://en.wikipedia.org/wiki/Norman_Foster

[3] Rust, Roland, Debora Thompson, and Rebecca Hamilton, "Defeating Feature Fatigue," Harvard Business Review, February 2006.

This column is taken from Ruth Malan's (almost daily) architecture journal, entry date: 2/24/06.