Architect's Role in Dealing with Complexity
Related White Papers
For more on Architecture Action Guides see
For more on Architecting see
Architects and Accountability
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. 
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). 
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.
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 ( 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.
 http://en.wikipedia.org/wiki/London_Millennium_Bridge and http://en.wikipedia.org/wiki/Norman_Foster
 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.
Restrictions on use: All material that is copyrighted Bredemeyer Consulting and published on this page and other pages of our site, may be downloaded and printed for personal use. If you wish to quote or paraphrase fragments of our work in another publication or web site, please properly acknowledge us as the source, with appropriate reference to the article or web page used. If you wish to republish any of our work, in any medium, you must get written permission from the lead author. Also, any commercial use must be authorized in writing by Bredemeyer Consulting.