Hello,
I am looking for examples of using Material, Equipment and flows alongside application functions and user interfaces, but am struggling, even with the syntax.
To start, the example in section 11-5 of the specification has a relation between the materials and the equipment that I am unable to recreate in Archi (version 3.8)
https://pubs.opengroup.org/architecture/archimate3-doc/chap11.html (https://pubs.opengroup.org/architecture/archimate3-doc/chap11.html)
Any suggestions on workarounds?
Hi,
Quote from: asmundhjulstad on August 31, 2021, 13:40:43 PM
To start, the example in section 11-5 of the specification has a relation between the materials and the equipment that I am unable to recreate in Archi (version 3.8)
These are access relationship. An access relationship is always defined FROM behavior (or active strucure) TO passive structure, whatever the type of access (read or write). I guess you've tried to create a read access by first selecting material and then the equipment, while you should do the opposite, and then select you new access relationship and set it to "read" instead of "write" in the properties.
Quote from: asmundhjulstad on August 31, 2021, 13:40:43 PM
I am looking for examples of using Material, Equipment and flows alongside application functions and user interfaces, but am struggling, even with the syntax.
I should be able to find or create some examples, but maybe you should first explain what you goal or need is. For example, explain why you want to have physical elements next to application functions and user interface as these are usually not mixed (the physical "world" is usually used directly by humans, with no application in between).
Regards,
JB
Thank you for quick reply,
I see in the specification example that several of the access arrows are directed from material to equipment, but perhaps this is an error?
Quote from: Jean-Baptiste Sarrodie on August 31, 2021, 15:26:21 PM
Quote from: asmundhjulstad on August 31, 2021, 13:40:43 PM
I am looking for examples of using Material, Equipment and flows alongside application functions and user interfaces, but am struggling, even with the syntax.
I should be able to find or create some examples, but maybe you should first explain what you goal or need is. For example, explain why you want to have physical elements next to application functions and user interface as these are usually not mixed (the physical "world" is usually used directly by humans, with no application in between).
The model will describe a new system-of-systems for tracking of items through parts of a distributed supply and manufacture chain. Users will inspect, measure and mark individual items (and sometimes manufacture). Then shipped to final site, where some re-inspection might take place. Eventually, items will be assigned to a specific location in the finished product which is then assembled at the final location.
The purpose of the modelling effort is to facilitate discussions on functional allocation (who is responsible for what, and in which system), in turn identifying system boundaries and interfaces. Further, to discuss sequencing of implementation and possible future developments.
There will be lifting equipment, hand held bar code readers, bar code readers integrated in cranes, inspection results, detailed manufacturing designs, pre-assembled items, globally unique identifiers, shared databases, multiple companies, boat freight, heavy machinery and their control systems. Unreliable wifi, unreliable internet, user authentication, Excel integration [sic], (not all in one diagram, of course).
Regards,
Åsmund.
Hi,
Quote from: asmundhjulstad on September 01, 2021, 07:40:36 AM
I see in the specification example that several of the access arrows are directed from material to equipment, but perhaps this is an error?
You have to distinguish the visual direction and the semantic direction: in ArchiMate an access alway targets a passive structure, but depending on the type (read, write...) the visual notation change and the arrow is on the target or the source.
This is stated here (https://pubs.opengroup.org/architecture/archimate3-doc/chap05.html#_Toc10045319):
Note that, at the metamodel level, the direction of the relationship is always from an active structure element or a behavior element to a passive structure element, although the notation may point in the other direction to denote "read" access, and in both directions to denote read-write access. Care must be taken when using access with derived relationships because the arrow on the relationship has no bearing to its directionality.Quote from: asmundhjulstad on September 01, 2021, 07:40:36 AM
The model will describe a new system-of-systems for tracking of items through parts of a distributed supply and manufacture chain. Users will inspect, measure and mark individual items (and sometimes manufacture). Then shipped to final site, where some re-inspection might take place. Eventually, items will be assigned to a specific location in the finished product which is then assembled at the final location.
The purpose of the modelling effort is to facilitate discussions on functional allocation (who is responsible for what, and in which system), in turn identifying system boundaries and interfaces. Further, to discuss sequencing of implementation and possible future developments.
There will be lifting equipment, hand held bar code readers, bar code readers integrated in cranes, inspection results, detailed manufacturing designs, pre-assembled items, globally unique identifiers, shared databases, multiple companies, boat freight, heavy machinery and their control systems. Unreliable wifi, unreliable internet, user authentication, Excel integration [sic], (not all in one diagram, of course).
That's a long list ;-)
Some hints that you can use as guidance:
You'll most certainly have to model what is done by human beings as Business Processes. When detailing a big/macro process into smaller chunks, those chunks are also Business Processes that trigger each others. When creating an overview of all these macro processes, depending on your case, you can use either triggers (if there is a clear time dependency) or flows (if there is no clear time boundary and processes exchange parts, product or information) to link them.
When at some step someone relies on an application to do its job, an Application Component (or an Application Service if you want to be very precise) serves the business process. If instead a real physical tool is needed, then it is usually modeled as an Equipment serving the Business Process.
If you model the industrial process (ie. the one done by industrial equipment themselves and not humans), then you should use Technology Processes.
- A Business Process manipulating information will access Business Objects (in read and/or write). A Technology Process manipulating physical things will access Material. A Business Process manipulating physical things will access Material too.
Of course, Business Objects and Material will often be the two faces of the same coin. Depending on the case you have to choose one or the other but your model will most certainly contain both. E.g. : if you need water, sand and cement to create concrete, you can either model them as Business Object or Material. if you focus on the process needed to buy these raw materials and manage their stocks, then you're on the information side (ie. Business Object). If you focus on how you have to mix them to produce concrete, then you're on the physical side (ie. Material). In this example, one could decide to have water, sand, cement and concrete as both Material and Business Object (the material realizes the business object), or you could simplify by modelling water, sand and cement as Materials realizing a single Business Object named "Raw Material" (if buying and managing stock is similar for all raw materials), and a "Concrete" Material realizing a "Finished Product" Business Object.
Depending on your needs, there's of course other modeling construct that can be useful, especially those using active structures (Business Actors and Equipments).
Regards,
JB
Thank you for an excellent explanation and advice. I am looking forward to giving it a try.