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