Communicating your ideas and architecture work effectively can be really tough. When we do we using create compelling visuals or models to communicate the complexities of our work. When I talk to architects I find there are many out there that really struggle with getting their messages across to their customers. They also feel that sometimes their communication is just out of their control or the audience just doesn’t get it. Meaning, they should get it, what were they thinking, right?
But is it really there fault? Maybe, maybe not.
The genesis of this post came from a series of recent conversations. I wasn’t sure if I wanted to create this post or not given the topic but in the past two weeks I have wither run into scenarios or have been asked specifically about this topic. The questions were all different but all led to the same basic theme. These questions included:
General modeling questions. What architecture modeling language should we use?
Specific notions. Should we be using ArchiMate notations instead of BPMN and UML?
Assertions about tools. PowerPoint isn’t for architects, Visio or [EA Tool Name Here] is.
For as long as I have been in IT I have seen this. The same debates but with different names continue on. For those that have either worked for me or know me I have had the same answer for some time now. But lets wait on that door a moment…
It’s a funny adaption to a very real situation. I often find my self in a modern day Capulet vs. Montague battle between which is the better way to describe the things we architect.
“What’s in a model? That which we call a Business Capability Model, By any other name would it be as effective to describe our business” – adapted from Act II, Scene II of Romeo and Juliet
There are a couple aspects to this scenario. The first is the tooling. I usually see three camps here. The EA tool folks that use it for modeling, the Visio folks and the PowerPoint folks. Then comes the real holy war, the actual notation. Some say it’s UML, some believe it’s ArchiMate while others just stick to their homegrown methods.
While sometimes interesting to watch, it can be frustrating to watch the debate. What it ultimately boils down to is, while we are having debates about which tool and notation the following isn’t getting done:
Work isn’t getting done.
Decisions are not focused on the right things.
Communication has broken down.
I think we lost our perspective on why we create these rich visuals, models or diagrams. These serve two primary purposes in my mind:
Communication tool to gain buy-in or consensus to support the decision making process.
Facilitate the architecting thought process.
You might say, well Mike, you forgot about all the rich things you can do in the modeling notions that can link aspects of your architecture together in a very qualitative way. I agree these are important and sometimes be game changing if you are at a level of maturity to support it. However, if the two primary aspects are not covered, what you modeled is shelf-ware. If your stakeholders who are paying for your effort can’t buy-into your architecture just for the simple fact that they can’t get their heads wrapped around our world of architecture, we have failed as architects.
A model being used as a communication tool, is the most important aspect in my opinion. This isn’t just my opinion but that of the architectural standard for describing architecture, ISO/IEC/IEEE 42010:2011 or formally known as IEEE 1471. In this standard, there is a core problem we are solving (i.e., Mission) with a set of stakeholders that have concerns that need to be addressed. Those concerns are addressed through the architecture models (i.e., view points, views and models).
The problem we get into is we want our models to be perfect. This may mean a high order of fidelity in the models, highly detailed or have a high level of precision. The challenge here isn’t perfection but that of communication to our stakeholders that have either sponsored (i.e., paid) for our efforts and/or need to buy-off on the architecture before it sees the light of day. Like the quote about truth, “the right model is in the eye of the beholder” or the Don Box quote, “All models are wrong but some are useful”.
So if we agree with the assertion that the critical component of a model is used as a communication method to stakeholders of all different varieties, then let’s consider the following breakdown to not choose the one model to rule them all, but rather a set of fit-for-purpose models that apply to the appropriate audience along with the right situation.
I break the models we create as architects up into two categories and add an additional one as the supplemental repository for ad-hoc models that fit only special circumstances.
Consumers of Architecture Work. These models are specifically designed for the consumers or stakeholders of architecture work. These individuals are different in that they usually not EA’s with that specific discipline knowledge but that of specific business unit areas.
Architecture Professionals. These models are specifically designed for the architecture professionals. They have the EA skills necessary to understand the chosen set of modeling tools and notations for the purpose of communicating, making decisions and facilitating the architecting process.
Supplementary Models. This class of models is used a bit differently than the other two. These are used in an ad-hoc nature to supplement the first and second. While these models are usually more oriented to the architecture professionals they can also include consumer oriented views as well.
Below is a visual that describes this as well:
The reason we want to break these up this way is simple, one set of models you use to communicate directly with your stakeholders or as I labeled them consumers of the models to be a bit more generic. These people who view these models do not have the architectural skills you do nor do they understand the complexities that go into our job. More times than not, it can be determinate to try to educate on the architectural detail as they don’t have the understanding or the experience to fully understand why the decisions were made.
On the other side you have models for architecture professionals. These people are very knowledgeable in the architecture space. More times than not, they are looking for detailed models with a high degree of rigor to understand the impacts the architecture may pose. I have also referred to these people as the “Builder Guild”.
Why call them that? It’s simple really. Just like in other well established profession you will find that the practitioners very different when among their own professionals versus in front of their customers. A great example of this is with home builders. I have built several homes and have had the same experience. I never got a blueprint. I only received a layout with dimensions and maybe a 3D video. Outside that I wasn’t provided anything else. The builder gave me as much as I needed to make a purchase decision with that model and others.
When we reflect back to the problem at hand I would strongly suggest we treat the way we communicate along with the visuals we provide just like how many other very mature professions treat it. If we do that, I think we will be much more effective in our success with our customers.
Mapping back to the structure defined you will see some interesting responses to the questions that were asked.
#1 What architecture modeling language should we use?
It just depends on who you are talking to. A consumer vs. an architecture professional. For an architect perhaps you want to use an industry standard notation like ArchiMate. However if you are talking to one or more people from across your organization like a business unit executive perhaps you want to throw out all those complexities and go straight to either existing visuals that have worked well or build less structured visuals with styles that he/she is accustom to.
#2 Should we be using ArchiMate notations instead of BPMN and UML?
If we build on the first question and assume this question is geared for an architecture or IT audience then it would be the right question to ask. Keep in mind all of these notations are tools in your virtual EA toolbox. Each one of these notations has a role and caters to a specific audience. Each one of these has a discrete audience and purpose. ArchiMate for architecture, UML geared for software development and BMPN built from UML to describe business process more effectively. My advise, don’t try to use one for everything, make sure what you build is fit for the task at hand.
#3 PowerPoint isn’t for architects, Visio or [EA Tool Name Here] is.
I heard this statement more than a few times, with some more negative in tone. My belief here is all three classes of tools are appropriate for the right situation. The tool that seems to get picked on the most is PowerPoint. In my own experiences or have seen / witnessed, there have been very clear successes with using a tool like PowerPoint. Remember, it’s not the tool or the notation, it’s the circumstances and the audience in which you are addressing.
So the final words of wisdom, don’t get caught up in the architecture modeling debate. It’s just a model, get over it. Reverse engineer from what the expectations are from your stakeholders.
コメント