‎21-07-2023 03:27 AM
Hi,
I would love to hear your thoughts on when to use structure versus scenario diagrams.
From reading the documentation its not quite clear when and for what purpose you should use one or the other.
At basic level - they both show how systems interact with each other.
Structure diagrams use a more robust object for interaction called Exchange Contract. This object is powerful but is a bit complex to model with fully (i.e. by adding Exchanges and Flows for detail)
Scenario diagrams use Application Flows and Flow Channels - which are linked to Content, which can be linked to actual Data.
Scenario diagram tend to be more intuitive for architects to create - and simpler for audiences to understand.
Lastly, there is likely impact on reporting and analysis depending if you use structure or scenario diagrams.
I would like to have a more clear guidance for when to use which. But, after reading the docs and the training materials - I'm still not clear myself.
Is it possible to relate these two types of diagrams to other architecture description languages, such as UML or Archimate? That might be helpful to understand which is best suited for what purpose.
‎24-07-2023 09:20 AM
Hello,
Scenario of flows diagrams are limited/focus on data flows between blocks (application, system, application, microservice...). The scenario of flows defines the case perimeter where represented (and optionally sequenced) flows are valid (generally a business event - at boundary of scenario).
Structure diagram shows components and their service interactions (API usages). Same for environment diagram with external partners. Hopex Aquila sees change in vocabulary to align to usage :
We plan to add capability to link both points of view by allowing to declare wich service interface/operation is used for an application flow.