Aggregation / Composition of Active Structure Elements by Product
From real-world experience in attempting to model representations of Products, particularly those types of elements found in the telecommunications / digital service provider industries, a number of types of elements are not easily representable using the current Product aggregation / composition relationships.
It is proposed to allow Aggregation and Composition relationships from Product to (at least) the following (possibly all) Active Structure elements.
Example Use Cases:
| Layer | Element | Examples / Rationale |
|---|---|---|
| Business | Business Actor | A Product offering in an industry business catalog representing the selling / leasing (e.g. franchise) of a business. |
| Business | Business Collaboration | A Product Offering in a business franchise catalog representing a collection of parties (e.g. "turnkey business solution" consisting of a business and its customers) for sale / lease. |
| Business | Business Interface | A Product offering representing business channels that are for sale or lease (e.g. door-to-door, marketing channel, etc.). |
| Application | Application Component | Application software (e.g. Archi for Windows 64 bit) that is for sale or lease (including possibly at no cost) as part of a Product offering in an application catalog. |
| Application | Application Interface | A specific SaaS API that is available as a subscription as part of a Product offering. |
| Technology | Device | A Product offering representing an electronic device (e.g. smart phone, SIM card, set-top-box, IoT device, etc.) that connects to a service provider's network as an active device. |
| Technology | System Software | Middleware (e.g. application server, database server, firewall software, proxy server software, etc.) that is for sale or lease (including possibly at no cost) as part of a Product offering. |
| Technology | Technology Collaboration | A suite of System Software Components or APIs (e.g. Middleware suite, ESB, etc.) that is available for sale or lease as part of a Product offering. |
| Technology | Communication Network | A network configuration, possibly consisting of a collection of Devices / Interfaces / software, etc. (e.g. public WiFi network solution, VPN solution, etc.) that is available for sale or lease as part of a Product offering. |
| Technology | Node | An application platform (e.g. combination of software and devices) that is available for sale or lease as part of a Product offering. |
| Physical | Distribution Network | A distribution channel (e.g. local truck-based delivery) that is for sale or lease as part of a Product offering in a business catalog. |
| Physical | Equipment | Network equipment (e.g. routers / wireless access points / firewalls / physical smart appliances (IoT), etc.), machines (e.g. trucks / forklifts / etc.) that are for sale or lease as part of a Product offering. |
| Physical | Facility | A factory is offered for sale as a Product offering in an industry real estate catalog. |
Visualization of Proposal (shows all Active Structure elements - a subset of this proposal may be more palatable (see above)):
Examples
Background / Rationale
A variation of this proposal was originally made to the ArchiMate LinkedIn Group Post and also to: Original Proposal / Exploration of Product / Active Structure in telecom hypothesizing that all active structure elements could be allowed to be aggregated / composed by Product, however the argument was made that Products are simply either "goods" or "services", and one should use a passive structure / service behaviour element to represent these types of entities, and relate them to their corresponding active structure elements.
The challenge with the simple Product consists of "goods" and/or "services" approach is that in scenarios where an entity that is considered to be an active structure element by the prospect / customer of the Product - which is certainly the case in the digital world, particularly in telecommunications - and is properly represented in ArchiMate as an active structure element in the model (e.g. a business, application software, API, device (e.g. set-top-box, smart phone, IoT device, etc.)), the modeller needs to define additional passive structure and/or behaviour service elements and relate them to the active structure elements that they may already have to represent these types of entities in their model.
In more complex environments, this may be hundreds of types of Product offering definitions / corresponding to the Product's aggregated / composed elements. This results in bloating of the model with redundant passive structure elements and indirect relationships that are required to be defined and managed primarily because the Product element doesn't support modeling a real-world scenario.
I privately received numerous confirmations from architects outside of the LinkedIn thread that the addition of aggregation / composition relationships on Active Structure elements would indeed be beneficial to their intentions, and that they too struggled with this gap.
Summary
The addition of aggregation / composition relationships from Products to some or all Active Structure elements would better support modelling of real-world scenarios, reduce model clutter and lower the barrier to adoption of ArchiMate in complex technical industries such as telecommunications / digital service providers.