Technical term - IE Data model How do I make it work?

Scott, great to see You to apply ARIS in data modelling also, in addition to process modelling. ARIS enables both, this being one of the most important differentiators and advantages ARIS has. The business language consists of two equal parts completing each other, process language and data language. Some people argue, processes are most important, some others stick on shared data. Needless to argue, both are needed. ARIS has still one advantage, ARIS enables to connect process and data descriptions seamless way. Your question also relates to that, how to combine process and data descriptions best practice way?

ARIS enables data modelling on two abstraction levels, conceptual modelling using Technical terms diagram, and logical data modelling using IE data model, like You mention. Now you ask, how to link these two, is a kind of mirroring or remodelling needed? Let me reply by considering various modelling requirements ARIS customers have. Some customers emphasize conceptual data modelling, close to business processes and without any need to proceed into more precise logical data modelling. For those customers, the Technical terms diagram is the right solution. It provides all the suffcient constructs to express the data language part at the same conceptual level together with processes.

Some customers emphasize the logical data modelling, then the IE data model is the right solution. So again, ARIS enables both requirements, serving a wide variety of customers. The IE data model provides the full scale proven entity-relationship modelling, originating from early 80'ies, and being still a valid and widely applied method. All the modern data modelling constructs, like data domain hierarchies, business object descriptions, all those can be expressed by applying the flexible data cluster concept, just like You mention.

Finally my reply, and my recommendation, is to avoid overlapping modelling. At best, a certain customer selects, their method is to apply logical data modelling, and to give up conceptual modelling. Another customer selects conceptual modelling, and they have no need to apply logical data modelling. If you select both, you have to guarantee resources as well, who can model and update both models, even to maintain the links in between and that mirroring you refer. My experience is, that rare companies have resources to maintain both conceptual and logical data models. Most often customers select logical data modelling today. So, my recommendation is to concentrate into logical data modelling. You can keep conceptual data models as well, or gradually give up. To establish data models first time, in transition phase you have certain remodelling to do, but later on you will have just logical data models to maintain.

Just my 5 cents to support the idea of conceptual information model...

Often there are only 2 parts of the company where different business units come together - board room and IT department. So the latter have to deal with a number of different LoBs operating on different markets, manufacturing different products or providing different services. Level of unification or diversification of an operating model of a company is defined by both business process and infromation integration (See EA as a Strategy book)... What I want to share, is the fact that conceptual model could serve a very important purpose in a company - establish a common business language across these business units which need information integration. Documentation of this language does not need entities, attributes and cardinalities. Instead such relationships like "is synomym of", "is the same as" are of ultimate importance!

Furthermore this common language can be used to establish  really common data model (CDM) aka logical data model (LDM), which could be either relation or object-oriented. Whether conceptual information model is then dropped, depends on the  justification of effort to maintain vs. value.

Actually, enhancement of a process with information is a step by step approach, which first can leverage information from conceptual informational model and then where necessary extend the process definition with content from common data model. Not every process deals with structured data - there are a lot of processes dealing with unstructured or not formalized structured information! So conceptual information model is fully sufficient.

/Konstantin

Having two modelling levels is worthless if the two cannot be connected. How do you propose we represent this connection?

Let me refer to my text, the last chapter starting "Finally my reply, and my recommendation ...". My practical experience really is, that most companies do not have resources to maintain both, and especially, the mapping between.

The only working mapping is consistent naming used in both, so the same object names mean the same in reality. For example, Sales order is Sales order in both! Theoretically, you could do mapping in detail, like with "depicts" between a technical term and an entity type, and display these connections in compact form in matrices.

But again, think first which is the responsible role in your organization to maintain these connections. I would stick on logical data modelling, and put all may data modeler resources there.

Sakari is definitely right if the sole purpose of infromation modelling is IT: implementation of custom application, modification\adjustment of standard software packages, application integration etc...

"Depicts" and matrix model in ARIS are the proper way to maintain the link between both levels. The relationship can be traced and analyzed.

/Konstantin

Hello,

FYI below is the response I got from IDS-Scheer support when I requested the ability to have "Technical Terms" objects be included in "IE Data Model" models. It contradicts your statement, saying that this can be done, but only with a certain license. (which we do not have)

Cheers,Laurent

quote begins here:

Hello

I have checked your license with the technical term in IE Data Model.

The symbol technical term is grayed out in th eIE Data Model.

The symbol Technical Term in the IE DataModel is contained in the method expension "Defense Solution - DODAF" .

You need a license with the code "Mam" in it.

To DODAF:

The product "ARIS Defense Solution" supports the DoDAF framework.

DoDAF = Department of Defence Architecture Framework; NAF = Nato Architecture Framework.

The "ARIS Defense Solution" serves as a guideline for the development of DoDAF-based organizational architectures. It contains guidelines for design and modelling of architectures in the US Department of defence (DoD). A defined set of products is used to assure that architectural descriptions are consistent across national and organizational borders.

ARIS Defense Solution allows organizations to optimize their Enterprise Architecture Management e.g. on the basis of DoDAF (DoD Architecture Framework). Also the new NAF (NATO Architecture Framework) can be supported.

The combination of IT and responsibilities in one central model is an important characteristic of system architectures in the company and state environment. The NAF (NATO Architecture Framework) standard is based on the US-American DoDAF (Department of Defense Architecture Framework) approach and completes it with additional working packages (NTV 3,4,5) with the aim of providing all NATO partners beyond the national borders with methods and conventions for the establishment of an Enterprise Architecture. This standard is now supported by ARIS Defense Solution.

The Framework contains the three main perspectives Operational

View (OV), Systems View (SV) and Technical Standards View (TV), which complete each other logically in the description of the whole company architecture

Kind regards, Andreas Stadler

To expand on this, do you know if there is somewhere a complete list of what is available:

which object-type,

which model-type,

which instantiation-possibility of each object-type on each model-type,

which relationship-type,

which instantiation ability of each relationship-type between each object-type on each model-type?

It would be good to have this for all possible license types of course...

Thanks in advance :-)

Hi,

where is the contradiction? Konstantin and Sakari are describing their experience how to do it in real world projects. Of course, if you are applying a very specific framework like DODAF, there might be different requirements. Just because you can model something in a model doesn't mean that it is the best way to move forward. I think that's what Sakari and Konstantin are trying to tell you.

The contradiction I see is in stating that we cannot want to connect a certain object-type on a certain model-type, that it would be a waste of resources, yet still the ARIS documentation explicitly mentions this possibility.

I happen to have this need coming back from users, and it is *very* difficult for me to argue against them, for at least two reasons: 

- the possibility is documented in the ARIS online help

- the notion that something as basic as connecting a "Technical Terms" object to another object on an "IE Data Model" model could be specific to the defense industry DODAF framework does not hold water, as there is nothing intrisically defense-related in Technical Terms ot IE Data Models...

Hopefully these users do not switch back to Visio just yet.

Hi,

an IE Data Model is used for logical data modelling and not for mapping conceptual data elements to logical data elements. You can do this kind of mapping in a technical term model if you like or in a matrix model.

Those discussions about "missing" connection and object types occur quite often. If we followed all those requests, we would probably have all object and connection types available in all model types :-) This would bring us close to a general purpose drawing tool like Visio. However, ARIS limits the number of possible combinations to provide best practices. As Sakari and Konstantin say, if you really need to map both levels, use a matrix model.

BTW, I tried to share some views on information architecture. All described there can be done with ARIS... No tricks..

/Konstantin