View
215
Download
1
Category
Preview:
Citation preview
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
1
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
A Review of
Business & Application Layers
of the ArchiMate® 2.1 Specification
March, 2014
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
2
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
CONTENTS
References 3
1. Introduction: Why Don’t We Use ArchiMate yet? 4
2. Business Layer 6
2.1 Business Layer Metamodel 6
2.2 Structural Concepts 9
2.3 Business Role 10
2.4 Business Collaboration 11
2.5 Business Interface 14
2.6 Business Object 16
2.7 Behavioural Concepts 16
2.8 Business Process 18
2.9 Business Function 21
2.10 Business Interaction 23
2.11 Business Event 25
2.12 Business Service 25
2.13 Information Concepts 27
2.14 Representation 29
2.15 Meaning 29
2.16 Value 30
2.17 Product 31
2.18 Contract 33
2.19 Summary of Business Layer Concepts 34
3. Application Layer 35
3.1 Application Layer Metamodel 35
3.2 Active Structure Concepts 36
3.3 Application Component 38
3.4 Application Collaboration 40
3.5 Application Interface 41
3.6 Behavioural Concepts 43
3.7 Application Function 45
3.8 Application Interaction 46
3.9 Application Service 48
3.10 Passive Structure Concepts Service 51
3.11 Data Object 51
3.12 Summary of Application Layer Concepts 52
4. Cross-Layer Dependencies 53
4.1 Business- Application Alignment 53
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
3
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
References
[1] ArchiMate® 2.1 Specification. The Open Group, ISBN: 1-937218-00. 2012.
http://pubs.opengroup.org/architecture/archimate2-doc/toc.html
[2] “Reference Architecture Foundation for Service Oriented Architecture Version 1.0”. Committee
Specification 01. December, 2012 http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra.html
[3] Michael Poulin, “Architects Know What Managers Don’t” (Business Architecture for Dynamic
Market). BuTechCon Ltd. - Troubador Publishing Ltd. April, 2013.
http://www.mpoulin.com/architects-know-what-manager-dont/
[4] Michael Poulin, “Ladder to SOE” (How to Create Resourceful and Efficient Solutions for Market
Changes within Business and Technology). Troubador Publishing Ltd. June, 2009.
http://www.mpoulin.com/ladder-to-soe/
[5] Michael Poulin, “Knight Rules of Ownership in Service-Oriented Ecosystem”. ebizQ BLOG Site,
Business Ecology Initiative & Service-Oriented Solution.
http://www.ebizq.net/blogs/service_oriented/2012/06/knight_rules_of_ownership_in_service-
oriented_ecosystem.php
[6] Unified Modeling Language: Infrastructure, Version 2.0 (formal/05-05-05), Object Management
Group, March 2006.
[7] ITU Recommendation X.901 | ISO/IEC 10746-1:1998, Information Technology – Open Distributed Processing – Reference Model – Part 1: Overview, International Telecommunication Union, 1996.
[8] A Business Process Design Language, H. Eertink, W. Janssen, P. Oude Luttighuis, W. Teeuw, C. Vissers, in Proceedings of the First World Congress on Formal Methods, Toulouse, France, September 1999.
[9] Merriam-Webster Dictionary, http://www.merriam-webster.com/dictionary/interaction
[10] Wikipedia, http://en.wikipedia.org/wiki/Interaction
[11] Michael Poulin, “A Domain Service-Oriented Modelling or How SOA Meets DDD”, Part 1 and 2.
Business Ecology Initiative & Service-Oriented Solution. ebizQ BLOG Site.
[12] Alexander Samarin, “Improving business process management systems”. Trafford Publishing,
2009. ISBN-10 1426902565, ISBN-13 978-1426902567
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
4
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
1. Introduction: Why Don’t We Use ArchiMate yet? It is not a secret that Lingua Franca is one of the fundamental
conditions for success of any architectural work in an enterprise. It is
also not a secret that all previous attempts to establish such a
language between Business and Technology in the enterprise and
even between different Business divisions of the same enterprise
have usually failed. This, however, does not mean that we have to
give up. If we can produce an architectural language that simplifies,
at least, the interactions and understanding between architects, it
would be a significant step forward for an Enterprise and/or
Solutions Architecture. The ArchiMate 2.1 is such a language [1].
ArchiMate is terrific and terrible at the same time. The language
addresses a set of the most important concepts in both business
and technology domains but does it half-way or relies on
“common sense” in too many cases in my opinion. It is the very
problem - what we call “common sense” is de facto different to
every individual - architects and architectural schools; it is simply
impossible and unacceptable defining standardised language
constructs by referring to “common sense”.
For example, I have found that ArchiMate coves the majority of
fundamental business and application concepts used in practice of
architectural modelling. I would add only two more concepts to
this collection. However, the defined relationships between these
concepts contradict my experience collected for the last 30 years
in 17 companies working in the USA and the UK as well as the
rational I’ve learned as a certified architect.
I do not know whether these problems relate to ArchiMate or
caused by ‘integration’ with TOGAF and BMM conducted by The
Open Group. In any case, we have what inspires this review, which
has only one purpose – to improve ArchiMate for other users by
sharing my knowledge and understanding.
This paper is intended to cleanse and clarify all ArchiMate 2.1
clauses and definitions identified by or related to the Business and
Application Layers. OASIS SOA RAF [2] has defined that the
concept of service orientation spreads across Business and
Technology domains of any enterprise, which requires modelling
languages such as ArchiMate 2.1 to be accurate and precise,
especially for the Business domains. It is because regular
professional language of business is ambiguous in practice but
Business Architecture for the next
150 years
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
5
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
models of business architectural entities cannot allow such
ambiguity; we cannot staple an architect to the model or diagram
to explain what has been meant.
Following sections track the clauses of the ArchiMate 2.1
Specification published by The Open Group [1]. I will review every
statement, diagram, sentence and word in the Business Layer and
Application Layer chapters of the Specification. If some text of
those chapters does not appear in this review, it means that I do
not have comments for it; otherwise, the text/diagram will be
copied into this paper with related remarks or proposals. Some
words in the original Specification’s text will be highlighted by me
in order to focus on the entity/word/statement that’s caused my
notes.
Each following section comprises a table where statements from
the ArchiMate’s text, presented in the left-hand column, is
commented or questioned in the related row of the right-hand
column. All comments are authorised by me; all used quotes are
referred to the sources provided in the “References” section.
BuTechCon Ltd. cannot be held liable for my comments in any way
neither in the USA nor in the UK.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
6
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
2. Business Layer
2.1 Business Layer Metamodel
Comments in this section correspond with modern understanding of Business Architecture [3] and
Business Services [4].
The comments to the diagram in Fig. 1 do not substitute comments for individual entities shown in
that diagram but rather complement them. For example, a “Constraints” note in the diagram is a bit
confusing by its presence. Particularly, in order to have an interaction it is not necessary to have
collaboration. A definition of Collaboration in architecture may be found in the related sections of
comments.
The diagram in Fig. 1 is copied from the ArchiMate 2.1 Specification and appended with the author’s
comments.
In the sections of this chapter, I comment or criticise current statements of the ArchiMate 2.1
Specification and propose alternative wording or semantics in some cases. The reader obviously may
disagree with my point of view but even in this case I hope that an alternative view on Business
Architecture that I represent might be interesting to the reader.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
7
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
8
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Figure 1. Business Layer Metamodel Diagram with Comments
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
9
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
2.2 Structural Concepts
ArchiMate’s Statement Comments
The active structure aspect at the
business layer refers to the static
structure of an organization… Two
types of entities are distinguished:
• The active entities that are
the subjects (e.g., business actors
or business roles) that perform
behavior such as business
processes or functions
(capabilities…
• The passive entities (business
objects) that are manipulated by
behavior ...
An introduction of a notion of “active entities” in “the
static structure” is least expectable. Moreover, this notion is not used anywhere in the Business Layer. The definition of “passive entities” leaves the question: whether they have their own behaviour open for external triggers or they simply cannot act. In general, the note that “passive entities” may be manipulated by external (to them) behaviour does not preclude them from having their own behaviour. In the same line of logic, it would be very helpful to define, which type of entities may and may not initiate an activity or action of entities.
Business collaborations have been
inspired by collaborations as defined in
the UML 2.0 standard [6]
While detailed explanations of term “business collaboration” is provided in the related section, the meaning of collaboration in Business (in English) particularly differs from the meaning of “relationship of type collaboration” in the UML 2.0 standard1. The use of the word “inspired” does not provide, in my opinion, enough warning to the reader that the meanings of these terms may be quite different.
ArchiMate business collaboration
concept has a strong resemblance to
the “community” concept as defined in
the RM-ODP Enterprise Language [7],
as well as to the “interaction point”
concept, defined in Amber [8] as the
place where interactions occur.
While detailed explanations of terms “business collaboration” and “interaction” are provided in the related sections, it is possible to note here that the business collaboration may take place without business interactions between participants of the collaboration though it is not a frequently used collaboration pattern. An absence of a concept Action in the language makes aforementioned pattern unavailable for the modelling.
… it is uncommon in current business
layer modeling approaches to
recognize the business interface
concept
This statement seems obsolete to me. No business service can be accessed in any other way than via its business interfaces. It is unclear to me whether a business interface can constitute a separate concept; no business interfaces exist without business services that own the instances of the interfaces. For example, if we have a notion of telephone, several business services may have their call centres that use telephones as interfaces between the consumers and service representatives. However, a telephone itself is not a business interface
1 In UML 2.0, “A collaboration is represented as a kind of classifier and defines a set of cooperating entities to be played by instances”. This definition mistakenly mixes two English words making the entire definition ambiguous. A set of cooperating entities cannot form a collaboration because none of them collaborate in the set. Taking cooperation as collaboration and collaboration as just an action in English is illiterate.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
10
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
until it interfaces something. That is, a telephone has a capability to become a business interface.
2.3 Business Role
ArchiMate’s Statement Comments A business role is defined as the
responsibility for performing specific
behavior, to which an actor can be
assigned
This definition contracts, in my opinion, the majority of cases where the term Role is used in ArchiMate. This leads to one of two conclusions:
1) If the definition is correct, the use of this term in the ArchiMate’s text is mistaken
2) The definition of this term is mistaken while the usage is correct.
Explanation of the confusion is: a responsibility itself cannot act, i.e. a Role, as defined, cannot act. Proposed change of the definition: A business role is a set of Actor’s responsibilities for performing specific Actor’s behaviour. A business role is a passive entity until an Actor is assigned into it. A pair of business role and Actor appears as an active entity. Thus, different Actors may be assigned into the Role as well the same Actor can be assigned to different Roles at the same time.
Business processes or business
functions are assigned to a single
business role with certain
responsibilities or skills
Business processes or business functions exist on their own regardless of the existence of particular Business Role. In my business practice, it is the Business Role that is assigned to the business processes or business functions. This reversed relationship outlines the supremacy of Business Architecture of the company over the company’s personnel. A company and its Business Architecture exist without and independently from its personnel. A Business Role per se cannot have skills, only the Actor performing the Role can. A business function is rather a business abstraction of the business process [3] – a higher level. So, we can talk only about assigning a Business Role to the business function or to its implementation – business process, not the other way around.
A business interface … may be used by
a business role, while a business
interface may be part of a business
role …
According to ArchiMate’s definitions of Business Role, it cannot use and (does not need to) include a business interface – a set of responsibilities is intangible and cannot have an interface.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
11
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
If a Business Role is defined as I have proposed in this paper, a Business Role (related Actor) can use a business interfaces.
Example. In the model below, the
business role Insurance Seller is
fulfilled by the Insurance Department actor and
has telephone as a provided interface.
The business role Insurance Buyer is
fulfilled by the Customer actor, and
has telephone as a required interface.
According to ArchiMate’s definitions of Business Role, it cannot and does not need to include a business interface (see above). An Actor fulfilling the Role may use/have a telephone as an interface.
Diagram in “Example 2: Business Role”
Business Role cannot include a business interface from the architectural reasonable viewpoint, in my opinion.
2.4 Business Collaboration
ArchiMate’s Statement Comments
Business collaboration is defined as an
aggregate of two or more business
roles that work together to perform
collective behavior
Given definition oversimplifies the core and modelling of collaboration of business. Any business has an architectural scenario of collective work with another business. This relates to all forms of business organisation – from the enterprise level to the team level. The collective work is usually described based on the patterns of Business Collaboration and Business Cooperation. The major difference between Business Collaboration and Business Cooperation is in that participants of the collaboration take the collaboration’s business goal as their own business goal, which may lead and frequently leads to changes in the participant’s internal operations, activities, business processes, or even business functions. Because of such changes, interactions between collaboration participants are not required in 100% of cases – after these changes the participants can produce desirable result of collaboration sometimes even without interactions. In contrast, participants of the Business Cooperation do not make the cooperation’s business goal as their own. They perform their own behaviour while the produced results are combined, which constitutes the outcome of the cooperation. The participants of cooperation are not necessarily needed to interact while a 3rd party can collect the results. The UML term “aggregation” corresponds to the Business Cooperation since all aggregated participants
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
12
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
are gathered as-is, without making the collaboration goal their own; each of aggregation participants continue their own life-cycles after the aggregations eliminates. Business Collaboration is closer to the UML concept of composition. When the composition eliminates each participant eliminates as well. In business, this is equivalent to retiring and eliminating those parts of the business that were changed specifically for the purpose of complete/eliminated collaboration. In the majority of business practices, different organisations cooperate rather than collaborate but call it “collaboration”. This ambiguity is unacceptable in the modelling language, in my opinion. The use of term Business Role in provided statement contradicts the meaning of Business Role currently given by ArchiMate.
A business process or function may be
interpreted as the internal behaviour
assigned to a single business role
It is the Business Role may be assigned to “A business
process or function”, not the other way around, I believe. Business Roles come and go; business functions and even business process stay. I believe that the referred statement turns the business model of the company up-side down making temporary Roles more important than the business functionality and its implementation. This contradicts the subject of Business Architecture [3].
In some cases behavior is the collective
effort of more than one business role The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate. A set of responsibilities cannot have an effort; an action-based behaviour cannot be produced by the sets of responsibilities per se.
… in fact a collaboration of two or more
business roles results in collective
behavior which may be more than
simply the sum of the behavior of the
separate roles.
The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate. A business role – a set of business responsibilities – cannot collaborate and act. A “collective behavior” cannot “be more than simply the
sum of the behavior of the separate roles” only because it is collective. There should be something more than just the group of participants and their responsibilities and only this “something” might be associated with the “more than simply the sum”. ArchiMate’s statement
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
13
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
omits this “something”. For example, a business process is more than simply a sum of its intermediary results because it has its business logic, which constitutes “more than simply a sum”. None of the process steps or suppliers has this process’ business logic and, once created, the business process logic exists on its own regardless process workers, involved actions, suppliers, managers, and so on.
A collaboration is a (possibly
temporary) collection of roles within
an organization which perform
collaborative behavior (interactions).
The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate. Collections of such Roles (sets of responsibilities) cannot perform any behaviour or actions. Business Collaboration is not a “collection of roles” by definition but a collection of activities (Actions) or behaviours of the participating business entities. A Business Collaboration may require such Business Roles that none of the participating businesses has before entering into the collaboration. In some cases, Business Collaboration, which should be modelled, can cross the organisational boundaries. Collective behaviour does not necessarily assume “interactions”. See explanations before.
However, a business collaboration can
be regarded as a kind of “virtual role”… The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate. A Business Collaboration can be interpreted, in my opinion, as a kind of virtual Action or behaviour conducted by a virtual Actor.
A business collaboration may be
composed of a number of business
roles, and may be assigned to one or
more business interactions
This composition will not represent the essence of collaboration if follows the meaning of Business Role currently given by ArchiMate. A set of responsibilities cannot act or interact. “A business collaboration may be composed of a number
of business role” represents an incomplete (ambiguous) description of a business collaboration, in my opinion, because the latter is about Actions and activities rather than Roles. An assignment of collaboration to an interaction is very confusing to me. A Business Collaboration is usually understood at a high business level, as a form of collective business work like a programme or corporate /divisional transformation, while a business interaction is a single act of exchange of information or two related
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
14
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Actions. It would be much more comprehensive saying that “one or more business interactions” may be assigned to the Business Collaboration. The interpretation of the term “interaction” is provided in the corresponding section.
Diagram in figure “Example 3: Business Collaboration”
The diagram demonstrates an example of Business Cooperation, not Collaboration. None of the aggregated entities has any special association with Collaboration modules, i.e. the diagram does not demonstrate that participants “work together to perform collective
behavior”. I have a concern about the capability of UML to express the essence of business relationships in Business Collaboration.
2.5 Business Interface
ArchiMate’s Statement Comments A business interface is defined as a
point of access where a business service
is made available to the environment
At a glance, the question is: why Business Interface relates to Business Service only? If ArchiMate were adopted the modern understanding that Business Services realise Business Functions while Business Processes and Actions realise Business Services, then I would not have any objections to this definition. However, such adoption is not confirmed and a statement that Business Interface is a point of access to Business Service may have two opposite readings. First, in Service-Oriented Ecosystem (see OASIS SOA RAF specification), it is the very Business Service that decides what Business Interfaces to expose to the environment; it is the service that drives the interface, not the other way around. Also, the given definition allows a mistaken interpretation that a Business Interface may exist on its own – “as a point of access” – regardless of the Business Service it interfaces to. In Service-Oriented Ecosystem Business Interface does not make any sense without the Business Service.
A business interface exposes the
functionality of a business service to
other business roles (provided
interface), or expects functionality
from other business services…
Business Interface is a passive element of the “interaction pipe”, IMO; it does not act, expose or expect. It is a Business Service exposes or expects business functionality via its Business Interfaces.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
15
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Business Interface defines and exposes only the interaction means of the Business Service. The Business Interface does not necessary make any visibility into Business Service functionality. The names of the elements of the Business Interface may have no semantic correlation with real functionality of the Business Service. According to the OASIS SOA RAF specification, business functionality of the Business Service is exposed to the consumers / environment via a Service Description [2], which can include all public Business Interfaces and their SLA, plus, some other informational elements. Business Interface is only a mechanism of interactions with the external environment. The only role in this environment defined is the role of Service’s Consumer (Actor). All Actors communicating with the Business Service via its Business Interfaces become or play a role of Service’s Consumers. Business Interfaces may act only upon an agreement Service’s Consumers that use this interface for interactions. This agreement is defined in the OASIS SOA RAF specification as a Service Contract [2], which may be explicit and implicit.
A business interface may be part of a
business role … The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate. Related explanations regarding a Role or Actor and an interface are given before. A Business Interface is the part of Business Service only. In regular enterprise, a Business Service has a supremacy over Business Roles.
…and a business interface may be used
by a business role The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate. A Role, as defined in ArchiMate, cannot act, i.e. cannot use anything. Only an Actor in the Business Role can use an interface.
A business interface may be assigned
to one or more business services… In my opinion, the practice is right opposite – a Business Service can expose one or more Business Interfaces. Business Interface cannot exist without the entity it interfaces to.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
16
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Two or more independent Business Services may have the same logical Business Interface but they never share the same instance of the Business Interface, which contradicts the Principles of Service Orientation, concept of service ownership and OASIS SOA RAF specification.
2.6 Business Object
ArchiMate’s Statement Comments A business object is defined as a passive
element that has relevance from a
business perspective
Based on this definition, a Business Object can represent anything that does not have behaviour (or cannot initiate behaviour by itself). To me, the definition is quite uncertain with this regard and, thus, error-prone.
Business objects are passive in the sense
that they do not trigger or perform
processes
It is unclear why only a process is mentioned in the statement. Can a Business Object trigger an action, a function or a service, for example?
2.7 Behavioural Concepts
ArchiMate’s Statement Comments A business process represents a
workflow or value stream consisting of
smaller processes/functions…
In my opinion, it is not always right that a Business Process consists of “smaller processes/functions”. There may be no sub-processes. Functions are rather abstractions that may be implemented via services of actions. Process is an implementation of function; it can use other implementation means. Since ArchiMate does not define Action, description of a process becomes cumbersome. A Business Process is a workflow of value of is a special value-stream. The workflow of stream value-stream must have a predefined business logic in order to form a process and Business Process in particular. According to modern understanding of Business Architecture, a Business Function may be implemented by a Business Process. The letter, in turn, appears as an implementation of Business Service to the process/service consumers. The process’ business logic comprises process steps that require intermediary values; who and how produces these values is irrelevant to the process. The producer may be a sub-process, or a service, or an action. The sub-process or a service can utilise values produced by
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
17
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
other sub-processes or a services, and so on. In a strict definition of the process, and Business Process in particular, providers of the intermediary values are arbitrary entities and do not belong to the process. One process can be unambiguously distinguished from another process by only one characteristic – the process’s business logic. A change in the providers does not change the process; a change in the process’ business logic results in a new process. No business process can be improved: it can either provide better outcome because of better intermediary values or it can be replaced by another process with better outcome [3].
Typically, the business processes of an
organization are defined based on the
products and services that the
organization offers, while the business
functions are the basis for, for example,
the assignment of resources to tasks and
the application support
This is a relatively common misconception, in my opinion. Business Process can utilise the results of Business Services while the latter implement Business Functions. In turn, every Business Process appears as a Business Service to its consumers. Again, Business Process is defined based on HOW it utilises intermediary values in order to deliver a pre-defined outcome. Nonetheless, how these intermediary values are created and provided is not a concern of the Business Process until the delivery SLAs are preserved by suppliers. The Business Function defines WHAT business should do in order to reach its business objectives. The categories of resources of any kind (technical or human) belong to the function implementation, i.e. to HOW the business would work to realise what is defined in the function. Thus, resources are the Business Process prerogative. An outcome of a Business Process may be a product while the Business Process is the service implementation. At the same time, a product may be a combination of outcome from several services and include combinations of other products.
A business interaction is a unit of
behaviour similar to a business process
or function…
The concept of Business Interaction is commented and explained in the related section below. Without defining a concept of Action, it is impossible to define a concept of Interaction, in my opinion. To express a collective work in a global sense, we have different terms like cooperation or collaborations. It is highly recommended to distinguish between a unit and a collection of units of work. In my experience, an
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
18
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Interaction is used to be understood as a fraction of collective work. In essence, an interaction is a joint of two Actions. The OASIS SOA RAF specification defines a Joint Action in full. I would not compare an Interaction with a Business Function because 1) function addresses incomparably more complex level of behaviour, and 2) interactions are used to be associated with the Business Function’s implementation rather than with the Business Function itself, which is an abstraction. Regarding comparison to a Business Process, the difficulty comes from the difference in the point of view: from the Business Function perspectives, a Business Process is a single unit of work while from the process’ perspective it is an ordered (business logic) collection of units of work. An Interaction can become very ambiguous if not linked to the business execution context (see OASIS SOA RAF specification for the definition). That is, the “two-way effect” depends on the communication and execution policies that regulate both the Actions and effect.
…function, but which is performed in a
collaboration of two or more roles
within the organization.
For an interaction between two business entities neither Business Collaboration nor Business Cooperation is required but rather usually conducted. Two business entities can act toward each other without any actions from one to another. For example, one company requires some information (RFI) from another company before any relationships between them are established; knowing this, the second company publishes this information up-front on public Web. The first company collects needed information from the Web when needed; no interactions between companies are perdormed. The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate.
2.8 Business Process
ArchiMate’s Statement Comments A business process is defined as a
behavior element that groups behavior
based on an ordering of activities …
An understanding of a Business Process based on activities is very popular but, I believe, obsolete already. None of the collections of activities can identify
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
19
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
particular Business Process because they may be used in many different Business Processes simultaneously. However, a Business Process has one business value that none of activities can have – it is a business logic of the process (see [3]). From the process perspective, it is irrelevant who/what and how provides values for the intermediary process’ steps if this is done in compliance with pre-defined SLAs. In the process, the “behavior element that groups
behavior” of process steps puts in order the intermediary values/results rather than activities (which are undefined in the ArchiMate).
A business process describes the
internal behaviour performed by a
business role that is required to
produce a set of products and services
A business process describes the outcome/value/result to be obtained via predefined interface; a business process does not care about an “internal behaviour” of providers of intermediary suppliers [3]. If a Business Process is performed by a single worker – a “business
role that is required to produce …” – it is still not an “internal behaviour” but clear external realisation of the business logic of the process (which is independent from the “internal behaviour performed by a business role”). From the viewpoint that sees an enterprise as a structure of systems or as a super-system, people and people groups serve the enterprise, not the other way around. If this viewpoint is taken for architectural modelling, Business Process describes its own behaviour or business logic regardless the Actor in the Role or Role itself. Not everything a Business Role performs is a Business Process. The crucial difference of the Business Process from other types of Actor’s activities is that the Business Process must be repeatable in the same execution context by different Actors. If a Business Role produces products or services in a non-repeatable manner, this cannot be qualified as a Business Process (but rather as a Business Case) but this difference is omitted in the given definition. The products or services are associated in this case with the Business Process, not with those who execute it (Business Roles). A product or its part(s) may be a result of a Business Process. However, any Business Process is a Business Service for the consumer of its results. That
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
20
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
is, a Business Process does not produce a Business Service but realises it. The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate.
In comparison to a business interaction,
in which a collaboration of two or
more business roles are (interactively)
involved, at a given level of granularity
only one business role is involved with
a business process.
A Business Interaction, as it was explained earlier, requires neither Business Collaboration nor Cooperation. In the Business Interaction, at least two participants have to perform related actions (that are undefined in the ArchiMate). That is, a Business Interaction assumes two Actors, not two Business Roles (because both Actors may be in the same Business Role). The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate. A Business Process indeed needs one Business Role of a holder of the business process logic but this is not a constraint and the same Business Process may use two or more Business Roles. For more complex logic and a numbers of alternative Business Process branches, a need in more than one Business Role is more likely. Anyway, a concept of Business Process cannot guarantee at any level of granularity that only one Business Role should be “involved with a business
process”.
… finer-grained processes, each of
which may be assigned to finer-grained
roles that are aggregated by roles that
are aggregated by the original role
No Business Process can be assigned to the Business Role but the other way around. A granularity of the Business Process is not in any direct impact on the granularity of the Business Roles working with this process.
… processes describe some kind of
“flow” of activities, whereas functions
group activities according to required
skills, knowledge, resources, etc.
Business Process describes a flow/logic of steps regardless activities that provide the intermediary values for these steps. Functions assume activities that should be articulated in the terms of WHAT should be done in order to reach the function’s outcome, not HOW this outcome may be reached. That is, “skills, knowledge, resources, etc.” relate not to the Business Functions but to their arbitrary implementations via Business Services and, respectively, a Business Processes.
A business process may access business
objects. A Business Process does not access anything but its own logic. It is the supplier of the Business Process can “access business objects”. A Business Process, as any process, defines the intermediary interfaces that are
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
21
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
used by suppliers to provide intermediary values/results. It is quite possible that for delivering the same intermediary value one supplier needs to access one Business Object while another supplier needs to access another Business Object.
A business process may realize one or
more business services and may use
(internal) business services or
application services.
In other words, a Business Process may be used by one or several Business Services as their implementations or as a part of the implementations. However, no Business Services will share their implementation or body; this is against several Principles of Service Orientation. Thus, if certain Business Process is needed by more than one Business Service, this Business Process must be externalised and represented as a new Business Service; in this case it might be a Business Utility Service. Alternatively, this Business Process should be cloned and owned by those Business Services in need. For example, a process of paying with a Credit Card used by many retail Business Services should become a Credit Card Payment Service serving different retail Business Services or copied into the body of the each retail Business Service. The Business Service defines the service boundaries for its implementation and owns everything in these boundaries.
2.9 Business Function
ArchiMate’s Statement Comments A business function is defined as a behavior
element that groups behavior based on a
chosen set of criteria (typically required
business resources and/or competences).
Business Function is one of the fundamental elements of Business Architecture [3].Business Function defines WHAT business/organisation/ enterprise/division is doing to meet strategic business goals and objectives as well as how the consumer of the business sees this business in the market. Particular Business Function defines what behaviour should be realised in the function’s implementation and what the success criteria for this implementation. Business Function does not behave but defines what should be done. Business “resources” belong to the Function’s implementation while the Business Function itself is an architectural business abstraction that may have an arbitrary implementation via Business Services
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
22
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
that, in turn, may be implemented by Business Processes as well as participate in Business Collaborations, Business Interactions and activities. Business competences are the first level of Business Function decomposition pointing to what company is doing with regard to particular Business Function. In contrast, business capabilities are what the company will be able to do under certain conditions. Business Function is defined in the business domain top-down rather than bottom-up. Some Business Functions can be decomposed into more grained Business Functions while others cannot.
…a business function also describes internal
behaviour performed by a business role. Business Function is used to define an external and internal functionality of the business entity(what business functional values are available from a company or its internal division). In the Enterprise Business Model – the initial definition of what a company is doing in the market – Business Functions describe external behaviour first of all. The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate.
… a business process forms a string of
business functions. A Business Process, being an implementation of Business Function or Business Service, can cross the boundaries of other Business Functions. A Business Process does not form “a string of business
functions” because the latter exist independently from the Business Process; instead, it organises a use of Business Functions in certain order or business logic of the process.
A business function may access business
objects. A Business Function’s implementation can access Business Objects, not the Business Function itself because it is an abstraction.
A business function may realize one or
more business services Business Service is the first level of implementation of Business Function. That is, it is a Business Service may and always does realise a Business Function . The Enterprise Business Model comprises Business Functions that are later translated into the Business Services and into business capabilities. The latter may be implemented in the form of Business Processes as well as grouped by Business Services and/or Processes.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
23
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Example. Moreover, business functions may
access business objects Business Function is a business abstraction that defines what the business does or can do. Only an implementation of Business Functions can access something, e.g., Business Objects.
Diagram “Example 8: Business Function” Business Functions such as Customer Handling, Basic Administration and Financial Handling may have particular Insurer to be assigned to them while the Insurer itself might be not even aware of this assignment. Thus, the Insurer can be in only Association relationship with these functions, not in the Assignment relationship.
2.10 Business Interaction
ArchiMate’s Statement Comments A business interaction is defined as a
behavior element that describes the behavior
of a business collaboration.
An ‘interaction’ in English means “mutual or reciprocal action or influence” [9], it is “a kind of action that occurs as two or more objects have an effect upon one another. The idea of a two-way effect is essential in the concept of interaction” [10]. Business Interaction addresses a low level event of exchanging information or actions between two business entities. This exchange does not need to be pre-defined or agreed, i.e. it may be unrelated to any processes or collaboration. A Business Interaction has several business prerequisites: a) need; b) willingness, c) ability. They are universal, may relate to BPM but irrelevant to any higher level of organisation of business activates like Business Collaboration. Moreover, a Business Collaboration can take place without any interactions between its participants.
A business interaction is similar to a
business process/function, but while a
process/function may be performed by a
single role, an interaction is performed by a
collaboration of multiple roles.
The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate (responsibilities cannot act by itself). A Business Interaction may be “similar to a business
process/function” only in the sense that all of them relate to an action, which is not defined in this version of ArchiMate.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
24
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
A business interaction may access business
objects. An interaction in English is an act, in which entities perform actions towards each other. In ArchiMate a Business Object cannot have behaviour. If one interaction participant accesses a Business Object, the latter cannot act in response, i.e. this is not an interaction. If this participant changes the Business Object, it is still a single-side action. Thus, a Business Object cannot participate in an interaction. However, a Business Object may be exchanged as a result of an interaction but this happens with no participation in the interaction because the Business Object is not aware of how and where it is used.
A business interaction may realize one or
more business services and may use
(internal) business services or application
services.
A Business Interaction may be only a result of execution of a Business Service realised by its body/system; an essence of the service is not in its action against another service or consumer. An interaction is a combination of two actions of two participants. What the internal mechanisms triggered by interaction is visible neither to the actions nor to another participant. An Interaction itself does not exist on its own and, when executed, cannot act/use any other Business or Application Services.
A business collaboration or an application
collaboration may be assigned to a business
interaction.
A Business Interaction is one of the lowest elements of inter-entity communication. A Business Interaction can be one of the parts of Business or Application Collaboration but not the other way around.
Example. The business interaction Take out combined insurance is performed as
collaboration between the travel and
luggage insurance seller.
The diagram for this Example does not reflect a collaborative relationship between “travel and luggage insurance sellers”; the diagram may be read as business cooperation because of the UML aggregation sign. An interaction cannot be performed as collaboration because is a trivial act (Action) of communication while Business Collaboration is pattern of several inter- or intra-acts (Actions) The assignment relationship between the collaboration and interaction in the diagram is ambiguous since it does not show the direction of the assignment.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
25
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
A Business Interaction cannot use a Business Object, especially a Policy, because it is the very interaction should be conducted in accordance/compliance with or under the Policy. The diagram depicts a wrong subordination between a policy and action, in my opinion. One of preconditions of Business Interaction is participation of two Actors. Given diagram shows only one Actor – “the travel and luggage insurance
seller”
2.11 Business Event
ArchiMate’s Statement Comments A business event is defined as something that
happens (internally or externally) and
influences behavior.
In business domain, a Business Event does not necessarily results in the change of behaviour or other influences onto the behaviour of business entities. A Business Event may simply change the state of Business Execution Context/environment or an entity in this environment without an influence on behaviour. The use of “and” in the given statement narrows modelling abilities with regard to Business Events while it does not demonstrate any noticeable benefit for modelling, in my opinion.
…a business event is instantaneous: it does
not have duration… A business event may
access a business object
If a Business Event is instantaneous, it cannot access anything including Business Object because an act of “access” has a physical duration. Apparently, here is a noted earlier mixture between the event itself, distributions of information about the event (via distributions of a Business Object) and acting under the constraints caused by the Business Event.
Diagram “Example 10: Business Event” Regarding the “Send portfolio”, the event here is not a request but a fact of receiving the request (according to the diagram).
2.12 Business Service
ArchiMate’s Statement Comments A business service is defined as a service that
fulfills a business need for a customer
(internal or external to the organization).
Defining something via external view on it is a mistake according to ISO/IEC/IEEE 42010:2011. An external view can only describe the entity based on subjective viewpoint/perceptions. If a Service fulfils a business need on one customer and non-business
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
26
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
needs of another customer, is this a Business Service? In contrast, the essence of the definition of Business Service [3] is in that it realises particular Business Function or feature regardless if a customer needs it or not. A Business Service can exist without customers for a while; if Business Service is not utilised for certain time it can become a bankrupt and leave the market. It has been noticed that in the previous ArchiMate texts business service was introduced predominately for the use of external users of the organisation.
A business service exposes the functionality
of business roles or collaborations to their
environment.
According to the current version of ArchiMate, a Business Role cannot have functionality. Business Service offers/exposes business functionality and/or business capability to potential service consumers regardless any Business Roles. Business Service hides all its internal activities and organisation. An implementation of Business Service or service’s body can change any moment together with involved Business Roles with practically no effect for the service except the quality of its outcome. Business Functionality represented by the Business Service exists regardless any Business Roles that might realise it. Certain level of abstraction should be applied to both Business Service and Business Functionality, which given statement does not demonstrate, in my opinion.
A business service is realized by one or more
business processes, business functions, or
business interactions that are performed by
the business roles…
Business Functions are realised by Business Services, not the other way around. No Services can be realised by Interactions; an implementation of a service can interact with the consumer but an Interaction per se is not a realisation of the Service. The use of term Role here contradicts the meaning of Business Role currently given by ArchiMate.
A business service should provide a unit of
functionality that is meaningful from the
point of view of the environment
Business Service ”should provide a unit of
functionality that is meaningful” to the service consumers, not necessarily to the rest of the
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
27
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
service execution environment. Business services can be external, customer-
facing services (e.g., a travel insurance
service) or internal support services (e.g., a
resource management service)
In the Service-Oriented Ecosystem (OASIS SOA RAF), any Business Service may face consumers/customers irrespective their location regarding the corporate boundaries. This is the very reason why corporate services must be competitive in the market or replaced by / outsourced to external service providers. Nothing should change in the Business Service in order to face internal or external customers/consumers. At the same time, an admitting the fact Business Services can be “internal support services” is a very important step forward toward the Service-Oriented Business/Enterprise.
A business service may be used by a business
process, business function, or business
interaction.
Business Interaction itself cannot use anything, IMO, – it is an act or actions that can be part of a service realisation. A Business Function is an abstraction and it does not use but is realised via a Business Service.
A business interface or application interface
may be assigned to a business service. A business interface does not exist without a Business Service. A business interface may be exposed by a Business Service but not assigned to Business or Application Service. An implementation of a Business Service can use an Application Interface but Business Service itself uses only Business Interfaces (in the modelling).
A business service may access business
objects. It is unclear in which sense “access” is used. A Business Interfaces is a means of passing things through including Business Objects. If given “access” is meant for marshalling/unmarshalling of Business Objects, then no comments applied here. Otherwise, I have to outline that it is the implementation of Business Service may access Business Objects.
The name of a business service should
preferably be a verb ending with “-ing”; e.g.,
“transaction processing”…
In English, “a verb ending with “-ing”” is called gerund and represents a special form of a noun.
2.13 Information Concepts
ArchiMate’s Statement Comments
… a number of informational concepts that
focus on what we could call the
“intentional” perspective
Term “intentional” requires more explanations. An intention is what we would like to have but do not have it at the moment. It is unclear, in my opinion, how an intention relates to information in given
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
28
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
context. Information is fundamentally related to
communication. Information is fundamentally related to interpretation and knowledge and can exist with no communication whatsoever. It is a communication fundamentally relates to information, not the other way around.
Information always serves a particular
purpose, which is tightly connected to some
communicational goal…
Information can exist with no communication whatsoever as well as the information purpose only optionally relates to communication goal. A communication is a secondary purpose of information. A modelling value of a ‘mandatory’ linking information to communication is unclear to me in given context. At the same time, an interpretation of information does link to “some
communicational goal”.
… a dynamic part (the communication action
itself)… Term “action” is not defined in ArchiMate.
A meaning description is not equal to the
representation causing the meaning Usually, a meaning is independent from representation. In my opinion, it is considered a Bad Practice when a representation causes a meaning, e.g. when the same term between the exchanging parties has different meaning if it is used in the e-mail text and in the document attached to this e-mail.
The most important elements of such a
context are the actors sending and receiving
the business object, the time and place of
communication and the environment in which
this happens.
Since term “environment” is not defined in ArchiMate, this statement appears ambiguous. For example, I cannot be sure if Actors who are not “sending and receiving the business object” are excluded from the context? Are certain policies and regulations included in or excluded from this context?
We see a (financial or
information) product as of a collection of
services…
Why “financial” has a special focus in this statement? What is the modelling value in it? I, for example, see a lot of financial products that have nothing to do with services (practically all investment financial products). In my opinion, given argument is too weak to declare that a product is always a collection of services. However, this may be a modelling principle. Nonetheless, I agree and support a statement, which says that a product is a combination (composition or aggregation) of the service results/outcome. Whether a direct link between a
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
29
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
product and a service correct is totally contextual.
…together with a contract that specifies the
characteristics, rights, and requirements
associated with the product.
Given enumeration of contract characteristics misses the most important element of the product contract – the set of policies specified for the use of this product in particular context.
2.14 Representation
ArchiMate’s Statement Comments A representation may realize one or more
business objects. A representation cannot realise; instead it can show/depict/illustrate/display/represent a Business Object.
Example. The model below shows the
business object Request for insurance… The “Example 12: Representation” does not show “the business object Request for insurance”
2.15 Meaning
ArchiMate’s Statement Comments Meaning is defined as the knowledge or
expertise present in a business object … Does this definition mean that a function, service, action, value may not have a meaning or their meaning cannot be presented via anything than a Business Object? Meaning or ontology is usually defined regardless particular presentation. Meaning is, first of all, associated with an entity that acts on the Business Object. The Business Object may have very different arbitrary meanings to different observers, i.e. defining a meaning via presentation in a Business Object is incomplete and inconsistent, IMO.
A meaning is the information-related
counterpart of a value: it represents the
intention of a business object or
representation (…). It is a description that
expresses the intent of a representation;
i.e., how it informs the external user.
A meaning cannot be a counterpart of a business value because the latter has one or more meanings depending on the business context. Business Object, as interpreted in ArchiMate, cannot have an intention. Meaning is independent form a representation. For example, a letter on a paper or on a CD is still a letter. Meaning is knowledge while an intention relates to particular Actor and action. The meaning may be delivered via a representation, but representation itself does not have its own intention. Someone who creates particular representation may have an intention to demonstrate the meaning this person
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
30
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
has.
It is possible that different users view the
informative functionality of a business
object …
According to the definition of Business Object given in ArchiMate, a Business Object may not have any functionality (which associates with actions)
Example. …an Insurance policy
document that is the representation of
an Insurance policy, which is a business
object. The meaning related to this
document is the Insurance policy notification, which consists of a Policy explanation, an Insurance registration,
and a Coverage description.
The meaning of Insurance policy in this example is expressed via “a Policy explanation, an Insurance
registration, and a Coverage description” while Insurance policy notification is another representation. The meaning of the Insurance policy notification is a “notification” itself.
2.16 Value
ArchiMate’s Statement Comments Value is defined as the relative worth, utility,
or importance of a business service or
product.
Does this mean that no value may be associated with Business Function, Business Object, Business Process or Actions? I think that Business Value has both tangible and intangible aspects. For example, a product is a tangible value because it consists of the outcomes of actions and services. At the same time, the presence/availability of a Business Function realised by the service is an intangible value for the (potential) consumers. A customer choses a service because it provides/offers particular Business Function first, then the customer reviews Policies and Regulations the service may be used under, and only then the consumer considers service’s Business Interfaces.
A value can be associated with business
services and, indirectly, with the products
they are part of, and the roles or actors that
use them.
Products are usually the outcome of Business Services. Thus, a Product may have a direct value that comprised individual values of engaged Business Services. Users of Business Services – “roles or actors” – do not automatically “inherit” values of the Services. These “roles or actors” may be of value incomparable to the value of the Service. However, “roles or actors” can consume/use the Service’s
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
31
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
value; in this case it is unclear why an association should be “indirectly”.
… where the “functional” value of a service
is concerned it is recommended to try and
express it as an action or state that can be
performed or reached as a result of the
corresponding service being available
ArchiMate does not define a notion of Action. A state can exist or be reached but cannot be performed (in English) No value exists or can be obtained or materialised from only the fact that a service is being available. The value, especially business values, is the result of the service execution, i.e. of the service action.
2.17 Product
ArchiMate’s Statement Comments A product is defined as a coherent collection
of services, accompanied… This definition seems too restrictive since it excludes an option where one product can be a part of another product. For example, a lot of products like “financial complex derivatives” contain numerous simple or vanilla derivative products. In relatively common opinion [2,3,4], service is associated with Actions while product may be a tangible entity generated as a special combination of tangible service outcome.
This definition describes financial, services-
based, or information products… An example provided above shows that the given definition does not describe specifically financial products.
… that are common in information-intensive
organizations, rather than physical
products.
Does this mean that ArchiMate is not suitable for modelling “physical products”? If so, is ArchiMate really suitable for Business at large and for business architectural modelling particularly?
“Buying” a product gives the customer the
right to use the associated services. An essence of “buying” is the ownership. If a business product is bought while it includes services, the services are also owned by the buyer and the latter can do anything with included services. However, an expression “associated services” may mean the services, which are the parts of the product as well as the services that use this product or other products that the bought product is a part of. In the latter case, buying a product does not “gives the customer the right to use the associated
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
32
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
services”. For example, if a car owner buys a part for its car, this does not mean that s/he gets the right for a full Car Maintenance Service though this Service certainly includes the Maintenance Services of the bought part. In my opinion, ArchiMate is missing a concept of ownership, which is so important for modelling in/for business.
A product may aggregate business services
or application services, as well as a contract. A notion of term “aggregate” assumes a collection of more than one thing. That is, the given statement should, at least, say “contracts”. Contracts are usually external subjects to products while may be associated with them. A product can exist without a product contract. A product contract cannot exist (as an instance) without a product. At the same time, a contract is owned by the owner/user of the product, not by the product itself. Thus, in my opinion, a product cannot aggregate contracts on its own; contracts do not make any part of the product. At the same time, contracts may be aggregated by an entity in relation to the product, which is not the same thing and a product aggregating contracts. In the Service-Oriented Ecosystems, the ownership of service works differently than the ownership of the service outcome or products. Particularly, if one buys a product that includes a Service A, this service may be in contractual relationships with a Service B. The fact that one owns A does not mean that s/he owns the contract with Service B automatically. The Service B has to endorse the contract with the new owner but is not obliged to do this.
Example. In the model below, a bank offers
the product Telebanking account to its
customers. Opening an account as well as
application support (i.e., helpdesk and the
like), are modeled as business services
realized by the Customer relations department.
Provided example, in my opinion, is a typical modelling and design for the end of the last century. A product should not include actions/activities that may be applied to it (e.g. “opening” and actions of “application support”). These actions/activities are
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
33
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
controlled by the access rights (security) associated with the Actor. The product has no idea how it may be used in one context or another. A contract is also should be an external subject of the product – the contract may change for the same product with no awareness of the product provided. Moreover, if a contract with a user is a part of the product, this leads to the security gap: when the user is removed and the contract stays (in the product) someone can pretend later on to be that user and gain an unauthorised access to the product.
2.18 Contract
ArchiMate’s Statement Comments A contract is defined as a formal or informal
specification of an agreement that specifies
the rights and obligations associated with a
product.
Given definition is assumed incomplete in my opinion. It artificially narrows the scope by products only. In reality, Business and Application Services may have their contracts as well. Then, the definition does not state whose rights and obligations it refers to. Given definition is omitting to mention conditions, in which “the rights
and obligations” are applicable. Even if conditions are assumed to be a part of the “the rights and
obligations, their absence in the wording allows for skipping or ignoring them. According to OASIS SOA RAF, these conditions are expressed via: policies of execution (business context), communication means and execution/communication SLA, in particular.
… but also a more informal agreement
associated with a product. There is no justification provided for such a statement.
Diagram at Example 16: Contract In the diagram, the “Telebanking account” may have several contracts but they cannot exist without the “Telebanking account”. That is, the relationships between them should be a composition from “Telebanking account” to “Telebanking contract” (a filled rhomb). “Telebanking contract” may have many “Service conditions” as an aggregation; some conditions may exist regardless the contract. Also, the same
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
34
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
“Telebanking contract” may have many “Service Level Agreements” but only via a composition relationship (a filled rhomb) because an SAL without the contract does make sense.
2.19 Summary of Business Layer Concepts
The enumeration of concepts and definitions given in the Table 1 of the ArchiMate specification
omits an element used/referred/assumed widely in the specification – it is Business Action concept.
It is highly recommended to add this concept to complete the set of Business Service – Business
Process – Business Interaction concepts.
An additional recommendation may go to introducing a concept of Business Capability. A Business
Capability occupies the position between Business Layer – Behavioural Concepts and Application
Layer - Behavioural Concepts but shift more toward the Business Layer. A Business Capability is an
ability of a business or organisation/company to execute certain business function in the future
under pre-defined conditions/circumstances. Thus, a Business Capability comprises pre-defined
business function(s), which may be expressed as a service, with the reserved or planned
implementation resources. If only Business Function is defined but no resources are
available/planned, the business/organisation/company does not have this identified capability.
ArchiMate provides some means to model a Business Capability without defining a special “language
symbol”. However, in several modelling cases, it might be very convenient to model a landscape of
Business Capabilities without defining each of them in the same diagram but referring them by a
special symbol.
Finally, it is highly recommended to introduce a concept of ownership. Business modelling is
handicapped without such a concept. It will be necessary to address the aspects of ownership in the
world of Business Services [5] versus Products and Applications.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
35
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
3. Application Layer
3.1 Application Layer Metamodel
In ArchiMate 2.1, an Application Layer Metamodel faces a challenge of combining two not fully
overlapping concepts of Service and Object Orientation. Particularly, in SO, a Function is realised by a
Service that, in turn, is realised by the Application. As service oriented mentality is extravert. Also, in
SO, an Interface is a derivative from the Service and provides all interaction means needed by the
Service; an Interface cannot exist without the Service. In contrast, in OO, an object is more introvert
and interfaces can exist on their own.
Figure 2. Application Layer Metamodel Diagram with Comments
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
36
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Talking about activities and joint activities of elements in SO and OO, a term collaboration in English
means that participants of the collaboration make the collaboration goals and objectives their own
goals and objectives. This, if needed, leads to changing internal organisations, resources, operations
of the participants. Thus, if an entity wants to participate in several collaborations, this entity is
ready to change its internal as many times as needed. In OO, such changes are a regular matter and
called refactoring.
A collective work of type of cooperation assumes that all participants are used as is, with no possible
internal changes; the cooperation participants do not make the goals and objectives of cooperation
their own but contribute their regular capabilities into the results of the collective work. Therefore,
an expression “Application Collaboration” means that the application can be changed internally for
the sake of this type of collective work, which is the least desirable constraint. Moreover, if an
Application changes internally how would we know if it remains the same Application or another,
new one. In SO, cooperation is the most preferable pattern of a joint/collective work – services are
built to be used by consumers in many different combinations. I t would be inefficient if a service
needs to be changed for the sake of one collective work and for another one again.
3.2 Active Structure Concepts
ArchiMate’s Statement Comments … software components that can be part
of one or more applications… Also in
application architecture, the inter-
relationships of components are an
essential ingredient.
According to the ISO/IEC/IEEE 42010:2011, an application architecture should comprise of elements that are applications only, with their interrelationships and relationships to the environment. Components as parts of the applications are invisible at the level of the application architecture. Even if “ the inter-
relationships of components are an essential
ingredient” this may not be reflected in the application architecture but rather in the component architecture. When we talk about Application, we mean two appearances of it – logical and physical. If an Application is an implementation of a Service, the Application itself and all its internal Components may not cross the Service boundaries. If two Applications belong to two Services, they cannot share physical Components (across the service boundaries) but they may use a cloned Component. These clones can be logically considered as a the same Component but this is considered as a very bad practice in SO.
…the concept of application
collaboration here, defined as a collective
of application components which
perform application interactions.
An introduction of Application Component makes the entire Application Layer very ambiguous. It mixes constraints of Applications and Components and allows having alternative or inconsistent interpretations every time when this term appears.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
37
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Hereinafter, I will stick with a clear hierarchical model, in which an Application Component is a Component of Application, i.e. its internal element. As such, it can be deployed and re-deployed separately from other Components but only within boundaries of the Application. Also, a Component cannot substitute Application in any models. If a concept of Application collaboration is defined in the ArchiMate differently than in the rest of standards and English language, this makes the ArchiMate an isolated and, therefore, impractical instrument. See the definition and explanation of collaboration in the section 3.1. Even without considering the definition of collaboration to the letter, given statement is semantically inconsistent and ambiguous: in English, Application collaboration should mean a collaboration of Applications, i.e. activities between and within Applications. The Application Components are internal parts of the Applications and “a collective of
application components” is invisible at the Application layer. Moreover, a collective of Components cannot perform Application interactions – these are the Applications that perform the Application interactions.
… an application interface is the (logical)
channel through which the services of a
component can be accessed
While it is understandable what the authors had meant when wrote “services of a component”, it is inaccurate because the term “service” is already taken and, as I mentioned before, is an architectural abstract that is implemented by the Application, i.e. a Component may not have Services. Also, ArchiMate has not defined that an Application comprises Components only and does not have its own code. In this case, an Application Interface does not necessarily leads to the internal Component or even to its Interface.
… an application interface defines some
elementary behavioral characteristics: it
defines the set of operations and events
that are provided by the component, or
those that are required from the
environment.
An Application Interface relates to Application and only implicitly to its internals like components. An Interface has only that behaviour, which is needed to pass received and sent messages through. The “the set
of operations and events” defined in the Application Interface does not necessarily reflects any internal Application’s Component (while a Service Interface never reflects any internal Application).
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
38
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
The operations and events used in the Component level are not necessary visible through the Application’s Interfaces.
The application interface concept can be
used to model both application-to-
application interfaces, which offer
internal application services, and
application-to business interfaces (and/or
user interfaces), which offer external
application services.
While it is understandable what the authors had meant when wrote “internal application services”, it is inaccurate because the term “service” is already taken and, as I mentioned before, is an architectural abstract that is implemented by the Application, i.e. there are no such things as “internal application services”. An expression “application-to-application interfaces” is a tautology because two applications cannot interact in any other way than through their interfaces. If ArchiMate considers that Applications that belong to different Services can interact directly beneath the Services and their interfaces, this violates the major Principles of Service Orientation. Thus, the ArchiMate has to decide if it operates in Application / OO realm or in the Service realm.
3.3 Application Component
ArchiMate’s Statement Comments An application component is defined as a
modular, deployable, and replaceable part
of a software system that encapsulates its
behavior and data and exposes these
through a set of interfaces
This definition is confusing because 1) it is unclear whether the “software system …
encapsulates its [M.P. - Component’s] behavior and
data and exposes these through a set of interfaces” or this is about a Component “that encapsulates its
behavior and data and exposes these through a set of
interfaces” 2) a term “software system” is undefined and it is unclear how it relates to Application. As mentioned before, I consider a Component as a part of Application. From given definition, it is unclear if a Component can be deployed alone, without an Application. If so, this would violate the ArchiMate definition of Component given earlier in the ArchiMate 2.1 text. Why a component is re-defined here as a part of a system rather than a part of application or another component?
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
39
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
An application component is a self-
contained unit of functionality. As such, it
is independently deployable, re-usable,
and replaceable.
A fact of self-containing does not justify an independent deployment – they are different architectural concerns. As mentioned before, I consider a Component as a part of Application. That is, a component may be independently deployed only within the boundaries of its owner – the Application. This, however, does not preclude us from re-deploying, replacing and reuse Components within an Application independently from other Application’s Components.
Co-operating application components are
connected via application collaborations. This statement violates the model of layering – Cooperating Components may interconnect only within the Component’s form of a collective work. An Application Collaboration is a layer above Components.
An application component may be
assigned to one or more application
functions, business processes, or business
functions.
An assignment of a Component in this context is ambiguous – if a Component is assigned to more than one Application it is unclear if these Applications share the physical or logical Component-entity. An “application function” is (in English) a function of application but in the context of ArchiMate the term “function” is already taken and specially defined. I follow the hierarchical model where a function is realised by service, which, in turn, is implemented by Applications or Business Processes. Thus, a Component cannot be “assigned” to a Business Function or a Business Process. A Component may be used by Application to realise particular Application’s functionality.
An application component has one or
more application interfaces, which expose
its functionality. Application interfaces of
other application components may be
used by an application component.
An application component as a part of an application may not ‘have’ or own application interfaces because Applications and Component belong to different structural layers. Instead, Application Interfaces may be used to access the Application and, then, the Component interfaces inside the Application. Components may use their Component Interfaces to interact with each other inside the Application. An interaction between Components across Application boundaries is a common practice in programming but this couples the Applications and makes such Applications unsuitable for the use in different Services.
Example. …a financial application is This example is formally correct but semantically does
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
40
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
depicted as an application component
consisting of two subcomponents for
accounting and billing, each of which
offers an application service to the
environment.
not make sense. If an application – a Financial Application – has been defined already, there is no need to re-define it into a Component. If it is necessary that another Application would own this the Component “Financial Application” there is no need to define this Component as an Application. The dualism presented in the Example is ambiguous and confusing. Moreover, “subcomponents for accounting and billing, each of which offers an application service” is a programmatic slang; this is incorrect for architectural modelling. An Application or Component cannot offer a Service because the Service is implemented by the Applications, that comprise Components. The Service is at the higher level of abstraction. If a Component implicitly “implements” a function, i.e. it is a Service or a part of Service, the functionality implemented by the Component, should be offered via the Service interface(s). Two Service cannot physically share the same Application or Component because this creates ‘Service coupling by implementation’ which is prohibited in the Service-Oriented Environment. However, two or more Services may use the same logical Application or Component via cloning or physical duplication.
3.4 Application Collaboration
ArchiMate’s Statement Comments
An application collaboration specifies which components co-operate to perform some task.
It is necessary to note that cooperation is more restrictive type of collective/joint activities than collaboration. A cooperation uses participants as-is while a collaboration may require changes in the participant implementation. Thus, collaboration cannot be defined via more strict cooperation. No activities of Components may be visible at the higher layer of Applications.
An application collaboration typically models a logical or temporary collaboration of application components, and does not exist as a separate entity in the enterprise.
An Application Collaboration typically models a logical or temporary collaboration of Applications. Though Application Components may be changed for sake of Application Collaboration, the Components are invisible at the level of Application Collaboration.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
41
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
An Application Collaboration may be much more stable and long-living form than a cooperation and, because of that, may appear as “a separate entity in the enterprise” for certain time. This is because the Collaboration may result in the changes in the Applications, which require investments, and ignoring this fact is a misconception.
An application collaboration is a specialization of a component, and aggregates two or more (co-operating) application components
As mentioned before, no collaboration can be comprised cooperating elements. More accurately, the given statement might be articulated as “…or more (interacting) application…”
An application collaboration is an active structure element that may be assigned to one or more application interactions or business interactions, which model the associated behavior.
Actually, the relationship here is exactly reverse because “application interactions or business interactions” are the realisation of an Application or Business Collaboration. An Application Collaboration is the lowest level of joint/collective work of Applications.
… an application collaboration may be composed of application interfaces
This is an incorrect statement: Application Collaboration is a set of joint activities of applications following certain pre-defined logic. Application interfaces cannot compose a collaboration because they are inactive elements; it is an Application or a Service acts via the Interface. However, it is possible to specify which Application’s Interfaces are designated to particular collaboration. It is not recommended dedicating one interface to multiple collaborations. A need of different collaborations may be very specific and impact requirements to the Application’s Interfaces, which in the case of sharing, couple different application changes.
Example. In the model below, two
components collaborate in transaction
administration: an Accounting
component and a Billing component.
This collaboration performs the
application interaction Administrate
transactions.
A collaboration of two Components constitutes a Component Collaboration via Component Interactions. Applications reside in the higher level of abstraction. An Application Interaction should be defined between two Applications first and only then, indirectly, may be linked to the Component Collaboration.
3.5 Application Interface
ArchiMate’s Statement Comments
An application interface is defined as a This definition uses term “service” in ambiguous
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
42
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
point of access where an application service is made available to a user or another application component.
manner. Service is a higher abstract than Application; the latter just implements the Service’s functionality. While the intent of the authors of this statement is clear, it is unknown up-front if the Application can perform as a Service. The more accurate expression would be if the word “service” were replaced by the word “capability”.
An application interface specifies how the functionality of a component can be accessed by other components (provided interface), or which functionality the component requires from its environment (required interface).
An Application Interface is used in the interactions of Applications only, not their internal Component. Nonetheless, there is one known Application execution model, called “recursive”, that allows the Application to call itself via its interface, though it is rather an exception than a regular practice. An Application Interface does not necessary expose the functionality realised by the Application. In general, the Application Interface reflects the Application’s functionality only implicitly. Moreover, no Application Interface requests any Application’s functionality (that may be related to its internal Component) because an interface per se is inactive. If an input to the Application Interface realises a Command Pattern, the command/functionality is considered by the interface as a regular data value.
An application interface exposes an application service to the environment
This statement is either a fundamental mistake or articulated in the programmers slang that obfuscated the reality. No one interface can convert an Application into a Service (this is publicly defined and even standardised since 2006). An Application may implement a Service but everyone can. An Application Interface exposes only a capability of the Application to implement certain Service’s functionality.
In a sense, an application interface specifies a kind of contract that a component realizing this interface must fulfill.
It is an Application realises its interfaces while Components are invisible at the layer of Application. This statement addresses only a contract of programmatic connectivity while the Application may fulfil much more in accordance to the functionality it implements. Also, there may be many elements/artefacts of conditions under which the Application executes but they are invisible through such a contract.
An application interface may be part of an application component through
An Application Interface may be part of an Application only but the information moving through it may be
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
43
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
composition passed to the internal Components. An Application Interface is unaware if there is a Component composition exists in the Application.
An application interface can be
assigned to application services or
business services, which means that
the interface exposes these services to
the environment.
In service-oriented environment, comprised by Services that are implemented by Applications, it is the Services that have public interfaces. These Service interfaces can delegate information processing to the Application Interfaces. Service interfaces do not exist without Services. That is, an Application Interface can be assigned to Application and used by the Service or Business Service.
3.6 Behavioural Concepts
ArchiMate’s Statement Comments Also here, we make a distinction between
the external behavior of application
components in terms of application
services, and the internal behavior of
these components; i.e., application
functions that realize these services
When talking about a layered model, we should not forget about the surrounding context. Particularly, in the industry, we have a standardised definition of the service and should use it to avoid confusions and incompatibility. Thus, an external behaviour of an Application is not a Service (yet) because not every Application can be a Service. Also, in the service-oriented environment (if ArchiMate uses term Service), Service models the Function, not the other way around, and the Service is implemented by Applications. Inside an Application, there are Components that act/interact implementing elements of the Application’s functionality. It is a bad practice of using pre-defined terms in the different meaning in the text of the standard.
An application service is an externally
visible unit of functionality, provided by
one or more components, exposed through
well-defined interfaces, and meaningful to
the environment.
A expression of “application service” is a programmer’s slang because in layered model Service is the higher abstract than Application and can comprise several Applications at once. No internal Application’s Components may be exposed through the Application’s Interfaces. An environment is unaware and does not need to be aware of internal Application’s Components.
The service concept provides a way to
explicitly describe the functionality that
components share with each other and the
functionality that they make available to
the environment.
At the level Services, the Application’s Components are invisible. A description of Service, if properly articulated, does not refer to any Components that realise Service’s internal Applications.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
44
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Service implementation via Applications also does not address internal Application’s Components. Applications per se do not expose any functionality to the environment surrounding Services but can be known to other Applications within the Service’s boundaries.
The concept fits well within the current
developments in the area of web services In the theory of Service Orientation, a Service can have as many different interfaces as needed for its consumer base. Web Services is only one among many others. Thus, Web Services are well fit with the concept of Services, not the other way around.
The functionality that an interactive
computer program provides through a user
interface is also modeled using an
application service, exposed by an
application-to-business interface
representing the user interface.
In my opinion, this is inaccurate expression. First, an “application service” is an undefined term in ArchiMate. Thus, the statement is inconsistent. Also, an expression “application-to-business interface” has a negative connotation because it separates Applications from Business while Applications form a part of the Enterprise Business. Also, a user interface is not necessary intended or dedicated to the business users: an application configuration/tuning or security setting user interfaces are not for the business users.
Internal application services are
exposed through an application-to-
application interface.
This is an inaccurate use of the term Service – Services cannot be exposed via Application Interfaces but only via Service Interfaces. Nonetheless, this statement may have a much deeper meaning. Particularly
- ArchiMate recognises that Application can consists of interacting services
- This fits with the model of service-oriented enterprise where Services are used as for external as for internal consumers
An application function describes the
internal behavior of a component
needed to realize one or more
application services.
An application function is a function of application in English. Application implements Service that realises Function. An Application may have its own functionality – the things it does. Components are not visible at the Application level; Components constitute an internal structure of Applications. Some Components may have behaviour that contributes to the functionality of Application while others are only supportive and invisible in the application function. An “application service” is an undefined term in ArchiMate.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
45
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
An application as a physical instance cannot realise more than one service. To be used as an implementation of several services, the application (instance) must be duplicated to avoid service coupling by implementation. Alternatively, an application that needs to be shared has to be defined as an implementation of a new service engaged by those in need.
An application interaction is the
behavior of a collaboration of two or
more application components.
An Application Interaction is an interaction between Applications (in English). Such an interaction can take place without a collaboration of participating Applications. Also, Application’s Components are invisible in the Application Interactions.
An application interaction is external
behavior from the perspective of each
of the participating components
Components are invisible in the Application Interaction.
3.7 Application Function
ArchiMate’s Statement Comments An application function is defined as a
behavior element that groups automated
behavior that can be performed by an
application component.
Application implements Service, which realises Function. An Application may have its own functionality – the things it does. No justification is provided on why an Application’s functionality must be automated only; an Application that realises an interactive process may include human behaviour as well. This artificially narrows a notion of Application’s functionality (because components cannot perform human’s operations).
If this behavior is exposed externally,
this is done through one or more services. When an internal behaviour is exposed externally, this is a bad practice. Service Orientation prohibits such exposure because it couples external interaction with consumers with internal implementation of the service, which contradicts one of the Principles of Service Orientation.
An application function may realize one
or more application services. An “application service” is an undefined term in ArchiMate. This is an incorrect statement in the service-oriented environment. An Application’s functionality is a reflection of the Function provided by the Service. The same Function may be provided by more than one Service but these Services certainly do not share the Applications that implement them.
An application function may access data
objects. An “application service” is an undefined term in ArchiMate.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
46
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
This is an incorrect statement. A functionality of an Application cannot access anything, it is an abstraction. Only application itself can access data objects via its components.
The name of an application function
should preferably be a verb ending with
“-ing”; e.g., “accounting”
In English, a verb ending with “-ing” is known as gerund, i.e. a verb-derived noun.
Example. These application functions
realize the application services that
are made available to the users of the
application.
An “application service” is an undefined term in ArchiMate. This is an incorrect statement in the service-oriented environment. An Application’s functionality is a reflection of the Function provided by the Service. The diagram, shown in this Example is impossible in the service-oriented environment because three Services share the same Application or Component. According to DOSOM (Domain Service-Oriented Modelling) [11], the design of a Service implementation starts with defining the Service’s boundaries, and no implementation Applications may cross these boundaries in any way other than through the public interfaces of the Service.
3.8 Application Interaction
ArchiMate’s Statement Comments An application interaction is defined as a
behavior element that describes the
behavior of an application
collaboration.
For an interaction between Applications no Application Collaboration or even Cooperation is needed. An Application Collaboration cannot be used to define an Application interaction unless ArchiMate wants to omit the dominant majority of interaction types. The preconditions of the Service implementing Application interaction are defined in the OASIS SOA RAF specification (2012). There is no such thing as behavior of Collaboration because Collaborations do not behave. It is a participant of Collaboration behaves according to the logic of collaboration. An interaction between one Application and others in the Collaboration is only a sub-element of the collaboration logic.
… the collective behavior that is
performed by the components that The Components are not participants of the
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
47
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
participate in an application collaboration Collaboration of Application because Components are invisible at the Application level.
This may, for example, include the
communication pattern between these
components.
In the Application Collaboration, communications take place between Applications, not between their Components.
An application interaction can also specify
the externally visible behavior needed to
realize an application service.
This is an inaccurate use of the term Service. Applications can interact with no Services involved. If an Application is a part of the Service implementation, this Application may interact with other Applications within this implementation only, and not with Applications, implementing other Services. In the service-oriented environment, there are no horizontal interaction layers outside of the Service boundaries. An interaction is an act of action of one entity to another and another entity to the one. There is no other behaviour than interaction in the interaction.
The details of the interaction between the
application components involved in an
application interaction can be expressed
during the detailed application design…
The Components are not participants of the Application interaction because Components are invisible at the Application level.
An application collaboration may be
assigned to an application interaction
An Application Collaboration may comprise collective interactions of several Applications performed in accordance to the Collaboration logic. That is an Application Collaboration is a sort of container for related Application interactions. Thus, the given statement should be reversed: an interaction between Applications may be a part/assigned to the Collaboration of Applications.
An application interaction may realize
an application service.
This is an inaccurate use of the term Service. An interaction per se cannot realise a Service but may be a part of Service realisation together with the applications and the logic of interactions. Service realisation is a realisation of a Function; an exchange of actions between Applications cannot be a Function. An “application service” is an undefined term in ArchiMate.
Application services and infrastructure
services may be used by an
application interaction.
This statement should be reversed: Service is a higher abstraction than Applications – it is Service uses Applications, not the other way around. An Application interaction is one of several elements
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
48
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
of Service execution. Thus, Service may use Application interaction, not the other way around. An “application service” is an undefined term in ArchiMate.
An application interaction may access
data objects
Application interaction consists of exchange of messages between the Application’s interfaces. A Data Object may be used as a message load but interaction (a dual action) cannot access anything, it does not make sense in English. IMO, an attempt to make an interaction a “first class citizen” is mistaken because it is not self-sufficient and always depends on participants and the logic they apply.
Example. … an Accounting
component and a Billing component of
a financial system co-operate to
compose an administrate transactions
interaction. This is modeled as an
application interaction assigned to
the collaboration between the two
components.
If an Accounting component and a Billing component of a financial system co-operate to compose an administrate transactions interaction, they have to have a direct relationship, otherwise they do not interact. Therefore, we have either incorrect example diagram or this diagram has to be described in plain English like “a collaboration Transaction Administration includes such participants as Accounting component and Billing component that have to interact in the collaboration using Administrative transaction”. Moreover, in this example an interaction is assigned to the Collaboration, exactly as I commented above and in contradiction to the previous ArchiMate statement.
3.9 Application Service
ArchiMate’s Statement Comments An application service is defined as a
service that exposes automated behavior On several occasions in this paper I said that “Application Service” is not defined. It is because this term is defined via term “service”, which is undefined in ArchiMate (this is a serious discrepancy for a standard). It is unclear that a verb “exposed” means. Is it an influence of the service on the environment? Is it a reaction of the service to the influence from the environment? Term “service” is fundamental and ArchiMate as a The Open Group ‘s standard must use the definition of
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
49
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Service specified in the OASIS SOA RAF according to existing agreement between these Standards Bodies. Given use of term “service” is incompliant to the OASIS SOA RAF.
An application service exposes the
functionality of components to their
environment.
An “application service” is an undefined term in ArchiMate. The environment of Components is the Application. If assume that we talk about the Application’s functionality, the functionality of its Components is indistinctive at the Application level.
This functionality is accessed through one
or more application interfaces. Application’s functionality “is accessed through one or
more application interfaces”. An application service is realized by one
or more application functions that are
performed by the component.
An “application service” is an undefined term in ArchiMate.
An application service should be
meaningful from the point of view of the
environment; it should provide a unit of
functionality that is, in itself, useful to its
users.
An “application service” is an undefined term in ArchiMate. It is the Service should be meaningful from the point of view of the environment; it is the Service should provide a unit of functionality that is, in itself, useful to the Service’s users. Applications realising Services are invisible at the service level.
…if this [M.P. - service] environment
includes business processes,
application services should have
business relevance.
In an enterprise with a service-oriented environment, all service must have “business relevance” regardless business processes; otherwise, irrelevant services should be eliminated. In service-oriented environment, everything is a Service, i.e. an environment cannot include business processes (every business process is a service to its consumers [12]). A Service implementation may be a business process, which constitutes the environment to the to the implementing Applications.
A purpose may be associated with an
application service.
An “application service” is an undefined term in ArchiMate. It is unclear whether a “purpose” is a term/element of ArchiMate. A Service or an Application without a purpose is meaningless, IMO, and should not exist in the first place.
An application service may be used
by business processes, business
An “application service” is an undefined term in ArchiMate.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
50
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
functions, business interactions, or
application functions
Business Function does not “use” Service, it is realised by the Service(s). Business interaction is a form of behavior; it itself cannot “use” anything. A functionality of an application is derived from the Function of Service, i.e. it is the Service can use the functionality realized by the Application, not the other way around.
An application interface may be
assigned to an application service.
An “application service” is an undefined term in ArchiMate. A Service exposes its interfaces; they are not assigned to it because do not exist without it. An Application Interface can be assigned to an Application.
An application service may access
data objects
An “application service” is an undefined term in ArchiMate. A Business Service usually accesses Data Service that may access a Data Object. An Application may accesses a Data Object.
The name of an application service
should preferably be a verb ending
with “-ing”
In English, a verb ending with “-ing” is known as gerund, i.e. a verb-derived noun.
Example. …a Transaction processing
(application-to-application) service is
realized by the Accounting
application function, and is accessible
by other components through a
Transaction processing application
programming interface (API). This
service is used by the Billing
application function performed by the
Billing component.
The overall Example diagram is inconsistent. A Service cannot be realized by Function because it is the Service that realises the Function. The Applications implement the Service. Thus, “a
Transaction processing (application-to-application)
service is realized by the Accounting application”. The Accounting Application may be accessible via its API to the other Applications of the same Transaction Processing Service. Interactions between Applications across Service boundaries couple independent Services and, in the service-oriented environment, is a bad practice. A Service can be accesses through the service interface only. The Service’s interface may engage the API to delegate the invocation of the applications that implement the service. A Service cannot be used by a Function because it is an abstraction. That is, in the Example, the Billing Service may use/engage a Transaction Processing Service via its Service’s interfaces. The fact that the Transaction Processing Service delegates the engagement to its
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
51
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
internal “Transaction processing application” using its API is invisible at the level of Services.
3.10 Passive Structure Concepts Service
ArchiMate’s Statement Comments A data object can be seen as a
representation of a business object, as a
counterpart of the representation concept
in the business layer. The ArchiMate
language does not define a specific layer
for information; however, concepts such
as business objects and data objects are
used to represent the information
entities and also the logical data
components that realize the business
objects.
In the business layer, business object is ““informational” or “conceptual” elements in which the
business thinks about a domain.” Though such definition is vague (who knows what and how an abstract business thinks about domain, and how this tacit knowledge can be transferred to anybody else?) , I can assume that ““informational” elements” comprises data with business meaning. If the meaning in the Application Layer for data object is different from its counterpart in the business layer, a mapping between layers is due. If the meaning is absent, no data object makes sense. It is unclear to me how it is possible talking about Business Architecture in ArchiMate that “does not
define a specific layer for information”. If “business
objects” and “data objects” separately “represent the
information entities and also the logical data
components”, which one of these objects represent what aspects of the information entities (the term is undefined in ArchiMate)? If the objects represent the same, what is the reason having both of them, which makes the entity ambiguous?
3.11 Data Object
ArchiMate’s Statement Comments An application function operates on a
data object. Function and functionality is an abstraction; it cannot operate by itself. It is the Application operates on Data Objects via its Application’s Components.
It should be a self-contained piece of
information with a clear meaning to the
business, not just to the application level.
It is not clear what means to be a self-contained for a Data Object, especially if it is presented in language separately from informational Business Object. Data is data; meta-data describes data, but it is unclear in ArchiMate if the meta-data is a mandatory part of the Data Object. A data without meta-data have no meaning to the business. Each business actor can interpret pure data in any desirable way. The practice shows that even meta-data may be interpreted by different business
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
52
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
actors differently, i.e. models created with such language may be misinterpreted by the model consumers. ArchiMate does not provide a cross-level mechanism that can deliver “a clear meaning to the business, not
just to the application level”. A data object can be accessed by an
application function, application
interaction, or application service.
Function or functionality is abstract; it does not act and cannot access anything. An implementation of Function via Service in the form of Application can access Data Object. It is should be done via Application’s Components that are invisible at the level of Applications. Application interaction does not have operational behavioural of its own and cannot access anything. Service does not access Data Objects but, instead, engages special Data Services that access or be realised by Data Objects.
Example. …two application functions co-
operate via an application service, in
which a data object holding Transaction
data is exchanged.
An “application service” is an undefined term in ArchiMate. Application functionality is abstraction that cannot act or cooperate on its own. Applications are invisible at the Service layer. Services, implementing the Functions, can cooperate and exchange Data Objects holding Transaction data.
3.12 Summary of Application Layer Concepts
An Application Layer is addressed in modelling for more years than the Business Layer and is
expected to be more consistent and structured. Unfortunately, ArchiMate representation of this
layer is weak: no structural relationships for the structure elements are defined, which leads to very
confusing reversed relationships defined. I have an overall impression that the representation and
description of elements in the Application Layer was viewed bottom-up, based on practice and
jargon of programmers/developers, which resulted in several erroneous statements from the
architecture perspective. Also, several ambiguous statements were immediately overwritten by the
following statements when viewed top-down (suddenly).
The major problem in the representation of this layer I see in ignoring the Business Context and
inclusion of Services without considering Service’s specific modelling and designing rules and
constraints. In the Service or service-oriented world, Applications can act only inside the Service
boundaries and cannot cross these boundaries in their interactions. The same relates to the
Components of Applications and Application boundaries.
It would be nice if ArchiMate promoted an idea that Applications are parts of the Business and have
to “live” driven by the business rules and constraints.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
53
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
4. Cross-Layer Dependencies
4.1 Business- Application Alignment
ArchiMate’s Statement Comments
There are three main types of
relationships between these layers:
1. Used by relationships,
between application service
and the different types of
business behavior elements,
and between application
interface and business role.
2. A realization relationship
from a data object to a
business object, to indicate
that the data object is a
digital representation of the
corresponding business
object. 3. Assignment relationships,
between application
component and business
process, function, or
interaction, and between
application interface and
business service, to indicate
that, for example, business
processes or business
services are completely
automated.
An “application service” is an undefined term in ArchiMate. Types of “business behavior elements” are undefined in ArchiMate. In environment of Services, there are no relationships between Application interfaces and Business Roles because Application interfaces are invisible to the Business Roles; they can relate to the Business Service interfaces only. If “the data object is a digital representation of the
corresponding business object” then we have meta-data separated from data (meta-data is not necessary digital form of information), which leads the entire language to an extremely high risk of discrepancies between corresponding objects, separate life-cycle of these objects and error-prone modelling. It is unclear why “A realization relationship from a data
object to a business object” in the “relationships
between the business layer, the application layer,
and…” is specified while a realization relationships between Service and Application, and between Application and Component are not. In practice, business process or Business Service are usually manual, with or without elements of automation. When a business process becomes “completely automated” it ceases existence and shifts from the realm of business processes into realm of automated procedures. For a regular Business Process, which usually is not “completely automated”, an association with business processes and implementing Applications is a Best Practice of modelling Business Services – it means that the they are within the Service’s boundaries.
A Review of Business Layer & Application Layer in the ArchiMate® 2.1 Specification
Business & Technology Consulting
54
Copyright ©2014 Clingstone Ltd. Prepared by: Dr Michael Poulin
Clingstone partners Limited
Clingstone Partners Limited
Clingstone Partners Limited
Clingstone Partners Limited
Clingstone Partners Limited
Clingstone Partners Limited
Recommended