Architects like using Diagrams

When ever you talk to an architect (architect or technical) the first think most want to is draw something - usually some boxes with lines. These diagrams could be as simple as simple canvas views or as complex as detailed reference models or designs.

In an organisation with many people doing this and with many existing assets it is kind of useful if the boxes and lines relate to common concepts and assets. That is to say that if I draw a diagram which represents a new offering or service, for some markets, that relies on some offerings and assets (existing and new) - and someone else draws a similar diagram referencing some offerings and assets it is useful to know what is being referenced. So simple diagrams that don't link to each other or what exists (and all other diagrams) are not that helpful to enterprise (though they may service completely adequately the use of the author).  Further when I have a drawn a diagram in ad-hoc fashion that references things (i.e. laying things out in particular way), it is useful I can create a template without any further knowledge or skill for reuse by others.

So we believe the following characteristics are critical for such approaches to diagramming in an enterprise:

• portal based: to allow anyone in a distributed enterprise to access the data from anywhere, anytime on anything.
• simple for ad-hoc user: the reality is that the alternatives are a whiteboard or a simple drawing tool, and if a solution is much more difficult to use than this it won't be used, so it needs to be intuitive and easy to use.
• allow templates to be created on the fly: I need to be able to say this diagram will now be a template 
• allow data sets to be defined on the fly: I need to be able to say the data set in this diagram will be used elsewhere e.g. in other diagrams, in BI views etc.
• affordable for universal use:  because many people in an organisation need to be able to draw diagrams from time to time so 
• presenting data: allow the representation of data in repositories (which may in turn aggregate, collate that data from many other sources). This also helps ensure consistent semantics.
• control appearance based on data: allow the appearance of things to be changed based on properties of the underlying data and allow some common enterprise visual language to be used. 
• allow the underlying data to be updated: when in the course of drawing a diagram I see something wrong I need to be able to fix it.
• accessible to BI solutions: What architects don't usually draw are BI outputs, but the data in their diagrams need to be able to presented using these techniques

See also EA vs EPM

EAs need to communicate why decisions are made, by whom etc.if they want buy in

Understanding the rationale improves compliance

Enterprise Architects are often in a role of trying to get compliance with a set of decisions (or rules). If people can't see the rationale for the decisions, and it is not clear that their concerns and issues have even been considered, then they are unlikely to respect them (unless the penalty for not respecting them is severe).

The nature of any decision in a complex domain (from highest level strategies to the lowest level decision on  a technical or operational approach) is predicated on a set of goals, factors and beliefs. If we can as much as possible make the basis of the decision clear we can improve the chance of compliance or buy in.

Goals and principles

Any rule must be predicated on achieving some goal (otherwise it would have no purpose). Principles to some extent often reflect a class or kind of goals.

Patterns are decisions

Patterns also reflects sets of design decisions. All design involves trade offs. Explaining the thinking (goals/princioples, factors and beliefs, etc.) will assist in people understanding what patterns fit their circumstance.

The world changes

The other consideration is that we live in a changing world. Goals, facts and beliefs change. If we adopt a religious approach to following decisions or rules without being able to inspect their predicates we are unable to determine if a decision/rule that once made sense remains sensible.

If we record the key goals, factors and belief and how they relate to decisons/rules we can understand the impact of a change e.g. if a goal become more or less important, a factor changes etc.

It is for these reasons that in our solutions relating to managing quality (consistency, best practice, etc. including:reference models, decisions on reference models, patterns, principles etc.) that we seek to get the rationales recorded.