The focus of this approach is on a business process, like the one shown in the following figure.

The process is triggered by the Customer order received event. In turn, this event activates the Accept customer order function (procedure). For this procedure to be performed, the current state of the relevant process environment must first be described. In particular, this includes data relating to customers and items. The state of associated objects may change during workflow processing, for example, when the items' inventory data is updated with the new reservation data.

The procedures are performed by sales employees who can be assigned to departments. Departments use specific information technology resources (personal computers, printers, etc.) to perform their tasks.

Once the Accept customer order procedure is completed, the Order is confirmed event occurs that in turn may trigger other procedures, such as Track order or Create production plan. The Order object is now in a new state because the Order received object has become an Order confirmed object. Carrying out the Accept customer order function has generated a product/service that is used - in combination with human and technical resources - as an input for processing subsequent procedures.

The components required to provide a full description of a business process include procedures, events, products/services (states), users, organizational units, and information technology resources. Covering all effects on all elements of every procedure under consideration would result in a rather complex model and lead to redundancies in the description.

To reduce complexity, the general context is broken down into individual views (see the following figure) that represent specific modeling and design aspects (see Scheer, Architecture of Integrated Information Systems, 1992, p. 13 et sqq.). These can be processed independently. The views are broken down in such a way that relationships between the components are rather numerous within a single view, while there are only relatively few relationships between the various views.

Events, such as Customer order received or Invoice created, represent the fact that the state of information objects (data) changes. Events are described in the data view of the ARIS architecture.

The states that exist in the objects' environment, for example, within the scope of the customer order, are represented by products/services. The term product/service refers to the supply of either goods or services. Services that create and provide information are information services. Products/Services also include the provision of financial resources. Relationships between products/services are described in the ARIS architecture's Product/Service view.

The functions to be carried out (procedures) and their interrelationships form a second view, the Function view. It contains the description of the function, an enumeration of individual subfunctions that are part of the overall context, and the relationships that exist between the functions.

The Organization view subsumes users and organizational units, as well as their relationships and structures.

Information technology resources constitute the fourth area of consideration, the so-called Resource view. However, this view is significant for the technical consideration of business processes only insofar as it provides general conditions for describing other components that are more directly geared toward business management. For this reason, the components of the other views (Data, Function, and Organization view) are described in terms of their proximity to the information technology resources. Thus, resources are dealt with at the design specification and implementation level of the other views (see chapter Descriptive levels). The lifecycle model that is defined as a result of the descriptive level approach replaces the resource view as an independent object of consideration.

While breaking down the process into individual views reduces complexity, the process component relationships across the views are lost. For this reason, the Control view is provided as an additional view for describing the relationships between views. Combining these relationships in a separate view allows for systematic and redundancy-free recording of all relationships.

The control view is an essential component of ARIS. It is the fundamental feature that distinguishes the ARIS concept from other architecture approaches (for comparison with other architecture approaches see Scheer, Architecture of Integrated Information Systems, p. 24 et sqq.).

Thus, there is a total of five ARIS views, which form the basis of the following method descriptions.