Best way to draw a data model in ArchiMate

[Manj75]

Not strictly an Archi tool question, but more about ArchiMate.

I wanted to get views on how everyone using Archi are creating Data Models.  The ArchiMate specification does not really expand on the data layer, but I have used the Application Data Object element and Associations to produce conceptual/logical data models.  These obviously are not a replacement to Entity Relationship Diagrams, but can be utilised to convey similar information.  I've used the data object to convey a DB table and high level table columns are populated as properties of the element.

I've found this to be the best way to design data models and keeping all designs in the Archi model, however where an ERD is required then I'd capture that as an image on a canvas.

It would be good to get the properties to be displayed in the data object element to more closely resemble an ERD and I know there is a Specialization plugin that can do this, but when I last evaluated it was crashing.

I'm interested in your views.

Thanks,
Manjit

---------------------------------------------------------------------------------------------------
Just discovered that there is an ArchiMate board and this post should likely reside there.
---------------------------------------------------------------------------------------------------

[chdessus]

Hello,
With ARCHIMATE, you can't draw data model such as UML entity/relation models. The only possible links between Application Data/Business Objects/Artifacts are :
- association
- composition
- aggregation

You can use the composition or aggregation link to show (x,N) association. With association, you can't  indicate "cardinalities" (nb of objects in a set).
In fact, Archimate is not intended to do that. If you are designing a system software, you still need to use UML and other methods to do it.

The big thing that you can do is to show the realisation/serving relation between business objects, application data and artifacts. You can also show the access (read, write) access of business objects, application data and artifacts :
- business objects by business processes, services or functions  ==> Conceptual model
- application data by application components, services or functions ==> Logical model
- artifacts by system software, services or functions ==> Physical model

Regards

[ChampagnePerry]

Hello,
Data Models and ArchiMate.
ArchiMate does have a number of limitations and I think we should lobby to introduce a little more nuance into the MetaModel here.

I think we should encourage the ArchiMate standard to move closer to the UML standard and recognise directed associations, multiplicity on associations, aggregations and compositions, attributes and a concept of state.

Having said that most of the things you really need to give reasonable clarity are already there in the Association, aggregation, composition, specialisation, realisation and access relationships if you are careful and separate your layers logically.

The way I use it to try to get around some of the limitations is to use a business concept level where we use Business Objects to do what their name implies and use this to represent the Business Data that normal business people would understand, this can be a bit of a wild west which has objects at alarmingly different levels but if it adds clarity to the business that's fine.
This is used to deliver the contextual view (how the data is used and what it's business value is).

These Business objects can be put into processes and where it's needed can express relationships between the objects using associations, aggregations, compositions and specialisations.
I have a more logical concept level starting at Information Domains (using an Archimate Grouping) that contains a more logical decomposition of the domain with Data Objects.
This can be used to create informal taxonomies within each domain, slightly more formal ontologies can be added which may well span more than one domain as well.
Whether these are simply a lot of logical but distinct concepts aggregated by the domain or whether they express more structure doesn't really matter.
I suppose the important bit here is, again only where it is needed to clarify, views of these logical concepts are combined to give clearer definition to what the Business Data actually means.
This is the logical conceptual layer of your model that introduces better separation of concerns between the data elements you will actually need.

Tables and Fields if you need to go that far should be represented by Artifacts not Data Objects as Data Objects are supposed to be tech agnostic (if you are talking tables you have probably made technology decisions that you should try to keep out of your logical model).
This is your Physical layer.

I'll post some examples of their use later if you like (sounds more complicated than it is).
I've attached a couple of diagrams that may help explain this approach.
(or not)

Hope that helps (and is more or less understandable).

Regards
Paul

[Manj75]

Hi ChampagnePerry,

Your response is highly comprehensive and I really like your diagrams that elaborate the approach - makes total sense.  Tbh, I have been sort following what you detailed, but primarily modelling the the logical data model using the application data objects, so nice to see it is aligned.

It would be good to have this approach adopted more formally into the ArchiMate specification as I feel that it covers all areas except for Data Architecture modelling, and what you provide does address that gap.

You mentioned that you can upload some examples that showcase the approach, can you please do so - I look forward to seeing them.

Also, you don't mind if I adopt your diagrams for reuse?

Thanks,
Manjit

[ChampagnePerry]

Hi Manjit,
No feel free to use them, the more people who use them the more likely we are to get it adopted as a standard.
I will upload some examples to this thread but I will have to tidy them up first and ensure that I depersonalise them to remove any sensitive information.
There is a question as to which level you want to drop down into an ERD and where and how you link this to your conceptual model, there may be no standard answer to this but I'm sure we can identify some basic ground rules that would help everyone who wants to do this.
Regards
Paul

[rchevallier]

Hi Paul

Thanks for sharing your modeling. It's about the same I'm using right now. However, I don't separate Business Data and Conceptual Data. Could you care to explain (with example?) why you need both and how they differ ? Is it because you assume the Conceptual data model is already a technical (IT) vision/interprettaion and so may not be  comprehensible by Business people ?