What process gives a tool to a fool?

Mike Walker recently blogged about the veracity of architectural models, and the precautions that should be taken to insure that an architectural model is actually accurate and correct before it is used to make decisions.  (see A fool with a tool is still a fool).  Mike points out some very good points about how the architect using the model should be certain of its accuracy before making decisions on the basis of it.

I would add, however, that there is a deeper problem, and one that Mike did not address.  Why does the organization trust the architect to make decisions on the basis of a model?

That is not to say that a model cannot be useful.  It certainly can be useful for illustrating intention and for capturing information in a manner that is readily usable for other purposes.  However, there are two kinds of decisions that can be influenced by a model: technical decisions and portfolio decisions.  Technical decisions answer the question “does this model reflect a good way to solve this problem?” Portfolio decisions answer the question “if not, what are we going to do about it?”

Who is responsible for these decisions?

Technical: I have no problem with an architect making a recommendation to an empowered development team or group, on the basis of a model, that a particular aspect of their work should change.  However, even for that technical decision, I’d wonder about any team that didn’t invest, in the dev team itself, the right to challenge that decision.  An empowered dev team will question any architectural decision that appears dumb.  (They will challenge the smart decisions, too, but that’s another point).  If, during that challenge, the architect produces the model, the dev team can say “but the model is wrong.”  At that point, the discussion and correction of the model may result in a change in the advice itself.  The system is self correcting, as long as the architect is working with an empowered development team.

Portfolio: no architect should be responsible for making portfolio decisions.  They may be accountable for making recommendations, but at the end of the day, there should be some governance or steering committee of business leaders (or a single business leader) who is accountable for spending money.  That person is nearly never the architect.  If that person is the architect, then the process is broken, because the architect is a poor choice for managing the portfolio.  There’s an inherent conflict of interest in that situation. 

So, if the process requires the architect to manage the portfolio, then the process will inevitably make a fool out of any architect.  In that case, don’t fix the model… fix the process.

But back to Mike’s concern: what if we make a bad portfolio decision on the basis of a bad architectural model?  Well, sure, we don’t want to do that.  But the alternative is not to drop the concept of modeling.  That would be equivalent to saying “missing data” is better than data that is “90% accurate.”  As Mike correctly points out, “all models are wrong… but some models are useful.”  We need to figure out how accurate a model must be in order to actually be useful.

Making architectural decisions without architectural models is driving a fast car with our eyes closed.  Making architectural decisions with inaccurate models is driving the same car in a heavy rainstorm. 

I’ll take the latter every time.