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.
Principles
Principle
4a: A message or data flow conveys a data object from a source to a target
Principle
4c: The cardinality of associations is important
Principle
4d: Data objects are neither objects nor classes in the OO sense
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