Sometimes, the architect is not really relevant.

For architectural purists, this is a shocking thing to say.  To them, I’d say that teams can choose to ignore their architect.  In fact, in some situations, they are REQUIRED to ignore their architect.  (case in point to follow).  If that is the case, then creating a model, or delivering a review, is pretty pointless.

When are teams required to ignore an architect?

I’ve come across two situations.  Perhaps there are more.

1. When the process used to select projects, fund projects, collect requirements, etc, has no mechanism for involving an architect. 

If an architect delivers a model in this environment, it MUST be ignored because there is no team that is expecting to receive the model, or trained to understand it, or governed by alignment with it. 

2. When the architect has stated goals that conflict with the desires and preconcieved notions of powerful people.  If a person is used to funding IT projects without regard to anyone else’s wishes, and he finds out that an architect is saying things like “build for the enterprise” or “create fewer, simpler, more consistent solutions,” he can simply refuse to cooperate with the architect.  The architect is outside the meeting loop, outside the process. 

Delivering a model in this environment is pointless, because the team dynamics are oriented to listen only to the “customer” even though the money comes from the corporation, and the customer may not represent the corporate interests. 

In both cases, the folks involved in development are not being mean or malicious by ignoring their architect.  They are following the ‘rules’ that exist in the environment.  They have no choice.

So if you find yourself in this situation, don’t create models.  You will be wasting your valuable time.  Work on the real problem.  Find the support you need to connect the process up, so that architecture has ties into project funding, and a recognized voice in project delivery. 

Architecture makes lousy (and expensive) shelf-ware.