Data Object - Conceptual x Logical/Physical

Started by eduardobbs, October 14, 2020, 14:59:52 PM

Previous topic - Next topic

eduardobbs

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?
All the apps write this data to their own repository, but only one of them is the Authoritative Source of Truth


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.

"

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?

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

Thank you.

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

Jean-Baptiste Sarrodie

Hi,

Ok, I'll try to answer or comment...

Quote from: eduardobbs on October 14, 2020, 14:59:52 PM
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?

Its hard to answer because there might be a misunderstanding of what Data Object is: a Data Object is the representation of a data used to automate some behavior inside an application component. This implies that two Data Objects are the same if they have the same format (ie. structure or schema). So in your case it will be right to say that one application writes it and the other reads it only if the data structure is the same.

Let's take an example: Archi can store an ArchiMate model using its native (.archimate) file format, or export it using the Open Group Model Exchange File Format. Both format are not the same and some informations might be lossed on one or the other. Frome an ArchiMate point of view, Archi (Application Component) is able to access two different Data Objects (ArchiMate model in native or Exchange format). Of course, both Data Object realize the same Business Object (an "ArchiMate model").

Quote from: eduardobbs on October 14, 2020, 14:59:52 PM
I guess TransactionID is not an "object type" as the spec suggests. Maybe if I rename it to FraudScreeningResult it would be better, but [...]

Exactly. In your case, "TransactionID" seems very much like an attribute, not an object.

A good rule of thumb to decide whether something is an object or not is to check if this "something" can be uniquely identified. If yes, this is most certainly an object and not an attribute. A "Transaction" can be uniquely identified, and "Transaction ID" is just an attribute to make this possible.

Quote from: eduardobbs on October 14, 2020, 14:59:52 PM
[...] 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.

There is no specifc or agreed way of modeling an attribute in ArchiMate (the standard does not target such level of detail). The usual way to do it is to use element's attributes, but in this case you can't really model it per se and show it on a diagram.

What you want to describe is a bit too detailed for typical use of ArchiMate, so this will necessarily be a trade-off. TBH, with the labels you put on triggers and flows, it seems quite implicit to me that this "TransactionId" is needed, so I wouldn't bother to model it explicitely. At most I'd show it in a data oriented view (like a Data Model). Another option is to add a constraint saying that all three application must share the "TransactionId" for your system to work as expected.

Quote from: eduardobbs on October 14, 2020, 14:59:52 PM
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.

"

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?

"Classe" and "instance" are used here in their usual Object Oriented meaning: a class represents a group of similar things, while an instance is one of those things ("JB Sarrodie" is an instance of "Person"). So the remark should be understood as: you don't model "the transaction n° 523-43-AA002" (an instance), but "a transaction" (a class). This remark is no meant to distinguish multiple occurences (storage) of the same information across tools.

So in short, these are not "different instances of TransactionID", but they might be (generally speaking) different representation of the same information (it is not unusual to exchange master data accross systems and have to cope with different constraints for the same attributes, depending on the application, like maximum number of characters, numbers or dates stored as text...

Quote from: eduardobbs on October 14, 2020, 14:59:52 PM
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?

No. This means this: when you model that "eCommerce" accesses "Orders", you (hopefuly) mean that your "eCommerce" system manages several "Orders", thus you model "Orders" as one single Data Object which is in fact a class. But as your "eCommerce" also accesses "Product", "Customers", "Stocks"... at some point (usually to ease the link with underlying Technology Layer elements like System Softwares and Artifacs), you'll most certainly come to the point you decide to add a "eCommerce Data" or "eCommerce DataBase" Data Objects which aggregates all of the previous. In such case, you usually don't mean that your "eCommerce" application accesses multiple databases, but only a single one. In the first example you've used DataObject as a class, in the second as an instance. In ArchiMate, because class/instance don't exist, this is not an issue at all and you can mix both semantic in your model. It's simply up to you (the modeler) to make it sure the name your put on the Data Object is clear/meaningful enough.

As a side note, the same is true with each and every concept in ArchiMate: when you model an "Customer" you are modelling a class, but when you model "eCommerce", I suspect you model an instance (because you most certainly have only one eCommerce system exposed to your customers). And of course, it can be both: again, your "eCommerce" application is both an instance (as explained just before), but also a class if you look at it as the collection of your different environment (development, QA, production...).

So, all this being said, what would I do if I were you... My personnal preference would go to simply remove the "TransactionID" Data Object (flow/triggers' labels are enough IMHO), another choice would be to keep the Data Object but find it a better name, maybe something along the line of "Fraud Screening Request".

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

eduardobbs

Very clarifying response. I do not know if the spec is not very clear or it was just me mistaking this.

I have also found some insights on the page. This site has loads of good Archimate content, BTW:
http://grahamberrisford.com/00EAframeworks/05ArchiMate/Premise%204%20Data%20conveys%20meaning.htm

At last, but not least, thank you for your time on this.
I find Archi, this forum, your engagement, and everything related fantastic.