Premise 4: Data conveys meaning
How to align ArchiMate with UML and TOGAF
Copyright Avancier Ltd 2106
“The method proposed by systems theory is to model complex entities (multiple interacting components) by abstracting from certain details of structure and component.” (Laszlo and Krippner).
This is one in a series of papers that present premises and principles for using business system modelling languages and frameworks in a way that is compatible with system theory.
Premise: A data object contains a data structure or item that is meaningful or valuable to its creators and users. Business system modellers need to know what data passes between actors or components what data is stored in which containers. Enterprise architects model "information-intensive" business systems in which essential elements include data flows (messages of all kinds) and data stores (memories).
ArchiMate is thin on data architecture. Is its “data object” a message or data flow? a memory space or data store? or a discrete chunk of information conveyed inside a message or retained in a memory? The premise here is that each data object is a data item or larger data structure that is meaningful or valuable to its creators and users.
ArchiMate does not talk about the data structures contained in data objects, but they are there. A data object can be small or large. It could be a single data item, or a customer entity with several attributes. It could be an aggregate entity, such as a customer, with orders and order items. Or a large and complex data structure containing customers, orders, order items and product types. However small or large, the content of a data object can be defined in a data model.
A discrete message or data flow (or interface in TOGAF) conveys a data object from a source to a target. Messages occupy space and take a physical form (e.g. digital or paper). You can draw a flow arrow to show the movement of data/information/value between source and target elements. You can elaborate every data flow relationship using two arrows and a data object thus [source element ---> data object ---> target element].
Note that any discrete service may consume and/or return a data flow, even though it is not shown on a diagram.
A discrete memory or data store (or data component in TOGAF) retains a data object for the use of actors or components performing behaviours. Memories occupy space and take a physical form (e.g. digital or paper). The purpose of showing data stores in a system model is to identify independently-maintained memory spaces. Especially ones that hold large and complex data structures, composed of many smaller data structures and items.
How to represent a data store? ArchiMate has no data store symbol, and has various symbols that might be used.
· Data object – can represent a data structure at any scale from atomic data item to large and complex data structure.
· Artifact - can represent a deployable data structure definition (e.g. a message schema or database schema)
· System software – can represent data management system (e.g. a DBMS).
· Application component – can represent a data server layer that encapsulates a data store or other data source.
It isn’t obvious which symbol is best. You may say a data store is a passive structure that does not perform behaviour. So a data store can be modelled as a data object – perhaps a large and complex one. At run-time, a data store instantiates the concepts defined in any associated logical data model; it contains actual data (e.g. rows in database tables). If it is to be useful it has to be encapsulated in some way by put/get services. Which means it could be modelled as an application component. So, should we draw a data object or an application component? ArchiMate will not let you draw data flows to or from data objects, so if you want to do that, then you have to represent a data store as an application component.
ArchiMate doesn’t have a way to show the cardinality of an association relationship. The result is that people use composition to mean a 1-N association and use aggregation to mean an N-N association. Just as we need AND and OR symbols to connect relationships, we need a cardinality symbol (and better a crows foot than an asterisk) to show where the system element at one end of a relationship can appear as several instances in the operational system.
A business object or data object is not an object as in OO programming. Nor is it a class in a UML class diagram (though it could possibly correspond to a class). To avoid confusion, you could reasonably refer to business/data objects as business/data types. A data type describes a data structure which encodes information that has meaning or value to its senders and receivers.
Copyright Avancier Ltd 2106