As mentioned earlier, the ARIS resource view is replaced by a lifecycle concept of an information system's descriptions.

Lifecycle models in the form of level or phase concepts describe the lifecycle of information systems. However, the ARIS lifecycle model is not to be understood as a procedure model for developing an information system. It rather serves to define the various descriptions that differ in their proximity to information technology.

ARIS uses the three-tier division shown in the following figure (see Scheer, Architecture of Integrated Information Systems, 1992, p. 16 et sqq.).

The focus of this approach is on the business management problem. The description lists rough facts that focus very closely on technical objectives and technical language. The options that information technology provides for supporting business management processes and decisions are also included. Therefore, only semi-formal description methods are used for representation purposes. Because of their lack of detail and their highly technical vocabulary, these description methods cannot serve as a starting point for a formalized implementation.

Thus, a Requirements definition has a rather formalized description language to describe the business management approach to be supported, so that it can be used as the basis for consistent transformation into information technology. This procedure is also referred to as (semantic) modeling. The requirements definition is closely associated with the business management problem, as indicated by the width of the arrow in the following figure.

Applying the requirements definition's concept to the design of IT systems leads to the Design specification level. Here, the modules or transactions that carry out technical functions are defined, not the functions themselves. At this level, the requirements definition is aligned with general concepts used in information technology. However, the requirements definition and the design specification are only loosely coupled. This means that a design specification can be changed without affecting the requirements definition. However, this does not imply that requirement definitions and design specifications can be developed separately from each other. In fact, once a requirements definition is complete, the business management-related topics should be specified in such a way that purely IT-specific considerations, such as the information system performance, do not have any impact on the technical content.

At the Implementation level, the design specification is transformed into functional hardware and software components. This establishes the link to information technology.

The descriptions have individual update cycles. The update frequency is lowest at the requirements definition level and highest at the implementation level.

The implementation level is closely coupled with information technology development and is subject to continuous change as a result of rapid innovation cycles in information technology.

The requirements definition level is of particular importance because it serves as a repository for the long-term business management approach and, at the same time, is the starting point for further steps towards technical implementation. Requirement definitions have the longest lifecycle and – due to their close proximity to the business management problem – also document the technical benefits of the information system. For this reason, the view that deals with developing requirement definitions or semantic models is the one with the highest priority. Semantic models build the bridge between users and the initial translation of their business management problem into an IT-related language.

The combination of views, descriptions, and business management solutions forms the essence of the ARIS concept. As shown in the following figure, each descriptive view is broken down into the Requirements definition, Design specification and Implementation level.

The ARIS concept sums up the relevant objects or areas of consideration as defined by the architecture's descriptive views and levels. Including the business management problem, which is the focus of this approach, this gives rise to a total of thirteen components. In a next step it is necessary to select and explain suitable description methods for each object or area of consideration.

The criteria for selecting these methods (see Scheer, Business Process Engineering, 1994) include:

Individual methods applied to the objects or areas of consideration are described in the following chapters.