Today I was asked a series interesting questions in regards to why architects are so insistent on collecting models. He asked with passion, why there was a need to capture information from across the enterprise in a systematic way. Of course it didn’t help that there was the beginnings of an architectural current state analysis and road mapping exercise on my whiteboard and posted on my wall.
This led into a series of very challenging questions posed:
- Why would you build a model/picture of an environment or set of systems when you could just walk down the hall and talk to the person that wrote it?
- Isn’t a model subject to interpretation?
- If the architects in the company are looking at these models and making decisions how can we be sure they are making the right ones based on potential inaccuracy of the models.
After talking for about an hour about this I was able to finally get to the source of all the questions. As a developer, this person felt that architects and technical decision makers in the organization would take these models and make decisions in isolation and potentially abused on false information that would in turn potentially impact the developer in a negative way. Now we are getting somewhere… We have a case of Fear Uncertainty and Doubt or FUD. But, this fear is a common fear, especially if the organization has gone from little to no architecture maturity to the very beginnings of a structured architecture discipline.
So we have some FUD here, is this unfounded? Absolutely not. Believe it or not, sometimes architects over engineer or model an application, solution, platform or an enterprise in a less than optimal way. Sometimes downright inaccurate way. So is it fair to be worried, YES!
So this is where we actually get into why I label the post the way I did. So in the analogy, “A Fool with a Tool, is still a Fool” we have a direct correlation with this scenario.
When we look at the “Tool”, it would be the architectural artifact. This could be an architecture description, a model or a set of data supporting a solution.
The “Fool” or potential fool is either the creator or the end user of the specific artifact. Let’s just say that it is an architect for a moment. The architect who is going to use this tool or architecture model for a very specific set of purposes. One being, to make decisions.
For example, if the architect is going to use this information to make decisions it is the responsibility of that architect to think about the following questions:
- Is this the right model I should be basing by decisions off of?
- How accurate is the information displayed in the model? If unsure, ask someone.
- Understand the following principle “all models are false but some are useful”. Models that are created will sometimes have interpretation of a problem built in. As an architect you need to know how to quickly identify these areas.
- What was the created date?
- Are there tools and mechanisms that keep the information refreshed and thus the model can be trusted better.
- Finally, don’t be afraid to ask a lot questions!
What about these initial questions around the validity of the architectural approach? Has anything changed? Do we change the way we make decisions? No you do not. All of these questions center around information quality and collaboration. These are core tenets of good architecture practices. Models are extremely useful if used properly. However, we always need to be mindful of the fact, garbage in equals garbage out. The architecture model is only useful as the diligence that went into it, the maintenance of the information and that it is verified as valid ongoing.
The focus on the model specifically is actually the wrong center of focus. The center of focus should actually be on the user of that model. Let’s change the scenario and say that the model is actually 100% accurate. However, the architect that uses it isn’t the most seasoned and makes bad decisions off of a very accurate model. Where is the breakdown?
At the end of the day, the best tools still need a qualified operator. That is the essence of the analogy and why it applies so much to this scenario.
So if you are not challenging and following models blindly, yes, you are the fool in the scenario. But if you understand that architecture artifacts are just one tool in the toolbox and those tools need to be sharpened, tuned and even sometimes upgraded you’ll be just fine.
