Nuance 1 - Technology and physical equipment are not the same thingWell, my understanding was that Physical Elements were those things in the real world other than those already handled by the Technology Layer.
(from ArchiMate v3.0)
Technology: Device A physical IT resource upon which system software and artifacts may be stored or deployed for execution.
Physical: Equipment One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
ArchiMate "creaks" quite badly in places.
I note the use of the past tense, instead of the present tense. If your understanding was correct, why would there be a need for the physical layer, after all both contain physical items?
The minute you enter the physical realm, the realm of serial or VIN numbers (even asset identifiers), you are in the physical layer. But there is a complication, please see paragraph below regarding architecture vs engineering.
By the way, I have never seen the UML concept to Node as a
direct representation of something physical, please note the emphasis.
Nuance 3 - What certain instances may be?[SNIP]
Instance
An example or single occurrence (specific and identifiable) of something more abstract. We should distinguish between persistent instances (that have a lifetime extending beyond the duration of a single process) and ephemeral instances (run-time only - existing only for the duration of a process).
For the purposes of this discussion, it seems to me that we are dealing only with persistent instances.
Except for the part highlighted in red, this is how I always understood instance. However, I am not sure that we are dealing is this thread with persistent (or persistable) instances. However, you are touching an interesting issue underlying this discussion: hopefully we agree that something persisted is a
row/record on a
data entity/data store, please take both pairs of terms loosely and find the appropriate ArchiMate equivalents.
If we agree and have the following elements (> represent specialisations):
I) Vehicle > Motor Vehicle > (Motor) Car and Motor Car Model where (Motor) Car, and Motor Car Model both as Classes and Data Entities.
II) I propose that
II.a) The (Motor) Car data entity realises the (Motor) Car class, and the Motor Car Model data entity realises the Motor Car Model class.
II.b) An instance of a (Motor) Car Class is a row/record on the (Motor) Car Data Entity, and an instance of a Motor Car Model Class is a row/record in the Motor Car Data Entity.
[/list]
I was going to say I never had or seen a need to model this way but, but this thread may indicate otherwise. There are 2 aspects to this thread that could point towards such a need:
- transitioning between the deployment layer (UML)/technology layer(ArchiMate) and the physical layer (please see comment below regarding architecting vs engineering)
- can and should behavioural elements be instantiated?
Personally, I am more interested in the later. For example, should a Digital Shopper actor be instantiated? If so, what metaclass does the instance use? If the instance of a Digital Shopper actor is to be persisted, what is persisted to (a Session class or data entity) and does the Session realise the instantiated actor? Furthermore, in the digital world a Digital Shopper is or, at some point gets transformed into a User Credential that is authenticated.
Nuance 4 - From green to yellow (building without engineering, engineering without architecting, architecting without understanding the requirements)You seem to be confusing architecture and engineering. Generally architects are shit engineers and engineers are shit architects. I've spent a lot of time over the last two years producing local network views for customers where they would have previously received a visio diagram which looked like a cross between noodles and fruit salad.
I am not sure if I am confusing architecture and engineering but you do have a point. Architecting and engineering are separate things. In my simple mind, the engineers ‘world’ is the deployment layer (UML), and the technology and physical layers (ArchiMate).
My comment was more about diagrams looking “like a cross between noodles and fruit salad”. The abundance of such diagrams, I have also seen a fair amount of them, points out to a malaise that has afflicted IT for a long time, and does not seem to be getting any better: build without engineering, engineer without architecting, architecting without requirements. The good JFDI methodology.
This results on systems that look “like a cross between noodles and fruit salad” and on having to reverse engineering them to understand how it was constructed. ServiceNow plays a role in there.
Before somebody makes this point, I don’t think architects, engineers and developers are always required for anything we build in IT. But considering the complexity of some if the systems and ecosystems we developed, the frequent absence of building without engineering and engineering without architecting is staggering. The fact that this systems and ecosystems work and interact with each other may be proof that chaos theory applies to information systems and that somehow they are self organising.
