Re: [open-archimate-forum] Data Object - Conceptual or Logical?

[Mastering ArchiMate]

On 14 Oct 2020, at 15:48, Eduardo Sequinel <eduardo_...@next.co.uk> wrote:

On Wednesday, 14 October 2020 at 14:47:22 UTC+1 Eduardo Sequinel wrote:

I want to show a "TransactionID" Data Object in a view, but different systems handle/store this data in their own way. Is it ok to say that one Application Component writes it, while the other one reads it?

Yes, but in ArchiMate 3 I would prefer associating the object with the flows (instead of using a label) and leave out the Access relations. For one, order of access is clearer (I describe this in the book ;-). 

All the apps write this data to their own repository, but only one of them is the Authoritative Source of Truth

There are many ways to make this clear, none of which are really simple. But in this case you could for instance use Associations between TransactionID and the flows and have a single Access that goes from the source of truth to the object to signify creating it.

Note, your trigger says it has a payload (in the label) but that label is not part of the model structure. There is a Trigger (causation) and a Flow (payload). But you could as well use a Serving relation from FraudAnalysis to Backend and a flow in the other direction.

*Disclaimer: This is a hypothetical design only (no real data)  

My question is because the spec (link) says:

"

A data object represents data structured for automated processing.

...the ArchiMate language in general focuses on the modeling of types, not instances, since this is the most relevant at the Enterprise Architecture level of description. Hence a data object typically models an object type (cf. a UML class) of which multiple instances may exist in operational applications. An important exception is when a data object is used to model a data collection such as a database, of which only one instance exists.

There is quite a bit of confusion regarding instances and types. For instance (pun intended) a process in a model will happen many times, each with slightly different data. We will clearly not model one process for every time that it happens. Is that process then a type? Or are we in fact modelling a set by that single element in the model? Anyway, I think in that sense we often model some fomr of multiple things with a single element. The same happens in your example. The Application Components are clearly instances and rightly so (though in reality even these may be multiple via some sort of clustering, containers or HA) but the TransactionID is clearly a set.

The statement from the standard is simplistic and not really helpful. There is no “in general” here. And in fact I suspect it is a leftover from earlier days when Architects thought their domain was the abstract (“the payment transaction system”) instead of the real (“the SWIFT system”).

"

So, it is not clear for me what is meant by instance here. 

Conceptually speaking, there is only 1 TransactionID for each transaction in this scenario, but the same TransactionID is stored in different places. Can I consider them to be different instances of TransactionID?

This is yet another way we can have multiples. There are multiple instances created by your source of truth and while these logically are shared, they physically are copied. In fact, true sharing may said not to exist in IT. Even the shared file system bits are copied to the systems sharing it. A fundamental property of logical systems lurks behind this. 0

ArchiMate has no way to model class/instance specifically. 

I would forget in thinking about classes and instances here.

I guess TransactionID is not an "object type" as the spec suggests. Maybe if I rename it to FraudScreeningResult it would be better, but then I am not sure if I can make explicit the relevance of the Transaction ID on allowing everything to link together at the end. Maybe I should use some boring side notes to explain that.

I also have a secondary question which relates to the following sentence: "An important exception is when a data object is used to model a data collection such as a database, of which only one instance exists.":

Does it mean that, when modeling a database, each Data Object would represent an instance of a type, such as Transaction1 / Transaction2?

Maybe I am just bad at interpreting text   :b

No. What they mean is that a database is a single instance in your landscape that is modelled as a single element. It just exists once and it is modelled once. Whereas there are many (different) TransactionIDs that are modelled as well with a single element.

The third thing is that your Transaction ID itself is als a multiple as I noted before.

Don’t get lost in these discussions. Simply think about how you want to use the model and then choose a pattern that makes that use possible. It is impossible to get meaning from grammar anyway (cf. Uncle Ludwig), so don’t try, don’t get ‘bewitched by logic’.

Gerben Wierda
Chess and the Art of Enterprise Architecture
Mastering ArchiMate
Architecture for Real Enterprises at InfoWorld
On Slippery Ice at EAPJ

Thank you.

DISCLAIMER

This email is confidential and subject to important disclaimers and conditions in relation to monitoring, viruses, confidentiality and legal privilege full details of which can be viewed on our Email Policy at the following link: http://www.next.co.uk/Policy/EmailPolicyStatement.asp

Next Holdings Ltd registered in England 35161.  Registered Office Desford Road Enderby Leicester LE19 4AT.  Authorised and regulated by the Financial Conduct Authority

-- 
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/e510f1fd-842b-461c-b030-8fbdc52200c7n%40googlegroups.com.