Help » What is a View

What is a View

On Dragon1, a View is defined as a representation of a model in which certain entities, patterns, or situations are emphasized or highlighted.

A view is a visual or conceptual representation derived from a viewpoint.

It illustrates specific aspects of the enterprise architecture, such as systems, data, or processes, tailored to meet the needs of a particular stakeholder or role. filter of a model for certain data entities.

In short: a view is a filter of a model.

An example of a view is: Functionally fit Applications, or Inefficient Business Process.

Such views would filter out / hide all applications or processes that are not functionally fit or efficient.

view

Often, a view is a meaningful aspect or subset of a model.

Other examples of views are:

  • Technically fit applications
  • Standards Compliant applications
  • Cost Heat map application

Dragon1 supports you document and visualize views in the repository, in JSON files and Excel Sheets.

Read more about how to define Views

Dynamic Views

Views can be static or dynamic. Views can be previously generated or real-time generated.

With dynamic views, whenever the data in the model changes, the view also changes.

Sometimes this is required behavior.

Read more about Dynamic Views

Viewpoints

A Viewpoint is a perspective or focus area from which a model or specific subset of the enterprise architecture is examined.

A viewpoint is the (abstract) point or location from which a stakeholder (role-based) looks at data.

A stakeholder has needs and interests because of their experience, expertise, job, or role. So, there are things they find important to see, understand, or know. With views, we can provide that.

Viewpoint examples are: Financial Viewpoint, Risk Viewpoint, IT Management Viewpoint, TAX Viewpoint, Security Viewpoint, Inegration Viewpoint, Privacy Viewpoint.

A view can be linked to a stakeholder and viewpoint.

A financial manager for instance will see different things when looking at an application landscape diagram than a network administrator.

This is all because of the different viewpoints they look at models and diagrams (because of their knowledge, skills, work and interests.

A financial manager might see applications that are too costly and therefore are eliminated.

A network administrator might see the same applications as mandatory for the IT organization, and will advise management to keep these applications.

Architects can visualize these different viewpoints and views into 1 archietcture diagram to help people decide.

Example JSON specification of a Viewpoint
{"class":"viewpoint", "id":"123", "name":"Financial Viewpoint","stakeholders":"CFO,CIO,CEO","interest":"financial aspects of objects","classes","process,application","attributes":"cost,budget,payment","views":"IT cost view"}

With this viewpoint specified, if you select a stakeholder on a visualization or the repository you are shown a list of viewpoints.

If you select a viewpoint, you are show a list of views, etc...

Define Views via Classes, Attributes and Values

Dragon1 supports to create and document views in the repository on top of models and visualizations.

View is technically made available as entityclass in the repository.

On Dragon1, you can specify a view that filters out or lets through certain entity classes.

Suppose you have a diagram showing processes, applications and servers, but you only want to see applications, you can create a view that filters out the processes and servers.

If you provide an attribute and a value to the view specification, then Dragon1 will filter out or only let through data objects that match these attributes and values.

For instance a view that only shows the logistic applications that are in the cloud and used in the office in Amsterdam.

Dragon1 supports you to define one or more views on top of a model or visualization as shown below.

Example JSON specification
{"class":"view", "id":"12345","name":"logistic applications", "modelname":"my enterprise model", "filterclass":"application","filterattribute":"type","filtervalue":"logistics","filter":"in"}
{"class":"view", "id":"12345","name":"cloud applications", "modelname":"my enterprise model", "filterclass":"application","filterattribute":"deployment","filtervalue":"cloud","filter":"in"}
{"class":"view", "id":"12346","name":"Applications used in Amsterdam", "modelname":"my enterprise model", "filterclass":"application","filterattributes":"location","filtervalues":"amsterdam","filter":"in"}

These three views together show only the logistic applications that are in the cloud and used in the office in Amsterdam

Define Views via Relationships

Adding relationships is the second way to define views.

If you specify one or more relationships in a view, Dragon1 will only let through data objects that have a matching relationship.

Example JSON specification
{"class":"view", "id":"12346","name":"Applications supporting financial processes", "modelname":"my enterprise model", "filterrel-sourceclass":"application","filterrel-sourcetype":"*","filterrel-targetclass":"process","filterrel-targettype":"financial","filter":"in"}

Define Views via Rules

Configuring rules is a third way to define views.

If you specify one or more rules, Dragon1 will only let through data objects of a model that match the rules.

Example JSON specification
{"class":"view", "id":"12346","name":"Unused applications", "modelname":"my enterprise model", "filterrule":"application.relationship.count=0","filter":"out"}

View Actionscript

Views can be specified via classes, attributes, values, rules and relationships, but also using action functions.

A full list of can be found here: /help/dragon1-api-action-script

It makes it easy to color, hide, move or highlight objects that mathc certain values.

Suppose you want to color all applications that are functionally view, you use the colorObjects function as below:

Example JSON specification
{"class":"view", "name":"functionally fit view", "actionscript":"colorObjects(application,tags,fit,green);"}