TOGAF and ArchiMate 3.0 change requests
THIS OLD PAPER HAS
BEEN SUPERCEDED BY THIS
NEWER PAPER
THE REMANTS BELOW
ARE OUT OF DATE
Meta model diagram
change requests
Fig. 4. In accord with the UML rationale, show capabilities as structures rather than behaviors.
Fig. 12. In accord with the UML rationale, show functions as structures rather than behaviors.
Fig. 14. In accord with the UML rationale, show capabilities as structures rather than behaviors.
Fig. 44. In accord with the UML rationale, show capability is a structure <assigned to> a course of action.
Fig. 48. In accord with the UML rationale, show capability is a structure <assigned to> a course of action.
Fig. 51. In accord with the UML rationale, show functions as structures rather than behaviors.
Professional architects ought to be clear about the distinction between behaviors (services) and structures (interfaces).
In TOGAF and
ArchiMate, an interface, rather than providing access to a service, provides access to one
or more services.
And rather than
being a physical point of access, an interface defines a required service
portfolio, to be made available at run-time.
Current
definitions in black. Change requests in blue.
|
Interfaces as structures |
Services as behaviors |
|
Interface An external
active structure element, called an interface, represents a point of access
where one or more services are provided to the environment. An external active structure
element, called an interface, encapsulates
an internal active structure by grouping services made available to external
clients. |
Service An external behavior element, called a service, represents an
explicitly defined exposed behavior. An
external behavior element, called a service, is requestable by clients of an active structure, and
defined by a contract that
encapsulates the behavior performed. |
|
Business interface A point of access where a business service is made available to the environment. A structure that encapsulates a business function, role or actor by grouping business services made available to other business functions, roles or actors. Application interface A point of access where application services are made available to a user, another application component, or a node. A
structure that encapsulates an application component by grouping application
services made available to business users,
other application components, or nodes. Technology interface A point of access where technology services offered by a node can be accessed. A structure that encapsulates a node by grouping
technology services made available to application components, or other nodes. |
Business
service An explicitly defined exposed business behavior. A service requestable by clients
of a business function, role or actor, defined by a contract that encapsulates the behavior
performed. Application service An explicitly defined exposed application behavior. A service requestable by clients
(business users or application components) of an application component,
defined by a contract that encapsulates
the behavior performed. Technology service An explicitly defined exposed technology behavior. A service requestable by clients
(application components or nodes) of a node, defined by a contract that encapsulates the behavior performed. |
ArchiMate v 3.0 says: “Business functions and business roles serve as intermediary elements between “purely behavioral” elements and “purely structural” elements”
All active structure elements are defined by their relationship to activities, but that does not make them behaviors.
Organisation units and actors are active in dynamic operational systems; they are able to perform behaviors and actually perform them – they are not classified as behaviors.
Business functions and roles group activities in static system descriptions; they are not active; they do not perform behaviors.
ArchiMate classifies roles as structural elements; so why classify functions as behaviors? It just doesn’t make sense.
Current
definitions in black. Change requests in blue.
|
Functions as structures |
Processes as behaviors |
|
Function: A structure that groups behaviors, based on chosen
criteria, irrespective of time. |
Process: A sequence of behaviors that achieves one
or more specific outcomes. |
|
Business function A collection of business behavior based on a chosen set of criteria (typically required business resources and/or competences), closely aligned to an organization, but not necessarily explicitly governed by the organization. A structure that groups business behaviors based on chosen criteria (typically resources)
irrespective of time; it defines a logical organizaton
unit that can be fulfilled by one or more real organization units, but is not
explicitly managed by the organisation. Application function Automated behavior that can be performed by an application component. A structure that groups automated behaviors that can be performed by an application
component, irrespective of time; it defines a logical application component. Technology function A collection of technology behavior that can be performed by a node. A structure that groups automated behaviors that can be performed by a node, irrespective
of time; it defines a logical technology component. |
Business process A sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services. A behavior that sequences
business behaviors to achieve one or more specific
outcomes, products or business services. Application process A sequence of application behaviors that achieves a specific outcome A behavior
that sequences automated application behaviors
to realise an application service (often hidden behind an API and taken for
granted). Technology process A sequence of technology behaviors that achieves a specific outcome. A behavior that sequences
automated technology behaviors to realise a
technology service (often hidden behind an API and taken for granted). |
Having made the
changes above; it becomes easier to align ArchiMate with TOGAF at both
conceptual and detailed levels.
In
TOGAF’s conceptual framework, required behaviors
<are assigned for performance to> logical components <are realised
by> physical components.
In short, the
generic concepts are:
·
Service: An external behavior element, requestable by
clients of a business structure or component, and defined by a contract that encapsulates the behavior performed.
·
Logical
component: A
structure that groups behaviors based on chosen
criteria (typically resources or competences) irrespective of time. It can be
specified as a service portfolio.
·
Physical
component: A
structure that is hired, bought or built to realise one or more logical
components, and is deployable by the organisation.
It is possible to align
ArchiMate and TOGAF conceptual frameworks, and align concept definitions as
below.
|
ArchiMate definitions revised to match – changes in blue |
TOGAF definitions revised to match – changes in blue |
|
Service: An external behavior
element, requestable by clients of an active
structure, and defined by a contract
that encapsulates the behavior performed. Business service: A service requestable by clients of a business function, role or
actor, defined by a contract that encapsulates
the behavior performed. Application service: A service requestable by clients (business users or application
components) of an application component, defined by a contract that encapsulates the behavior
performed. Technology service:A service
requestable by clients (application components or
nodes) of a node, defined by a contract
that encapsulates the behavior performed. |
Service: An external behavior
element, requestable by clients of a business
structure or component, and defined by a contract that encapsulates the behavior
performed. Business service: A service requestable by clients of a business function,
organisation unit, role or actor, defined by a contract that encapsulates the behavior
performed. Application (IS) service: A service requestable by clients of an
application component, defined by a contract
that encapsulates the behavior performed. Technology (platform) service: A service requestable by clients of a platform
application or technology component, defined by a contract that encapsulates the behavior
performed. |
|
Function: A structure that groups behaviors
based on chosen criteria (typically resources or competences) irrespective of
time; it defines a logical component or subcomponent. Business function: A
structure that groups business behaviors based on
chosen criteria (typically resources) irrespective of time; it defines a
logical organizaton unit that can be fulfilled by
one or more real organization units, but is not explicitly managed by the
organisation. Business role: A
structure that groups business behaviors based on
chosen criteria (typically competences) irrespective of time; it defines a
logical role that can be fulfilled by one or more human actors. Application function: A structure that groups automated behaviors
that can be performed by an application component, irrespective of time; it
defines a logical application component. Technology function: A structure that groups automated behaviors
that can be performed by a node, irrespective of time; it defines a logical technology
component. |
Logical
component: A structure that groups behaviors based on chosen criteria (typically resources
or competences) irrespective of time. It can be specified as a service
portfolio. Business function: A
structure that groups business behaviors based on
chosen criteria (typically resources) irrespective of time; it defines a
logical organizaton unit that can be fulfilled by
one or more real organization units, but is not explicitly managed by the
organisation. Business role: A
structure that groups business behaviors based on
chosen criteria (typically competences) irrespective of time; it defines a
logical role that can be fulfilled by one or more (usually human) actors. Logical application component: A structure that groups automated behaviors
required of a physical application component, irrespective of time. Logical technology
component: A
structure that groups automated behaviors required
of a physical technology, irrespective of time. |
|
Internal active structure element: An entity that is capable of performing behavior. Business actor: A business entity capable of performing behavior (organisation unit or human). Application component: An encapsulation of application
functionality aligned to implementation structure, which is modular and
replaceable. It encapsulates its behavior and data,
exposes services, and makes them available through interfaces. Note: A computational or physical resource that
hosts, manipulates, or interacts with other computational or physical
resources. |
Physical
component: A structure that is hired,
bought or built to realise one or more logical components, and is deployable
by the organisation. Organisation unit: A
structure of actors that fulfils one or more business functions. It should
have a manager, goals and objectives with measures. Actor: An individual actor (usually human) that fulfils one or more roles
inside or outside an organisation. Physical application component: A technology-specific structure of software modules that is
hired, bought or built to realise one or more logical application components,
and is deployable by the organisation. Physical technology
component: A
technology-specific node (structure of software modules and/or hardware) that
is bought or built to realise one or more logical technology components, and
is deployable by the organisation. |