Realize relation between Business/Data Objects (class instanciation?)

[Robert Chevallier]

Hi all,

Archimate standard does not allow the "realization" relation between data objects.
In a model, I'd like to represent basically a class of object, but also specific instances of it and indicates their associated class. Normally the relation should be "realization", which is not allowed in Archimate 3.x

For now, I use:

• underline label for the object instance name (like in UML)
• the specialization relation toward the object class, (optionally with a label "instanciate")

eg: for an entry in a Business Catalog, I model the business object "Commercial Service" (a class), and to give an example of an instance, a business Object "Connectivity" (instance) which is an instance of a commercial service.

• What would you use ?
• Does anyone know if a future version of Archimate standard will develop the Data modeling part ?

[Mastering ArchiMate]

ArchiMate is class/instance agnostic, there is no native support. Realisation is not the most usable relation to work around that and it also is not meant for that (so for me not ’normally’). 

I’ve written about this on my blog https://ea.rna.nl/2014/10/21/modelling-homogenous-landscapes-in-archimate-classes-and-instances/ and in the introductory part of Mastering ArchiMate (ArchiMate Book, the introduction can be freely downloaded).

I generally use Aggregation for Class/Instance abstractions (I aggregate Instances in a Class, both elements of the same ArchiMate element type)

Your use of ArchiMate for data modelling is something that people may have opinions about. At least you run into ’the map is not the territory’ here, especially if you model the catalog entry of a service as a business object in a catalog. A catalog like that may consist also of Products, that can in turn aggregate the actual services. That would be an alternative approach and more close to the idea of modelling the landscape and not so much modelling the data about teh landscape. You woul dthen also have a direct relation.

Gerben Wierda

Chess and the Art of Enterprise Architecture

Mastering ArchiMate

Architecture for Real Enterprises at InfoWorld

On Slippery Ice at EAPJ

--
You received this message because you are subscribed to the Google Groups "ArchiMate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/8682fdc4-7c9a-4565-a2fb-13db148798be%40googlegroups.com.

[Robert Chevallier]

Thanks Gerben for your insight and the link

Indeed I should have reread your book I bought sometime ago.

At the Business level, the modelization of a catalog by using Product aggregating Business Services and Contract was done. 

However my goal was to demonstrate how a passive structure -- the catalog -- at the application level is partially shared between application services (Offer management, Ordering, Billing, Service execution, etc....) and will allow business agility, because it can be then considered as a declarative language/grammar. I wanted to avoid going into details (fields, type, etc) required usually by data modeling notation or using UML (not understandable by business people), and keep using Archimate simple understandable notation to express the main concepts and their relations. 

Differentiating type (class) from instance is a key point, as the type is implemented as a table in application, but an instance is then just a record 

I'm interested to understand why do you say "realization is not meant for that"? (even if today it is not allowed between passive structure of the same layer)
Couldn't we consider that an instance makes the type/class more real, which is the semantic of this relation if I understand correctly?

-RC

[Kalin Maldjanski]

Hey Robert,

Generally ArchiMate is not the best(at all) option to model Class instances and you should use UML for example to do that.

In your specific case first thing to mention is that business object(which you use in the example) can be realized by data object(which you use in the beginning of the question)

Specialization and even more Aggregation is not suitable to use for Class instances, it can just confuse humans and machines :)

If you would like to do something custom like that you better try association with a label or even a property within the Instance Element. Naming convention as you do could also help. 

The biggest issue IMO is clarifying what is that you want to show and model. You talk about data/business objects but it seems you mean application components or services or functions. 

Starting from a Class what do you mean here? Class as in UML Class for example you have along with attributes also methods i.e. behaviour. Data object In archimate means a piece of information, a whole DB, a table, a record, a field.

Commercial Service for example can be a classification or more generic of  Connectivity and in that case Specialization works just fine, but not as a data object but rather a service or a function in the business or the application domain. 

[Mastering ArchiMate]

On 29 Nov 2019, at 13:56, Robert Chevallier <robert.cheva...@gmail.com> wrote:

I'm interested to understand why do you say "realization is not meant for that"? (even if today it is not allowed between passive structure of the same layer)
Couldn't we consider that an instance makes the type/class more real, which is the semantic of this relation if I understand correctly?

That statement could be considered an example of Uncle Ludwig’s ‘bewitchment by language’. The fact that we use the word ‘real’ in that way, doesn’t mean that use (and hence meaning) of the concept ‘real' is equivalent to how it is used (and thus what it means) in ArchiMate.

In other words: Yes, an instance is real and a class is not. But that doesn’t automatically mean that in ArchiMate the relation between the two (as far as they are separate in ArchiMate) is ArchiMate’s ‘realisation’.

ArchiMate does not have support for this kind of relation, except when it allows the use of Realisation between for instance Application Components to signify TOGAF’s ‘logical’ ('abstract’) and ‘physical’ (‘actual’) such as “MS Word (Application Component)” Realises “Word Processor (Application Component)” which seems very close to class/instance separation to me (though technically, MS Word could still be a class, so it is somewhat messy). Which is something very weird in the language as it doesn’t fit the rest (and I know that some people at the core of the ArchiMate community are very unhappy with this TOGAF-intrusion in the language)