Hello fellow architects,

In my work as an enterprise architect I create a lot of architectural views for management, directors and boardroom members.

My experience is that when creating an architectural visualisation I focus on _meta_phorizing principles and then draw the _meta_phores I found.

Sometimes I don't need to find a _meta_phore, and is it possible to re-use reference models of concepts or standard patterns making it clear what principles are there or needed.

The views I create are much appreciated by my clients. They often find them representing their vision.

I find that there is little need to focus on demands or requirements of the stakeholders and to draw them.

This is, I think, because the principles chosen allready enable the demands and requirements of the stakeholders. And when looking at the visualisations people "run their demands requirements through the view" to test the principles.

I was wondering if other people have the same experience?

With kind regards,
Mark Paauwe

I believe this has much to do with the topic at hand. Presenting IT architecture for business management is in most case a challenging task. A visualisation is often prefered, but raise a lot of issues as the audience might not be as IT savvy as an average digital architect often assumes.

To get a better understanding of your statement ('little need to focus on demands') it would be nice to see a few examples of your visualised principles. In general I reckon that verbal statements without any visualisation fall short. But by leaving the problem at hand (requirements vs. constraints) implicit is tricky I guess. To make sure that decision makers have a correct understanding of the way forward (guided by principles) they should probably also share the context and understand the trade offs.

Hi Mark,
You are right and yes, well communicated principles will make further 'specification' unnecessary. Architects address the behavioural aspects (wanted, predicted behaviour). Since the value-chain of behaviour is: Principles --> Insights --> Rules --> Behaviour, wll-defined principles will function as a guide throughout the chain or, as you said, "... enable the demands and requirements of the stakeholders" without further specification. The architectural / infrastructural principle "drive at the right hand side of the road" and its powerfull impact down the value chain without further specifications may function as an acceptable 'proof' of the correctness of your experience.