uro's picture

Today I want to share some thoughts with you about data modeling in ARIS, because this topic is frequently discussed here in the community and also is subject of many internal discussions.

The ARIS method provides a broad range of diagram and object types that can be used for data modeling. This leads to a very different usage of parts of our methodology and the outcome of projects with the same objective looks quite different. This flexibility is not a big problem for the customers, on the contrary they like it because they don’t have to follow restrictions and conventions, but it leads to a problem for IDS Scheer as a tool vendor. If we offer such a flexible data modeling method there is the expectation, that we also offer supporting functionalities, accelerators and best practices. This is nearly impossible for a huge number of projects with different modeling conventions.

With respect to this, ARIS development and IDS consultants had long discussions to develop an integrated modeling approach to represent an information architecture in ARIS, mainly covering the requirements from Enterprise Architecture and SOA field.

Very important is the basic concept of three different abstraction layers in ARIS, relevant for data modeling (similar to OMG’s CIM, PIM and PSM):

  1. conceptual – used for classical business and enterprise modeling, independent of any automation or execution aspects
  2. logical – describes a more technical view with the target to automate processes and implement IT architectures, but normally platform and technology independent
  3. physical – used to model the implementation aspects, platform and technology dependent

The following figure shows a part of the ARIS meta model (taken from our SOA methodology) and how the diagram and object types are assigned to these three levels (to reduce complexity not all relationships between the object types are displayed).

ARIS meta model

Now let’s have a more detailed look at the three levels:

Conceptual level

On conceptual level, business terms and business objects are modeled. Here it is important to distinguish between terms and objects.

Terms define only the grammar that can be used to name objects, diagrams etc. including concepts like homonyms and synonyms. For the modeling of business terms in ARIS the object type Technical Term should be used (in a Technical Terms Model). Terms must not be used as input or output objects of process steps, because a term is not an information object! This grammar of course can be used for all elements in ARIS, not only data elements.

Business objects are used to model the data flowing in or out of a process step. They can be related to each other and structured hierarchically, for example to detail them down to an attribute level. Example:

  • Purchase Order Purchase

    • Order Header

      • Contract Number (ID)
    • Purchase Order Position
      • Contract Number (ID)

But keep in mind, everything is a business object.

Business objects may have a state, but they might be implemented later without this state. Business objects without a state generate new business objects, e.g. Customer, New Customer and Old Customer are different objects.

To model business objects in ARIS, the object type Cluster should be used exclusively, for example to attach them to process steps in EPC. The business object hierarchies should be modeled with an IE Data Model.

Logical level

On this level, the logical data models are described. Currently, different notations are used here, e.g. ERM and UML. The preferred way to describe logical data models is to use Entity types and Attributes in IE Data Models. eERM diagrams should not be used any longer, they should be transformed into the IE Data Model format (this is possible without a loss of information).

One way to create the logical data model is top down by transforming the elements from the conceptual level to the logical level. For this purpose our new transformation framework can be used. This further keeps the relation between source element (Business Object) and target element (Entity Type or Attribute).

It is also possible to import a logical data model or to model it manually as part of an as-is analysis and to map these elements to the corresponding business objects at conceptual level. The transformation based and the mapping approach should not be mixed. Of course you can also focus on modeling the logical level but without connection to conceptual elements.

Clusters may also be used at the logical level, but only to define views as partial (or scoped) views to complex logical items.

In future, with our new UML Designer (including good profile support), UML will play an important role to describe logical data structures.

Physical level

The physical data level can be described either using the relational (DDL) or object-oriented (e.g. XSD) paradigm. Elements of the relational description are tables, fields, relations, and constraints. The object-oriented description contains simple and complex types as well as the relations between them.

Although many design tools do not support a graphical description of the physical layer and work directly with the corresponding DDL/XSD files, we think it makes sense to have diagrams in ARIS for that purpose (Table Diagrams for relational description and a UML profile for XSD representation). Only if these elements are part of the ARIS repository it is possible to do analyses or to transform and map with other elements in our repository. But if there is an external (outside of ARIS) source for physical data description, we consider this source as the master for the data.

Conclusion

With the introduced abstraction layers we hope to make the data modeling in ARIS more transparent as in the past. The different other ways offered by our methodology will be available in the future, but new functionality in our standard products (transformations, imports, exports, search…) will be based on the object and diagram types described above.

I’ve ignored to discuss in this article how a data exchange between IT systems has to be modeled in ARIS. This is currently subject of discussions within the IDS Enterprise Architecture and SOA team. When we have a result it will be brought to you directly.

I’d appreciate to get response here in the community and assure you to take your requirements into account for our future activities.

Tags: ARIS soa