Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: mmontminy on July 06, 2019, 12:49:11 am
-
I am modeling the Application Layer of the enterprise using ArchiMate. I have high level view application landscape diagram showing the main application components and some relationship between them. I have more detailed/specific view by domain that shows the actual interfaces (represented by flow and triggering relationship) between them. I see the relationships in the higher level diagram as representing all the actual relationships in the lower level diagrams.
My question is how to model this?
Currently, I'm building the higher level view from the lower level relationship. I select one of the relationship and hide the other. This is not ideal as I cannot put anything in the attribute of the relationship because it will be everywhere the relationship is used.
Here are two options I'm considering:
- Creating a new type of relationship to represent those relationship
- Modifying the existing relationship type by adding an attribute to flag high level vs lower lever relationship
- Using the "Association" relationship type as it is generic
Option 1: seem to be the cleaner.
Option 2: would require less work to put in plan but would need more work to differentiate between high and low level relationship
Option 3: no work to implement but "Association" is a structural relationship when we are really in the realm of dynamic relationships and may conflict with other Association relationship relationships.
Other options I should consider or thoughts on the problem?
Ideally, it would be some kind of "composite relationship" where the higher level relationship would represent all lower level actual relationship.
These relationships may represent
-
Martin,
ArchiMate supports the idea of "derived relations", but EA doesn't really AFAIK
I would be leaning towards option 2
Geert
-
The derivation rules for dynamic relationships as explain in ArchiMate spec is not what I'm after.
I just thought of another option that would not require any work. For my lower level relationship, I have specialized the ArchiMate Flow and Triggering relationship to add extra attribute (like frequency). The higher level relationships don't need those attributes. Using the out-the-box ArchiMate Flow and Triggering relationships seems a cheap way to satisfy my basic need (different type of relationships to model high vs low level relationships). I won't have the composite "relation" between the high level ArchiMate relationship ArchiMate dervived relationships but if we limit (by process) the ArchiMate relationship between two Application Components to one the relationship will be implicit. I will give it a try.
Thanks for the feedback!
-
I think what you're trying to do I don't use ArchiMate for. I use a very stripped back UML model with Information Flows which carry Information Items between components. There's kind of a layer missing in ArchiMate where you can model the business' concept of a system with business objects flowing between systems. You'll see in a lot of ArchiMate business layers that modelled business interfaces are actually a "system".
-
Difficult to visualise exactly what you are trying to do without any specific examples. i.e. what view points and relationships specifically you are trying to show to the various stakeholders.
I use high level application components with high level relationships and low level application components with interfaces and low level relationships. The relationship between the high and low level components is either composition or aggregation.
For example SAP is represents a high level component and its high level relationships (associations) with other systems. The low level components such as SAP Financials have low level relationships(flow) that go through application interfaces (SFTP) with application components in other systems like Banking System. So it would kind of look something like this;
High Level:
SAP-> Association->Banking System
indicates there is some kind of relationship between the two high level systems.
Low Level:
SAP[Component]->Composite[Relationship]->SAP Financials[Component] -> SFPT[Interface] ->Flow (Payments)[Relationship]-> SFPT[Interface] ->Banking System[Component]
{Not sure if thats how SAP works just made it up to illustrate}
As the low level application components and interfaces have the relationships with other low level components and interfaces and these don't appear on the high level diagrams and you don't have low level relationships appearing on high level diagrams.
Hope that helps or provides some food for thought.
-
Let me be more specific with a simple example. I work in the banking industry where we have a Centralized CIF (Customer Information File) system/component. This system gets updated daily online (real-time) and batch by multiple system. Let's take its interaction with our Core Banking system Temenos T24. These 2 systems exchange multiple files for different purposes (client info, products, etc.) at different frequencies.
At a high level, I want to represent the 2 systems with one or 2 relationship (one for batch and one for online/realtime. At that level, there is no detail (no frequency, type of information carried, etc)
At a lower level each of the high level interface is "decomposed" one or many detailed relationships where characteristic of the relationships are detailed (frequency for batch, type of information)
@Sunshine: What you are describing pretty much match what I'm trying to do. You're proposing to use the "Association" relationship for high level diagram (that was my option 3) and more specific relationship for lower-level. The difference in what you are proposing and what we are doing (at the moment, at least) is that we don't decompose our application components into finer application components. We are not there yet.
For now I've elected to use the out-of-the-box ArchiMate Dynamic relationships for the high level and specialized version of those (that have some extra attributes) for the lower level.
Thanks for the feedback
-
Let me be more specific with a simple example. I work in the banking industry where we have a Centralized CIF (Customer Information File) system/component. This system gets updated daily online (real-time) and batch by multiple system. Let's take its interaction with our Core Banking system Temenos T24. These 2 systems exchange multiple files for different purposes (client info, products, etc.) at different frequencies.
Your example is why I use UML with information flows and information items.