A Review of Business & Application Layers of the …€™t-we-use...ArchiMate is terrific and...

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



2


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



3


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

http://pubs.opengroup.org/architecture/archimate2-doc/toc.html

http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra.html

http://www.mpoulin.com/architects-know-what-manager-dont/

http://www.mpoulin.com/ladder-to-soe/

http://www.ebizq.net/blogs/service_oriented/2012/06/knight_rules_of_ownership_in_service-oriented_ecosystem.php

http://www.ebizq.net/blogs/service_oriented/2012/06/knight_rules_of_ownership_in_service-oriented_ecosystem.php

http://www.merriam-webster.com/dictionary/interaction

http://en.wikipedia.org/wiki/Interaction



4


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



5


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.



6


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.



7




8


Figure 1. Business Layer Metamodel Diagram with Comments



9


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.



10


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.



11


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


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



12


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



13


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



14


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.



15


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.



16


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



17


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



18


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



19


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



20


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



21


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



22


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.



23


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.



24


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.



25


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



26


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



27


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


… 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



28


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



29


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



30


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



31


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



32


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



33


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



34


“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.



35


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



36


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.



37


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).



38


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


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?



39


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



40


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


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.



41


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


An application interface is defined as a This definition uses term “service” in ambiguous



42


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



43


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.



44


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


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.



45


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.



46


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



47


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



48


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



49


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.



50


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



51


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



52


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.



53


4. Cross-Layer Dependencies

4.1 Business- Application Alignment


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.



54


Clingstone partners Limited

Clingstone Partners Limited





A Review of Business & Application Layers of the …€™t-we-use...ArchiMate is terrific and...

Documents

Transcript of A Review of Business & Application Layers of the …€™t-we-use...ArchiMate is terrific and...