ARIS: A Framework for Enterprise Description

ARIS (ARchitecture for integrated Information Systems) has been developed in Saarbrucken (Germany), in 1992, with the main aim of providing an architectural framework for enterprise description. The ARIS framework is structured in terms of five different views (Organization, Data, Control, Function and Output) and three abstraction layers (Requirements Definition, Design Specification and Implementation Description). While the division in abstraction levels allows one to capture the information about the enterprise in different granularities, the viewpoints aim at specifying details referring to each organizational aspect.

The Organizational View describes the hierarchical structure of the organizational units, its relationships and responsibilities. The organizational structure defines the competencies realms of the organization, indicating its specialties areas and allowing one to identify the hierarchy of roles. The main purpose of this viewpoint is to provide subsidies to strategic decisions, such as how to aggregate similar organizational functionalities so that they can be assigned to organizational units, conversely, how to aggregate roles in specific units according to the functionalities required by these units or by the business process which these units execute.

The Functional View defines the organizational functions which can be described in various aggregation levels in a hierarchal way. Functions designate activities or tasks which must be executed for the production of some good. The term is not defined generically, but is used synonymously with the terms process, activity or task. The name of a complex function is also used for the designation of a business process (Scheer, 2000).

The Data View describes the business information that is manipulated by functions. The data objects have several roles in the flow of business process, such as: describe the events and messages which control the flow of business processes, describe the environment status of business process, represent the outputs produced by activities and so forth (Davis, 2001).

The Control View describes the transformation of information within business processes through a function or a set of functions. Since these functions represent potentially complex organizational tasks, the control view is used for modeling business processes into ARIS. The purpose of this view is to integrate the remaining views of the language (Functional View, Organizational View and Data View) which have been separately modeled. This promotes the description of the state modifications and consequently, the description of dynamic behaviour of processes which manipulate information and other kind of objects previously modeled in other views. Therefore, the Process View provides the linkage among all the enterprise views.

The main models involved in the Process View are: the Value Added Chain (VAC) model, the Event-driven Process Chain (EPC) model and the Function Allocation Diagram (FAD) model. This separation allows one to manage the complexity of modeling as well as the integration among the views. Among these models, EPC models can be considered the most important models since it captures the enterprise procedures, highlighting how the enterprise intends to achieve its strategies.

The importance of EPCs in the practice of business process modeling can be attested by the existence of several successful commercial tools which offer support for these diagrams, e.g., IDS Scheer’s ARIS Toolset, Microsoft’s Visio and BOC’s ADONIS. Further, EPCs have been used in the documentation of the widely-employed SAP R/3 enterprise resource planning system, which has led to the SAP Reference Model with over 600 EPCs (Mendling, 2008).

ARIS provides both components for creating enterprise descriptions: first, it provides a modeling language to capture enterprise models and second, it provides methodological support for the construction of these models, having a large market share due to its integration with the SAP suite in the corporate and government sectors. This acceptability and leadership in the business community can be accounted by the fact that it provides support for modeling several aspects of complex business models (including processes, data, organizations, systems and so on), support for modeling software systems (using UML) as well as other technical advantages (such as windows compliance, rich functionality and configurable for user requirements, support for business objectives, measures and balanced scorecard, among others)(Davis, 2001).

More information about ARIS products can be found at

http://www.ids-scheer.com/international/en

by Evellin & Paulo

References:

Davis, Rob. 2001. Business Process Modelling with ARIS - A Practical Guide. Springer, 2001.

Mendling, Jam. 2008. Metrics for Process Models, Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness. Lecture Notes in Business Information Processing (LNBIP). Springer-Verlag, Vol. 6, pp. 17-57.

Scheer, A. W. 2000. Aris – Business Process Modeling, Springer.

Archimate: A Service-Oriented Framework for Enterprise Architecture

ArchiMate is a modeling language for describing enterprise architectures which presents a clear set of concepts and relationships between architectures domains, and offers a simple and uniform structure for describing the content of these domains (The Open Group, 2009).

The language has been developed in the ArchiMate Project which lasted from July 2002 until December 2004 in a broad consortium from industry and academia (comprising ABN AMRO, Stichting Pensioenfonds ABP, the Dutch Tax and Customs Administration (Belastingdienst), Telematica Instituut, Ordina, the Centre for Mathematics and Computer Science (CWI), the Leiden Institute for Advanced Computer Science (LIACS), and Radboud University Nijmegen ) with the aim of providing a visual design language with adequate concepts for specifying interrelated enterprise architectures. 

The design of the language has been guided by the issue that managing the complexity of the organizations requires the description of the language in terms of several domains of knowledge as well as the relations within these domains. Therefore, the main goal of the language is to promote the integration of the several viewpoints of the organization, albeit it is not intended to introduce a language that can replace all existing domain-specific languages. 

The central characteristic of the architecture is the service orientation. According to (Lankhorst, 2005), “services are defined as the unit of functionality that some entity (e.g. s system, organization or department) makes available to its environment and which has some value for certain entities in the environment (typically the “service users”)”. The service orientation proposed in the ArchiMate enables a layered view of the architectural models, where the concept of the service is one of the main linking between the different layers. The service layers which the services are made available to higher layers are interleaved with implementation layers that realize the services. Within a layer, there may also be internal services.

The language distinguishes three main layers (abstraction levels): the Business Layer which offers products and services to external customers realized by business processes executed by actors or roles; Application Layer which supports the business layer with software applications services; and Technology Layer which offers infrastructural services for software applications (composed by software systems, computer and communication devices). Each of these layers can be decomposed in sub-layers. However, the level of abstraction must be chosen according to stakeholders concerns. 

In the structural/behavioral dimension, the behavioral concepts are assigned to structural concepts to show who or what displays the behavior. The structural concepts are in turn refined in active structural elements (concepts which indeed display the behavior) and passive structural elements (objects in which the behavior is applied). For instance, in the business layer, roles, interfaces and collaborations (structural concepts) are assigned to business processes, business services and business interactions, (behavioral concepts) respectively. 

Concerning the second dimension, there is a distinction between the external view and internal view. The external view is concerned about the functionality (and its associated non-functional aspects) which are exposed to the environment, whereas the internal view refers to internal realization of the services. In the internal realization of the services, the behavior may be performed by an individual structural element (e.g. actor, role and component) or by a collective structural element (collaborations). From an external perspective, it is usually irrelevant whether a service is realized by individual or collective behavior. Services are accessed through interfaces, which constitute the external view of the structural aspects. 

The language puts emphasis on concepts which captures the design and realization of the organization, without however providing concepts for capturing the intentional aspect (goals, strategies, policies and so forth). This “intentional dimension” is indispensable in the sense that it captures the principles which govern the design process for creating the enterprise as well as the translation of the abstract definition to the actual architectural implementation.

by Evellin & Paulo

References:
Telematica Instituut. 2009. Archimate Resource Tree. http://www.telin.nl/NetworkedBusiness/Archimate/ART/. [Online] 2009. .

The Open Group. 2009. What's ArchiMate. http://www.archimate.org/. [Online] 2009. http://www.archimate.org/en/about_archimate/what_is_archimate.html.

Lankhorst, Marc. 2005. Enterprise Architecture at Work - Modelling, Communication, and Analysis. s.l. : Springer-Verlag, 2005.

Important links for Archimate:

http://www.telin.nl/NetworkedBusiness/Archimate/ART/

http://www.archimate.org/

http://www.bizzdesign.nl/joomla/ (unfortunatelly, it is written in Dutch)

A Big Picture About Enterprise Architectures: Why do we need them?

The increasing competitiveness drives organizations to promote change in an attempt to improve the quality of the services and products they offer. In recent years, many of the efforts related to managing change in organizations have been conducted in the scope of Business Process Reengineering (BPR) activities (Hammer, et al., 1993) (Hammer, 1990). BPR is based on the assumption that change in business processes should generate radical improvements in critical performance measures (such as cost, quality, service and speed) (Hammer, et al., 1993). Moreover, it is believed that implementing radical changes in business processes is the way to achieve dramatic and satisfactory results (Hammer, et al., 1993) (Hammer, 1990).

However, predicting how a given enterprise environment should respond to changes by simply adopting a business process centered view is unfeasible since there are a large number of issues to be considered, such as infrastructure, power and politics, managerial control, organizational culture, among others (Yu, 1995). In turn, these issues provide potentially conflicting quality criteria whose prioritization (or postponement) impacts in the performance of the organization as a whole.

To properly address the interconnection among these factors in organizations often requires the utilization of an enterprise architecture. An enterprise architecture comprises in “a coherent whole of principles, methods and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure” (Lankhorst, 2005). Thus, the insights provided by enterprise architectures help overcoming the difficulty of managing organizations, allowing the determination of needs and priorities for change a given business perspective (Jonkers, et al., 2006).

By Evellin & Paulo


References:


Hammer, M. 1990. Reengineering Work: Don’t Automate, Obliterate. Harvard Business Review, 1990.


Hammer, M. y Champy, J. 1993. Reengineering the Corporation: A Manifesto for Business Revolution. London, England. Nicholas Brealey Publishing.


Yu, Eric. 1995. Modeling Strategic Relationships for Process Reengineering. PhD. Thesis. Departament of Computer Sciences, University of Toronto.


Lankhorst, Marc. 2005. Enterprise Architecture at Work - Modelling, Communication, and Analysis. Springer-Verlag.


Jonkers, Henk, et al. 2006. Enterprise architecture: Management tool and blueprint for the organization. Information Systems Frontiers, Springer. Netherlands.