ArchiMate Enhancement Proposal: Information/Data Modeling Extensions
Hello ArchiMate User Community,
I'm submitting this proposal to enhance the ArchiMate language to better support Information/Data Modelling, as per @jbsarrodie's request for contributions on LinkedIn (ArchiMate User Community has been launched). I initially posted this as a response to @jbsarrodie's response to Iver Band's Data Modeling with Archi, but I was not sure if my proposal would be visible as a comment on Ivar's post, so out of an abundance of caution, I've posted it as a new item here.
Summary
- Add optional support for cardinality on Composition, Aggregation and Association relationships among Passive Structure elements
- Add additional shape options on Passive Structure elements to better support representing nested elements
- Add support for representing attributes as composed nested Passive Structure elements, with possible representation of visibility
Rationale
In several organizations that I've worked with, there were significant challenges driving adoption of ArchiMate with Data Architects, who tend to immediately (and understandably) ask for cardinality on relationships before they would consider modelling in ArchiMate. The alternatives that tend to be used are UML (if we are lucky), or "classic" "crows-foot" E-R models, which are sometimes confusing to our users, particularly our business community, as it is (yet) another notation to absorb, and worse, is modelled in a separate tool / repository than the ArchiMate models.
I have heard the argument that providing cardinality is "too detailed" for the use of ArchiMate, but in my experience, I've found that even business stakeholders (e.g. managers / analysts), after a short overview, could understand cardinality on simple class diagrams (UML) / ArchiMate information models, and it actually gave them the confidence that their requirements were being captured (e.g. optionality, multiplicity, etc.). I've needed to resort to notation conventions in ArchiMate as @smileham illustrates (excellent examples, by the way) as our stakeholders wanted to see the cardinality. Of course, as a guideline, the "too detailed" rationale can be made, but as a modelling notation, the lack of support for cardinality is more considered to be a gap in ArchiMate, especially since a significant portion of UML was already borrowed from in ArchiMate. It would be better if the modeller would have the ability to choose whether or not they want to show cardinality, rather than not having it available to them at all. I've heard this argument at several levels (e.g. you shouldn't be modelling solution architectures / designs with ArchiMate as it is meant for "EA" purposes), but the fact is that once people learn ArchiMate, they tend to (really) like it, and would like to be able to represent different levels of detail as they drill-down from high-level architectures into solution architectures, all within the same notation and the same tool. This is especially true with representations such as TOGAF ACM and Full SAFe, whereby different levels of abstraction and detail are represented with an expectation of traceability among the elements.
Having the ability to fully support data modelling within ArchiMate makes it feasible to fully represent conceptual / information / data architectures within the ArchiMate tooling / repository, without having to pivot to other modelling languages (e.g. UML / E-R) and tools, which also in some cases reduces licensing / integration costs for tooling, and reduces training requirements / costs.
Some specific requirements / options have emerged:
Note: as I drew the example diagram that intends to illustrate combinations and examples of the base proposal, other aspects emerged and were listed as possible considerations (e.g. alternate shapes for nesting, visibility indicator, etc.). The proposal doesn't necessarily advocate that all items be adopted, but rather puts it forward for discussion and consideration.
With respect to cardinality:
- The ability to specify the cardinality of a relationship at both the target and the source of the relationship
- The ability to specify the name of the relationship (existing ArchiMate functionality)
Applicable relationships / entities to Passive Structure Elements:
- Passive Structure element composes Passive Structure element (structural relationship)
- Passive Structure element aggregates Passive Structure element (structural relationship)
- Passive Structure element associated to Passive Structure element (dependency relationship) (in this case, it would be ideal if the Association relationship could support direction on both sides in addition to none / target)
The Passive Structure Elements that would be applicable for Cardinality (as described above) are:
| Layer | Element | Notes / Rationale |
|---|---|---|
| Strategy | Resource | Resource element can be used to represent strategy-level concepts that support Capabilities / Value Streams / Course of Actions, entirely within a Strategy viewpoint, without having to reference passive structure elements (e.g Business Objects, Data Objects) from more concrete layers. Ideally, having the "access" relationship available among strategic behavioural elements and resources would allow consistent representation of the relationship between behavioral and (passive) structural elements. |
| Business | Business Object | Business Object element used to represent conceptual models. |
| Business | Product | Product element allowing formal decomposition / dependency relationships to be represented, e.g. in the context of product catalogs, and their items. See: TM Forum Product-Service-Resource models. |
| Business | Product | Contract element allowing formal decomposition / dependency relationships among contracts (e.g. Subscriber Contract / Agreement, Service Level Agreements (SLAs), etc. to be represented. |
| Business | Representation | Representation element, to be consistent with other business layer passive structure elements. |
| Application | Data Object | Data Object element used to represent logical models. |
| Technology | Artifact | Artifact element used to represent relationships among technology artifacts. An optional alternate notation (e.g. rectangle with artifact icon at top-right corner) would support a more consistent view of technology passive structure models, and would better support attribute nesting (see below) |
| Physical | Material | Material element used to represent tangible, physical matter, allowing more formal cardinality to be expressed, if required. |
| Implementation & Migration | Deliverable | Deliverable element, to be able to represent more formal cardinality and to be consistent with relating other Passive Structural elements with cardinality. |
| Implementation & Migration | Plateau | Plateau element, to be able to represent more formal cardinality (e.g. optionality of sub-plateau(s)) and to be consistent with relating other Passive Structural elements with cardinality. |
| Composite | Grouping | Grouping element, when representing passive concepts (e.g. Domains, Classifications, etc.), where Groupings are related to each other structurally, and/or sub-items of groupings are formally defined including cardinality. |
| Composite | Location | Location element to be consistent with other passive structure elements. |
With respect to Attributes:
- Composing other Passive Structure elements and showing them as nested elements can be used. The cardinality of the composition relationship could be used to define the optionality of the attribute.
- To better support nesting of elements, in order to reduce the vertical size required and to reduce the number of lines within elements, an alternate shape could be defined for Passive Structure Elements that were similar to how other elements are represented in ArchiMate, whereby a miniature icon representation of the element would be shown at the top-right corner of the element (see attached diagram for examples).
- In the nested form, attribute visibility (e.g. - private, # protected, + public, ~ package) could be supported as well, as per UML. This could optionally be defined on the composition relationship itself, possibly using a standardized ArchiMate Property).
- For Passive Structure elements that do not natively represent information (i.e. other than Business Object and Data Object), the information element within the given Passive Structure element's layer could be used to represent its attributes (see attached diagram for examples).
- In layers that do not contain concepts that represent information (e.g. Strategy, Technology, Physical, Implementation & Migration, Composite), a new element could be introduced in each layer to represent an information concept that could be used to represent attributes of Passive Structure elements. (This item is considered to be an ambitious possibility (i.e. a stretch), and is included here for only for completeness).
Regards,
Andrew Greff
