Objective
Archimate is an Open Group notation for enterprise architectures. As it is supported by open-source tools, it may be useful to review its core enterprise concepts and examine how they can be mapped to the Caminao modeling Paradigm and more generally to UML.
Architecture Levels
Archimate follows the widely accepted distinction between business, applications, and technology layers. Since those layers fully coincide with the Caminao levels for enterprise, systems, and platforms, the pivotal issue is how the description of the business layer can be mapped to its systems counterpart.
Business Processes & Functions
The objective is to distinguish between business functions and the modalities of their execution.
Process
Archimate: A behavior element that groups behavior based on an ordering of activities. It is intended to produce a defined set of products or business services.
Comment: Undefined ordering criteria; possible confusion with those used for functions.
Suggestion: Use time related dependencies (control flows) to describe processes execution.
Function
Archimate: A behavior element that groups behavior based on a chosen set of criteria (typically required business resources and/or competences)
Comment: No clear-cut definition of ordering criteria; possible confusion with those used for processes.
Suggestion: Use functional dependencies (and data flows) to describe functions ordering.
Event
Archimate: Something that happens (internally or externally) and influences behavior (business process, business function, business interaction).
Comment: Business events are meant to happen at business level, i.e they must be “visible” externally.
Suggestion: Events taken into account should reflect changes in state of business objects, status of processes execution, or actors expectations.
Business Actors & Roles
The primary objective is to decide what must remain under people responsibility, and what may (or may not) be done by systems. Assuming that business logic, regulations or technology will change with time, actors and roles should be managed separately. Unfortunately, Archimate and UML terminologies are contradictory: “role” means “actor” in UML parlance.
Actor
Archimate: An organizational entity that is capable of performing behavior via a role.
Comment: The definition ignores identification aspects. Moreover, given the importance of authority and responsibility for EA, muddling people, groups, systems, and devices under a single roof can be confusing.
Suggestion: Actors should always be stereotyped either as people, group, system, or device, and be associated by some relevant identification mechanism. If that’s not possible roles should be used instead.
Role
Archimate: The responsibility for performing specific behavior, to which an actor can be assigned.
Comment: While, and contrary to TOGAF, Archimate doesn’t mention the roles framed by organizational structures independently of associated activities, the difficulty remains for positions that, depending on rules and habits, could possibly be defined as actors or roles.
Suggestion: Given that roles are meant to be managed with regard to specific activities, any position identified and managed at enterprise level should be represented as actor.
Business Collaborations & Interactions
As for actors, Archimate and UML concepts don’t coincide: with the former a collaboration refers to agents, with the latter it refers to activities; terminologies also differ for interactions.
Collaboration
Archimate: An aggregate of two or more business roles that work together to perform a collective behavior.
Comment: Possible confusion with collective roles (groups) and collective behaviors (interactions). That ambiguity is comforted by the transition to application collaboration. More generally, it seems preferable to define collaborations in terms of activity before introducing the relevant roles.
Suggestion: Use business collaboration for collective behaviors (i.e internal interactions), and make separate references to roles. Business collaborations will be eventually mapped to controls at application level.
Interaction
Archimate: A behavior element that describes the behavior of a business collaboration.
Comment: Possible confusion with collaboration.
Suggestion: Use interaction to describe behaviors between processes and external entities.
Locations & Business Interfaces and Services
Location
Archimate: A conceptual point or extent in space.
Comment: A point is the antithesis of a space.
Suggestion: Locations should be defined as execution or address spaces.
Interface
Archimate: A point of access where a business service is made available to the environment.
Comment: Ambiguity between content (“functionality of a business service”) and medium (“It is often referred to as a channel”).
Suggestion: Use “interface” to describe the symbolic exchanges between systems and their environment. Corresponding communication channels are better described by relationships.
Service
Archimate: A service that fulfills a business need for a customer (internal or external to the organization).
Comment: Circular definition.
Suggestion: Align the definition with the semantics of services oriented architectures: a function that fulfills a business need irrespective of time and location.
Business Objects
Object
Archimate: A passive element that has relevance from a business perspective.
Comment: None
Suggestion: Business objects are symbolic representations of physical or non-physical entities whose identity and consistency must be maintained independently of the business processes using them.
Product
Archimate: A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.
Comment: Too vague for business modeling purposes.
Suggestion: Generalize to symbolic containers (figured by packages) for objects and activities.
Contract
Archimate: A formal or informal specification of agreement that specifies the rights and obligations associated with a product.
Comment: Too vague for business modeling purposes.
Suggestion: Generalize to business object.
Relationships (aka Connectors)
Archimate relationships combine syntax (composition, aggregation, grouping, junction, …), semantics (access, use, triggering, flow,…), and development flows (realization, assignment, specialization). As that makes room for ambiguities and redundancies, it may help to consolidate the different dimensions:
- Connectors semantics is set by context: symbolic reference (objects), communication channels, flows (activities), synchronization (processes execution). They must be used within layers.
- Connectors syntax deals with structures: containers and logic operators (and, or, xor).
- Engineering connectors deals with dependencies between layers. They are meant to be used across layers.
Association
Archimate: Models a relationship between objects that is not covered by another, more specific relationship.
Comment: Default connector.
Suggestion: Semantics set by context
Grouping
Archimate: Indicates that objects belong together based on some common characteristic.
Comment: Can be used in different context.
Suggestion: Syntax only. A distinction should be maintained between containers of symbolic descriptions (e.g product) on one hand, and containers used to manage instances of objects or processes (e.g location) on the other hand.
Aggregation
Archimate: Indicates that a concept groups a number of other concepts. It has been inspired on the aggregation relationship in UML class diagrams. In contrast to the composition relationship, an object can be part of more than one aggregation.
Comment: Confusion between concepts and (instances of) objects.
Suggestion: Syntax only. Aggregation is better defined as a grouping of instances identified independently. Should not be used across layers.
Composition
Archimate: Indicates that an object is composed of one or more other objects. It has been inspired by the composition relationship in UML class diagrams. In contrast to the aggregation relationship, an object can be part of only one composition.
Comment: The short definition is ambiguous.
Suggestion: Syntax only. Compositions are better defined as a grouping of instances identified through their grouping. Should not be used across layers.
Junction
Archimate: Used to connect dynamic relationships of the same type.
Comment: Combine syntax (AND, OR, XOR) and semantics (flows).
Suggestion: Can be generalized as a syntactic operator and applied to all types of homogeneous connectors, e.g for joint references.
Assignment
Archimate: Links active elements (e.g., business roles or application components) with units of behavior that are performed by them, or business actors with business roles that are fulfilled by them.
Comment: Can be seen as the complement of access. Discrepancy between definition (a bridge between semantic contexts) and some examples (dependencies between layers).
Suggestion: Semantics only. Should not be used across layers.
Access
Archimate: Models the access of behavioral concepts to business or data objects.
Comment: Can be seen as the complement of assignment.
Suggestion: Semantics only. Should not be used across layers.
Used by
Archimate: Models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations.
Comment: Possible confusion between functional and operational requirements. That can be avoided if “used by” is seen as the equivalent of “access” across layers.
Suggestion: Engineering only. Should only be used to describe operational dependencies across layers. Functional dependencies within layers be by “access” or “assignment” relationships, and design dependencies across layers should be represented by “realization” relationships.
Realization
Archimate: Links a logical entity with a more concrete entity that realizes it. Used in an operational sense (e.g., a process/function realizes a service), but also in a design/implementation context (e.g., a data object may realize a business object, or an artifact may realize an application component).
Comment: The duality of uses may lead to a confusion between operational and technical requirements. That can be avoided if “realization” is seen as the complement of “used by”.
Suggestion: Engineering only. Realization should only be used to describe development flows across layers; operational dependencies within layers should be represented by “used by” relationships.
Flow
Archimate: Describes the exchange or transfer of, for example, information or value between processes, function, interactions, and events.
Comment: The definition is ambiguous as events are sent or received but are neither source or destination.
Suggestion: Use only for data (messages) or control (events) flows.
Triggering
Archimate: Describes the temporal or causal relationships between processes, functions, interactions, and events.
Comment: The duality of uses may lead to a confusion between control flows (between functions) and state transitions (between execution sates). That can be avoided if “triggering” is seen as the complement of “flow”.
Suggestion: Use only for transitions between states.
Specialization
Archimate: Indicates that an object is a specialization of another object. The specialization relationship can relate any instance of a concept with another instance of the same concept.
Comment: The definition is circular (“specialization” appears on both sides) and inconsistent (specialization relates to descriptions, not to instances).
Suggestion: Syntax only. Use specialization for subsets of instances (objects or execution units).
Further Reading
- Modeling Paradigm
- Models, Architectures, Perspectives
- Building a Bridge
- Modeling Languages: Differences Matter
- Enterprise Architecture & Separation of Concerns
- EA Framework mock-up
External Links
Location
Archimate: A conceptual point or extent in space.
Comment:
Many thanks for this article, it really helps me to understand archimate principles.
I’m the last to say ArchiMate is perfect (I actually spend a whole chapter in my book on what is wrong with it, even more in depth in the upcoming Edition II), but it is quite useless to analyse it more or less linguistically based on what the standard specification says. It is easy to make mistakes (e.g. the Business Service definition is itself not circular, because it refers to an underlying more generic Service concept in an earlier chapter).
It is also more or less useless to take one standard of organising concepts in the organisation/EA domain and use that as a yard stick for another. Someone has one definition of ‘function’ and concludes the other is ‘wrong’. That comes close to ‘bewitchment by language’ from good-old Uncle Ludwig.
Finally, I gather from your approach that you are attempting a purely logical approach to these issues. The effect of such rational approaches when confronted with the world of the real is that they explode in size and complexity. Besides (and this is Uncle Ludwig again), roughness, ambiguity, vagueness (‘family resemblance’) have a real function: they provide us with the ‘rough ground’ that enables friction which enables movement. A perfectly logical language is like a perfect ice floor: it gets you nowhere. You can’t move without friction. Purely logical approaches are doomed to fail. Even in purely logical domains, often.
You’re right about this being an attempt to a logical (I’d rather say consistent) approach. One benefit of this approach is to be open to rational critics, and counter-critics. For instance, I do believe that defining a business service with a reference to an underlying more generic service concept can be seen as circular.
Hi,
I have one comment about “As it is supported by a free open-source tool”. I guess you think about Archi (which is by no way associated with the OpenGroup). If yes, then I would suggest to also add a link to Archi’s homepage: http://www.archimatetool.com
Regards
Jean-Baptiste,
Thanks.