Selected information about the system from a point of view and with a specific purpose

Introduction to the notion

Whereas the reality, in our approach, organizes itself into clearly distinct aspects, the same cannot be said for how the observer or actor sees things. Some aspects are difficult to grasp because they are abstract. Others have a counter-intuitive position, which can only be understood from architectural requirements. Spontaneous perception mixes different types of elements. For example, an expression of needs will mix operating logic with operational requirements; it will contain organizational presuppositions but will remain silent on the motivations behind the operations. This expression is therefore incomplete and mixed up at the same time. The elements have to be separated according to type to be included in a usable order. That said, it is not a question of getting rid of the expression of needs: it remains an essential means of communication. The same applies to the many documents and representations that we cannot directly include in the Enterprise System Topology but that concern elements of one or several aspects, to present them in a communication context. The views satisfy this communication need.

A view requires an actor looking at something. It provides access to part of the reality observed, from this actor’s point of view. It is therefore a subjective view: the subject’s particular situation faced with the reality. The advantage of a view is for communication as it develops, rightly so, against the needs and language of a particular kind of actor. The price to pay is a certain degree of confusion:

  • the views overlap as several types of actors have to know about the same elements;
  • the views are incomplete as they are limited to the need for knowledge and possibilities of understanding of a type of actor, sometimes at a given moment;
  • the views can encourage confusion because they mix different types of elements, sometimes within a same sentence or representation.

In practice, a view is made up of a selection of elements taken from one or several aspect models. For example: the “Use view” and the “Organization view” are both representations of the pragmatic aspect, one focused on a local stake, the other covering the whole of the organization. A “business view” will combine elements taken from the intentional aspect, the business aspects (semantic, pragmatic and geographic), but also from the logical aspect (to arbitrate the investments) and from the software aspect (mock-ups in particular).

The content, the form and the vocabulary of a view are adjusted to the recipients’ profile.

From an actor typology (contracting owner, organizers, strategists, IT workers, subcontractors, etc.), we define the views, which can take elements from one or several aspects.


The view is a complementary notion to that of aspect. Praxeme’s representation framework, the Enterprise System Topology, accords more importance to the notion of aspect, as it alone enables us to respond to the architectural requirements that apply – or should apply – to any representation framework. The framework structures the enterprise description repository, that is to say a considerable mass of information and decisions. It is important that this structure removes redundancy and makes it easier to use the information. If we only have views to help us organize the information, the weaknesses mentioned above would destroy any hope of mastering the repository or would prohibit any in-depth or detailed modeling work. We would be obliged to limit ourselves to general representations, in other words vague, as it would not be possible to base them on any detailed knowledge. Decisions would be made blindly, without any serious estimation of the impact they would have, as they would not be guided by any detailed analysis.

Related terms: actor, aspect, model, point of view.


Related - items

About Dominique VAUQUIER

Créateur et auteur principal de la méthode Praxeme. Consultant : accompagnement de transformations, modélisateur, architecte métier, architecte logique (urbaniste de SI). Formateur : BPMN, SOA, Praxeme, modélisation.
Bookmark the permalink.

Comments are closed.