Aerospace Logistics Architecture Program

Master’s thesis report: Aerospace Logistics architecture program Calvin Lee
Aerospace Logistics
architecture program
Action research at Air France Cargo - KLM Cargo
Project: Master’s Thesis Project for MSc Information Architecture

Student name: Calvin Lee
Student number: 1047590
Version: 1.1 18-10-2006, Delft
1
This page is left blank intentionally.
2
Abstract
Aerospace Logistics (AL) is a company part of Air France Cargo – KLM Cargo (AF-KL Cargo)
that handles the logistic activities for cargo in the aerospace segment. These are for example
aircraft engines and other aircraft parts. For the last couple of years AL’s repositioning
strategy in the market and in the AF-KL Cargo organization has been a hot issue. Next to this
the discussion about which direction AL should be going has been bothering the AL
management for some time as well. Because of these issues the question of how Enterprise
Architecture could play a role in this arose. The architectural way of thinking isn’t something
new to most of the people at KLM Cargo. In the technical domain an Enterprise Wide
Technical Architecture has already been devised and used in the design of technical systems.
The main question here, and at the same time the problem thesis for this project, can thus be
summarized as follows:
How can the Aerospace Logistics strategy and best practices be captured correctly in an
Enterprise Architecture?
A method to execute an architecture program forms the answer to this question. However, the
process of devising an EA purely based on principles has never been done before. Therefore
the applied method in this project will be given as the answer with the consideration that a
learn by doing approach was adopted in its execution.
The method starts with raising the EA awareness at AL to a level where the AL management
is willing to participate in the development of the EA. The actual devising of the architecture is
a group effort because the main concern is to come to a common understanding on the
strategy amongst the decision makers. This process of devising the architecture was done in
a brainstorm workshop to generate the principles after which the group discusses the devised
principles. The process was supported by a Group Decision Tool which contributed heavily in
the success of the workshop rendering the whole process to go almost automatically. The
result of the workshop is a first version of a complete AL business architecture.
3
Preface
First of all I would like to thank my supervisors, both at AF-KL Cargo and DUT, Prof. Jan
Dietz, Hans Zwitzer and Marco Koole for giving me the opportunity to do my internship at AF-
KL Cargo. Their guidance throughout my project made it possible to come to the results
presented in this report.
I also wish to thank all the people at AF-KL Cargo and especially at Aerospace Logistics who
helped me in the fulfilment of my project. Their spent time and effort in the project are very
much appreciated.
My special thanks goes to Andrew Go, a fellow student who also did his master’s thesis
project at AF-KL Cargo, for the marvellous collaboration in the process of executing our
projects.
4
Table of contents
1. Introduction .............................................................................................................................6
1.1. Project definition ..............................................................................................................6
1.2. Project approach ..............................................................................................................7
2. Analysis ..................................................................................................................................8
3. Development...........................................................................................................................9
3.1. Principle definition............................................................................................................9
3.1.1. Elements of a principle ............................................................................................10
3.1.2. Principle formulation................................................................................................11
3.2. Principle organization.....................................................................................................13
3.2.1. Enterprise architecture perspectives.......................................................................14
3.2.2. The Business Architecture Framework ...................................................................14
3.2.3. Domain Definitions ..................................................................................................18
3.2.4. Principles in the EWTA............................................................................................19
3.2. Aerospace Logistics EA awareness ..............................................................................20
3.3. Aerospace business architecture...................................................................................21
3.3.1. Pre-study .................................................................................................................21
3.3.2. Devising the AL business architecture ....................................................................23
3.3.3. EA development evaluation ....................................................................................33
3.4. Aerospace Logistics process modelling.........................................................................34
3.4.1. Pre-study .................................................................................................................34
3.4.2. Devising the AL process model...............................................................................35
3.4.3. Process modelling evaluation .................................................................................37
4. Discussion and recommendations........................................................................................39

4.1. Remarks.........................................................................................................................39
4.2. Experiences and learning points....................................................................................41
4.3. Recommendations .........................................................................................................43
5. Conclusion ............................................................................................................................44
Appendix A: Aerospace Logistics business architecture..........................................................46
Appendix B: Aerospace Logistics DEMO models ....................................................................47
Appendix C: EA awareness presentation.................................................................................48
Appendix D: Workshop preparation material............................................................................54
Appendix E: Enterprise engineering (overview) .......................................................................57
Appendix F: Project proposal ...................................................................................................62
Appendix G: Group Decision Tool manual ...............................................................................64
Appendix H: Aerospace Logistics Protos models.....................................................................65
Appendix I: List of abbreviations...............................................................................................66
References ...............................................................................................................................67
5
1. Introduction
The report that lies in front of you is the result of my internship at Air France Cargo – KLM
Cargo (AF-KL Cargo) carried out as my master’s thesis project in the Information Architecture
program at Delft University of Technology. The project is centred on the prescriptive notion of
Enterprise Architecture (EA). This notion defines EA as the normative restriction of design
freedom [1]. In practice, an EA consists of a coherent and consistent set of principles, as
appose to global models and/or blueprint in the descriptive notion that reveal how things are
[2].
1.1. Project definition

The concept of Enterprise Architecture isn’t new for the people working at AF-KL Cargo. In
fact, an Enterprise Wide Technical Architecture [3] (EWTA) is already in place and being used
to aid designers in developing technical systems. However, the Enterprise Business
Architecture, Enterprise Organization Architecture and Enterprise Information Architecture
have yet to be made and the need for an Enterprise Architecture that is complete has been
growing in the last few years. Therefore, the process of designing these architectures is in the
scope of a parallel master’s thesis project carried out by a fellow student, Andrew Go [4].
1
Regarding the history and the role of the Product Market Group (PMG) Aerospace Logistics
(AL), it can be considered to have a “special” position within AF-KL Cargo. There are some
AL business processes that are compulsory to the General Cargo2 (GC) business processes.
The way of working and the (information) systems at AL also differ from how it is organised at
GC. Consequently, AL should/could have its “own” EA (AL EA). Most likely this AL EA would
then be an extension of the GC EA where specific and specialized principles for and towards
AL can be found. The process of designing this AL EA is in the scope of my master’s thesis
project.
Formally the problem thesis for the project is formulated as follows:
The above thesis question can be further subdivided in the following sub problems:
1. How can the enterprise objectives be retrieved?

2. How can the best practices of the enterprise be retrieved?
3. How should principles be formulated such that they are applicable for designers?
4. How should principles be organized?
Thus the focus of the project is not only on the principles in the EA, but also the process of
devising these principles is of importance.
Another important thing to mention is that in this project raising the EA awareness of the
people at AL is one of the primary focuses. Because without the needed support working
under architecture will not have a chance to succeed, especially considering the fact that it is
a complete different way of working that AL is used to .
1
A specialized unit within AF-KL Cargo that provides dedication to certain kinds of products, in our case Aerospace
Logistics is dedicated to aircraft parts (e.g. engines).
2
The term General Cargo is used to separate the main Cargo division (GC) with the subdivisions for special cargos
like aircraft engines (AL) and mail (Mail).
6
Emphasis is also put on the business processes at AL. Modelling the as-is processes will not
only help me understand what is going on at AL, it will also identify which processes are
compulsory for AL and which processes are similar to the processes at GC. Furthermore, the
as-is process model provides a good starting point for enterprise redesign and change. This
result has value for AF-KL Cargo regarding cost-savings and organizational changes.
1.2. Project approach

My research starts with a detailed analysis of the current situation at AF-KL Cargo and
especially at AL to obtain the necessary context and background information for the project.
Studying the available AF-KL organization documents and interviewing key persons will form
the basic method of approach here. The analysis will thus be the first topic in this report.
By means of this knowledge a plan for answering the research questions must then be drawn.
This practically means figuring out what the best way is to devise the AL EA. With no
literature on how to do this, the development phase is something we can consider to be
3
learning by doing or an action research . Next to the development of the EA, the development
of the AL process model will be discussed in this section of the report.
With the development behind us we can then reflect on this whole process and at the same
time I will provide my recommendation on the follow-up steps.
Finally the report will be concluded and answers to the problem thesis and its sub problems
will be presented.
3
Action research is a disciplined method for intentional learning from experience, definition from wikipedia.org.
7
2. Analysis
Included along with this master’s thesis report is the analysis report [5]. In this analysis report
I have documented what I have learned in the first month of my internship at AF-KL Cargo.
The topics include: the project environment, the EA awareness, the AF-KL Cargo strategy,
the AF-KL Cargo process model, the AL strategy, the AL process model and the Information
Services’4 (IS) way of working in relation with EA. The reader is invited to go through the
analysis report first in order to obtain the necessary context and background information on
my project.
Below a quick recap of the conclusions resulting from the analysis is presented.
1. For the BDO to fulfil its role as a business solution facilitator and not only an IT
solution facilitator, it has to prove itself to both the business and the IS people of its
capabilities.
2. BDO’s perception that the Stemband5 is ineffective and inefficient due to the delaying
nature of permits is incorrect. If the designs are all made according to the standards
and guidelines, permits will be granted quickly. If not, it is only logical that the permit
requests are denied.
3. Attention towards processes can be noticed at both AF-KL Cargo and AL. Both
parties realize the necessity to start from processes in enterprise redesign initiatives.
However, deduced from the current shape of both the CPM6 and the ATI-PM7
(incomplete, inconsistent, not up-to-date, rarely used and not easy to understand) it is
reasonable to conclude that this necessity doesn’t reflect itself in practice.
4. Most of the written information (e.g. strategy, business plan, budget, etc.) are on
presentation slides without further elaboration or comments. It is therefore very hard
to extract the correct information from these resources without risking
misinterpretation. Interviews with the key persons about the slides prove to be the
best solution in this matter.
5. The current situation at AL has a lot to do with its history. Originating from the KLM
E&M division, through being its own BU and finally ending up as a PMG at AF-KL
Cargo, a lot of the employees at AL tend to take on the victim role.
6. As an integral part of the AF-KL Cargo division, AL must organize itself as such.
Synergies/standardizations with AF-KL Cargo are to be implemented in order to have
a better alignment between the two parties. This will result in higher flexibility and cost
reduction.
7. Working under architecture must not be forced into an organization nor must it be
seen as the ultimate solution. An EA awareness program has to be devised in order
to create a safe “breeding ground” for it to be accepted and used [6]. This is the first
and most important step in the architecturing process.
8. Unlike the situation at the BDO, the EA awareness at Aerospace is close to zero.
4
The main IT supplier for KLM.
5
The process that guides the development of an information system at KLM.
6
Process model of the KLM Cargo organization.
7
Process model of the Aerospace Logistics organization.
8
3. Development
In this chapter attention is drawn on the process of developing an Enterprise Architecture for
Aerospace Logistics. Two architectural processes can be identified here [7]: 1. devising the
architecture, which will be referred to as architecturing and 2. the transformation to come to
artefacts that comply with the devised architecture, which is often referred to as working
under architecture. Considering the time period the second process is not included as a result
8
in my project , therefore only recommendations and remarks on the second process will be
given in this report.
Devising architecture practically means devising principles [2]. Thus the first topic in this
chapter will be about the characteristics of architectural principles. This includes the definition
of principle, the elements of a principle, principle formulation and principle organization.
After the discussion on principles, the EA awareness at AL will be the point of attention.
Because apart from the two herefore mentioned architectural processes, the process of
raising the awareness and sense of urgency on EA must be considered the mandatory first
step in the architecturing process.
Next the methods used in the whole architecturing process and its results will be discussed. A
remark must be made that the methods chosen here have not been evaluated in a scientific
way but more chosen instinctively, by quick reasoning, by advice from our supervisors and as
a result of restricted materials/resources we had available. Thus one could argue if the
chosen way is indeed the best method. However, one could also argue that because the
project can be considered a novelty and not really done before, or at least not documented in
literature before, it required a “trial and error” approach.
The last topic in this chapter is about process modelling. From the introduction of this report
we could already notice that modelling the processes at AL is a part of my project. For that
reason the development of the AL process models will be treated in this chapter as well.
DEMO9 [8] will play an important role in this discussion.
3.1. Principle definition

An EA purely based on principles is something that hasn’t been developed before [9]. There
are, however, a number of examples of principle-based IT Architectures, including the
Enterprise Wide Technical Architecture adopted by Air France - KLM. Unfortunately, there is
no set of guidelines that can be found in literature and used to develop principles for the other
domains (business, organization and information). In order to develop principles of a similar
level of quality for the other domains, these guidelines would have been very useful.
The guidelines regarding the development of principles presented in this thesis are based on
the experiences of developing principles during the project and best practices from Enterprise
Architects at the Information Services division of Air France - KLM.
This part of the development phase of the project focuses on creating a starting point from
which an EA can be developed. First a clear understanding should be made of what a
principle is and what it consists of. Next, a number of suggestions on how to formulate
principles are provided. Finally the organization of principles is tackled to examine how the
principles should be managed.
8
See the Result entry in the Project Proposal document included in appendix F.
9
Design and Engineering Methodology for Organizations.
9
3.1.1 Elements of a principle
Before developing principles for the enterprise, it is imperative to clarify what a principle is. In
order to determine this, a definition of the term principle is presented below:
“A belief that is accepted as a reason for action or thinking in a particular way” [10]
Because of the possible misconception that the term refers to moral values, additional terms
such as rules and guidelines are used to explain how these principles should be used [11].
However, these terms can’t be interchanged. The definition shows that principles are more
than rules and guidelines. They represent a shared understanding on what needs to happen if
an enterprise wants to execute its strategy successfully [12].
There are issues that have to be kept in mind when dealing with principles. First of all,
principles are developed to be applied for a long period of time. Therefore principles should
address a class of systems, for example cars in Europe, in stead of a specific system, for
example the Toyota in the garage [1].
Also the difference between a principle and a requirement has to be made clear [1]. This can
be done by considering principles as general requirements, because they concern a class of
systems. Requirements are devised for a specific system and can be regarded as special
requirements. This distinction is necessary to avoid requirements from finding their way into
the architecture.
In order to define a principle clearly, each principle must consist of the following elements
[13]:
• A principle statement,
• The rationale for the principle,
• The implications of the principle and
• The key actions for enabling the principle.
The definition of these elements used by KLM Cargo is presented below [14]. Based on this,
definitions of these elements have been established that are used to develop principles during
the project, which will be discussed further in the report.
Principle statement
The principle statement ensures that the principle is recognizable. Because a principle
consists of more than just the statement, it is difficult for a principle statement to represent the
entire principle. Nevertheless, an important aspect of a principle statement is that it captures
and is able to communicate the intentions of the principle.
Rationale
Principles represent decisions that have been made on which designers can base their
decisions. All decisions should reflect the enterprise strategy or best practices, which means
that it should be possible to trace a principle back to them. The rationale provides this
traceability and explains why applying this principle contributes to realizing enterprise
objectives.
Implications
Principles represent a further elaboration of the enterprise strategy and therefore reflect
decisions made by (senior) management. The principle statement alone isn’t sufficient to
apply the principle, because it is usually a generic statement that has to be applicable
enterprise-wide. Implications specify how this design principle will impact the business and IT
Community. Next to the rationale, the implications also provide a good way to help designers
understand the principle.
10
Key Actions
The key actions specify what actions need to be taken to ensure that the design principle is
followed. After an architecture domain is introduced and “stable”, the key actions can be
removed from the document.
3.1.2. Principle formulation
As mentioned earlier, principles should represent a shared understanding on how the

enterprise should develop itself. Formulating these principles to represent this shared
understanding is difficult because these principles reflect many people’s minds and every
person uses different words to express their mind.
Nevertheless, there are many issues regarding syntax and semantics that have to be taken
into consideration when it comes to formulating principles [12]. During the project, two main
issues are examined:
• The acceptance of principles and

• The correctness of principles.
Acceptance of principles
In order to have people working with principles, the principles have to be accepted [15]. There
are a number of factors that can be used to influence the level of acceptance. Below, the
factors are described and also what role the architect has in influencing these factors:
• Involvement of users,
• Relevance of principles,
• Applicability of principles and
• Compliance with principles.
First of all, forcing people to work with principles while they don’t support them isn’t the right
strategy to implement the principles. Support for principles is best gained if the users of the
principles are actually involved during the development. It is the architect’s task to stimulate
these persons to become involved by explaining the value of principles.
Another factor that has to be taken into consideration is the relevance of the principles. The
principles have to regard topics that are relevant during the design process. By involving
users of the principles in deciding what topics the principles should cover, the principles
become more relevant to them. An architect should provide suggestions and examples which
assist the users in determining the topics.
Applicability also plays a role in the acceptance of principles. By definition, the architecture to
which the principles belong should be developed such that it limits the design freedom and in
doing so, guides the design process. This has to be taken into account when formulating the
principles. The architect’s role here is to ensure that the principle is formulated such that its
meaning is unambiguous to the users.
The strictness in compliance to the principles is also a factor that can influence the
acceptance of the principles. In order to effectively limit the design freedom of designers, the
compliance to principles has to be guarded strictly. Principles are the starting point from which
other decisions are made. Not complying with them is the very reason why most strategy
implementations fail [13]. However, managing this compliance too strictly might have an
adverse effect on the acceptance of principles and in some situations, e.g. reacting on a
business opportunity, it might be grounded to deviate from the principles. To enable non-
compliance in these situations, a process to allow exceptions should be introduced.
Exceptions must be approved and managed by the architect. To approve an exception, the
non-compliance has to be justified and made explicit.
11
Correctness of principles
During the project, the following tasks have to be carried out to safeguard the correctness of
the principles:
• Verification of the principles,

• Unambiguous interpretation of the principles and
• Ensuring the consistency between principles.
To check whether or not the principles are true, they have to be verified. Verification is done
by those who are part of the enterprise and experts in their domain. For example, when
verifying a principle regarding the relationship with a customer, an employee who is
responsible for the customer relationship has to be consulted. The architect is responsible for
facilitating the verification process by presenting the principles to these domain-experts and
pointing out suggestions for improvements. The architect should prepare in advance by
gathering information regarding the strategy of the enterprise and check whether or not the
principles are consistent with what has been found concerning the strategy.
An architect should also ensure that the principles are interpreted correctly. Asking various
persons to explain a principle might reveal the many different interpretations of a principle.
This gives the architect an impression of how well a principle is formulated and enables the
architect and those involved in the development of the principle to improve the principle.
In order to develop an enterprise within which everything is consistent with one another, the
principles themselves have to be consistent with each other as well. Considering the number
of principles in an EA and the fact that a principle represents something that isn’t easy to
grasp using words, checking an EA on consistency is an enormous challenge. Nevertheless it
is important considering the fact that inconsistency within an enterprise is the cause of many
strategic and operational problems [13]. Architects are responsible for architecture
governance, which means that they are responsible for checking the consistency among
principles.
Guidelines for principle formulation
The project allowed me to gain hands-on experience in developing principles. No strict rules
have been found during the project that could have made formulating principles easier.
Nevertheless a number of best practices have been discovered, which are described below.
The principle statement is the element that stands out from the other parts of the principle.
Bear in mind that most people will probably only read the statement to understand the
principle. Therefore in the principle statement the focus of the principle should be clear to
everyone. It is also important that the formulation of the principle statement is recognizable
and easy to remember. Analogies with scientific laws can be made here. Often laws are
stated in a shorthand manner [16]. For example, the First Law of Thermodynamics: Total
energy in a system is constant. Surely one must understand that this statement has some
conditions attached to it in order for it to be true. One such condition is for example that the
energy in the concerned system is neither brought nor taken away. However, if we were to
elaborate the statement with all the conditions incorporated, it will be harder to remember and
certainly harder to recognize. The same things can be said about the principle statements.
Instead of making the statements more precise by including all the qualifying conditions, they
should be made more memorable by clever and catchy phrasing. The principle elements
rationale and implications can then be used to put all the conditions in. This way the principle
will be easier recognized and remembered which ultimately will contribute to the acceptance
and the use of the principle. This is reflected back in the EWTA. The most well-known
technical architecture principle is: Reuse before Buy before Build. One cannot find a catchier
principle than this one in the EWTA.
A principle represents a decision that has been taken regarding a non-trivial choice. This is
how design freedom is limited in practice. This is a key issue to keep in mind when
12
formulating the statement; a principle must represent a choice made in advance. An example
of a trivial choice is: “We must work efficiently.”
The principles that are developed should be considered as the starting point from which the
enterprise should be operated and developed. Therefore, these principles should not be taken
lightly and considered to be best practices. Such a high priority must also be reflected in the
statement. In stead of using terms like “have to” or “should”, the term “must” is better suited to
convey the right message.
The rationale of a principle consists of a set of statements reflecting the issues for which this
principle provides an answer. Similar to the statement, it should also be as clear and
unambiguous as possible. The rationale helps in understanding where the principle comes
from and also gives the reason why it is a principle the organization wants to comply to.
Implications present effects of a principle if it is applied. This is achieved by formulating

statements that are similar to a principle statement. There is a thin line between an implication
and a principle. During the development of a principle, it is possible to discover that an
implication should be upgraded to become a principle or the other way around where a
principle is actually an implication for another principle. Two differences between an
implication and a principle can be identified:
• An implication clearly concerns a specific area within the area determined by the
principle, for instance in case of a principle regarding the area of customer
relationships, an implication can concern the specific area of sales or claims handling.
• An implication has less priority than a principle and the compliance with an implication
is managed less strict.
Besides considering implications to be an effect of the application of the principles,

implications can also be regarded as conditions. These conditions can be seen as
requirements for the truthfulness of a principle that are necessary in order to comply with the
principle. These two ways of interpretations implications have to be made clear to those who
are involved in the development of the principle. A suggestion to make this distinction
explicitly could be to consider the effects of the application of the principle as sub-principles.
However, by having sub-principles and perhaps even sub-sub-principles, it becomes a
greater challenge to maintain an overview of all principles. Taking into consideration the
status of the EA awareness at AF-KL Cargo, this distinction is left out of the scope in the EA
development. Nevertheless, it remains an interesting topic for future discussion.
As mentioned before, the key actions of a principle can be regarded as actions that have to
be done in order to comply with the principle. In essence, the key actions of all the principles
combined together are able to form projects that have to be carried out. Because of this, the
key actions can be considered equal to the high level business cases that are used by the
BDO. Thus we could associate key actions more with the actual realization side and because
EA is about guiding the realization process, we could argue whether or not key actions should
be an element of an EA. It is also arguable what the added value of stating the key actions
are if they are equivalent to the project portfolio. Nevertheless, key actions are good to have
in order to show the practical meaning of complying with a principle.
3.2. Principle organization

Next to formulating principles properly, these principles should be organized such that they
are manageable. The principles in this project are developed having a certain notion of an
enterprise in mind [17]. The relevance of this enterprise notion in organizing principles will be
explained below. Also, the framework that forms the starting point for the business principles
will be presented.
13
3.2.1. Enterprise architecture perspectives
An EA should take a holistic view on an enterprise [18]. To accomplish this, an enterprise can
be viewed from a number of different perspectives [17]. The figure below depicts the
perspectives that form an enterprise:
• The business perspective regards those enterprise activities that are purposeful and
gainful. Examples of issues that matter from a business perspective is the customer
relationship, the enterprise offerings, etc.
• The organization perspective regards the manner by which the here fore mentioned
activities are arranged. Issues such as processes, performance and employee
behaviour are the part of this perspective.
• The information perspective regards the information necessary to perform the business
and organizational activities. This perspective includes aspects such as gathering and
presenting information.
• The technology perspective regards the specific use of knowledge, methods, human
and physical resources that are needed to implement the enterprise. In AF-KL Cargo’s
case, the technology perspective focuses on topics such as airplanes, pallets, IT, etc.
Figure 1: Different perspectives on an enterprise.
3.2.2. The Business Architecture Framework
The principles in the business architecture should be managed properly in order to improve its
applicability. This can be done by organizing the principles in domains for which they are
relevant.
Business Domain Definition
To justify the need for an architecture in the business domain, the overall enterprise view has
to be taken as a starting point. The enterprise can be seen as a system which can be viewed
from two distinct perspectives, the functional and constructional perspective [2]. The
functional perspective of an enterprise can be seen as a “black-box” model of the enterprise
and is perfectly suitable for managing and using the enterprise. In the context of enterprises,
the functional perspective is usually called the business perspective. In order to develop the
functions or business of the enterprise properly, the EA should cover this perspective.
The business of an enterprise can be seen as carrying out the goal- and externally-oriented
and revenue generating activities. From a business perspective the question should be raised
regarding how such a business should be exploited, explored and developed. The business
architecture answers this question and can be defined as:
A logical consistent and coherent set of principles prescribing how a certain field of
(commercial) endeavour should be exploited, explored and developed. [13]
14
In other words, the business principles should guide the design of the functions of the
enterprise. Such a functional design is usually presented in a business model, which
describes the business by breaking it down into several key elements. These elements are
used to specify the business domains.
The business architecture framework presents the business domains that have to be taken
into account when developing the business architecture. Besides providing a checklist for
architects, a framework also improves the manageability of the principles by presenting the
context in which the business principles must be used.
The business domains in the business architecture framework are based on research on the
business model concept in [19] and the suggested framework in [13, 17].
Hedman and Kalling business model concept
The business model concept of Hedman and Kalling is presented in figure 2. This concept
shows components of a generic business model that represent four key levels:
• The market level,

• The offering level,
• The resource level and
• The activities and organization level.
Figure 2: Hedman and Kalling business model concept.
The first level consists of components that present information regarding the market, such as
customers, competitors and suppliers. The offering level includes components such as
products and services offered by the enterprise to the market. The economic model that is
used for these offerings also belongs to this level. Important resources within the enterprise
are part of the resource level.
The activities and organization level regards how the enterprise is organized. The
components on this level don’t belong in the business architecture framework, because they
don’t address the question how the business should be exploited, explored and developed.
15
The question how the business should be organized is raised in the organizational domain
and answered by principles in the Enterprise Organizational Architecture.
As already mentioned before, the functional or business perspective of an enterprise is similar

to a “black-box” view of the enterprise, which shows the functions of an enterprise. In other
words, it presents what you can do with the enterprise and what it will provide to its
environment. The components in the generic business model described in the market,
offering and resource level can be regarded as aspects that have to be taken into account
when developing these functions of an enterprise.
Hoogervorst Business Architecture Framework
The business architecture framework suggested by Hoogervorst is depicted in figure 3. The

framework consists of two parts. The left side shows the mission and strategy from which
principles should be derived (or the principles should be consistent with mission and
strategy). The right side presents domains for which principles have to be devised. These
domains are the starting point for developing the business architecture framework that will be
used in the project.
Mission Market Competitors
Sense making Market mix Lead/follow strategy

Purpose Market exploitation Relative position
Products
Key Resources Customers
Services
Customization Type/source Relationships

Value Deployment Personalization
Quality Interaction
Integration Interfaces
Standards Org. focus
Operating Method
Channels
Partners
Strategy
Economic and
Learning
Revenue Model
Renewal
Adaptation Core focus
Choices Income mix
Environment Stakeholders
Impact Impact
Contribution Contribution
Figure 3: Hoogervorst Business Architecture Framework.
According to Hoogervorst, the Market domain contains principles that guide how the market
should be exploited and explored. Examples of principles provided by Hoogervorst are:
• Marketing should move from mass marketing to one-on-one marketing,

• At least x% of the market share must come from recently (< 5 years) introduced
products and services.
The examples presented above have a strong relation with other domains beside the Market
domain, such as the Competitors and Customers domain. The market domain focuses on the
area in which three entities come together, the competitors, the customers and the enterprise
itself. The question remains whether or not this area is essential enough to have its own
16
domain in the framework. To keep the framework as concise as possible, the Market domain
will be left out from the business architecture framework. The other domains together should
be sufficient to cover the market area.
The Products and Services domain focuses on the development of products and services and
principles in the Economic and Revenue Model domain guides how the enterprise should
earn its money. These two domains are similar to the components presented by Hedman and
Kalling on the Offering level. Both the business model concept and the suggested business
architecture framework of Hoogervorst present these two domains as essential to a business
view on an enterprise and will therefore be included in the business architecture framework
for this project.
The Key Resources domain in Hoogervorst’s framework focuses on how important resources
should be deployed. These resources are more than just funds and people; it also includes, in
case of AF-KL Cargo, the AF-KL Cargo network, the planes and the fact that AF-KL operates
with two hubs. This might not be clear if the term “resources” is used. Therefore this domain is
renamed to Key Resources and Assets.
According to Hoogervorst, the way products and services are delivered to the customers is
defined in the Operating Method domain. The use of channels and partners are part of this
domain. However, the interaction and interface with the customers have already been
handled in the Customers domain, which renders this domain obsolete. Nevertheless, this
domain puts light on some business components that haven’t been included in Hoogervorst’s
framework, which are partners and suppliers of the enterprise. Instead of having the
Operating Method domain, a Partners and Suppliers domain is included in the business
architecture framework.
Although the aspects Environment and Stakeholders should be on the agenda of every
member of the senior management, it doesn’t belong to the business architecture framework
as a separate domain. The Environment aspect should be regarded as an area of concern
that has to be taken into account during the development of the business architecture.
Stakeholders and their wishes should also be represented in the business architecture by
means of areas of concern.
Although the business architecture framework should only consist of domains representing
the essential aspects of an enterprise, developing this framework unavoidably includes
subjective choices. The business architecture framework suggested by Hoogervorst presents
his choices, whereas the framework which is used in this project reflects mine. In practice, the
domains of the business architecture framework should be the result of discussions between
the architect and senior management regarding the relevant aspects of the enterprise.
The Business Architecture Framework
The models developed by Hedman and Kalling and Hoogervorst show their interpretation of
what is important for an enterprise from a business perspective. From their interpretation, a
view of enterprise from the business perspective has been developed that is used during the
project.
With this view on an enterprise’s business in mind, the business architecture framework within
which the business principles will be organized is developed and illustrated in the figure
below. The figure shows that the framework is based on a number of sources, such as the
strategy, vision, etc.
17
Business
Trends
Strategy
Business Architecture Framework
Economic & Revenue Model Competitors Vision
Products & Services Customers
Key Resources & Assets Partners & Suppliers
Best Practices
...
Here & Now
Figure 4: The Business Architecture Framework.
3.2.3. Domain Definitions
Below each domain in the business architecture framework will be defined.
Customers
Definition
The Customers domain regards the design and development of the relationship between AF-
KL Cargo and the customers.
Rationale
Customers are an important factor on which AF-KL Cargo business should focus on. This
customer relationship includes e.g. how Cargo should select its customers, the interaction
between Cargo and customers, etc.
Competitors
Definition
The Competitors domain deals with the relative positioning of AF-KL Cargo to the
competitors.
Rationale
Next to customers, the focus on the market should cover the competitors. The competitors
are also a key element of the AF-KL Cargo business. For example, decisions have to be
made regarding the relationship with the competitors in order to react properly to changes in
the competitors’ stances.
18
Products and services
Definition
The Products and Services domain considers the design and development of products and
services for the market.
Rationale
Products and services represent the offering of AF-KL Cargo to its customers. Decisions that
are relevant for the development of the products and services of AF-KL Cargo must be
considered as an important component of the business. Development also includes design,
marketing, implementing, etc.
Economic & Revenue Model
Definition
The Economic & Revenue Model Domain concerns the financial gain that can be achieved
from the activities that are involved in the AF-KL Cargo business.
Rationale
The prices of the products and services also belong to the offering of AF-KL Cargo. This
element in the business puts emphasis on the financial aspect of the business of AF-KL
Cargo. Focusing on this aspect enables the AF-KL Cargo business to sustain and grow.
Key Resources and Assets
Definition
The Key Resources and Assets Domain takes care of the management and development of
resources and assets that are important for realizing the business.
Rationale
Enterprise resources and assets have to be leveraged in order to create competitive
advantage. By focusing on the core competences it can be made clear how the enterprise
should develop itself to achieve its objectives.
Partners & Suppliers
Definition
The Partners and Suppliers Domain regards the development of the relationship with partners
and suppliers.
Rationale
A good relationship with partners, with whom you cooperate, and suppliers, that deliver key
resources, is essential in doing business. This key component of the AF-KL Cargo business
has to be exploited, explored and developed correctly as well as the other components.
3.2.4. Principles in the EWTA
The principles in the EWTA have provided insight in how a principle should look like.
Unfortunately, the development of these principles didn’t result in a set of guidelines which
can be used for this project. Still, lessons can be learned from how these principles were
developed and the differences between the development of principles in the EWTA and in the
Business Architecture.
The EWTA is based on the theory of architecture presented by the META Group [20]. Many
enterprises have adopted this view of architecture and the META Group has provided the
best practices in IT in the form of a set of IT principles. Together with the results from a
meeting within KLM regarding the best practices in IT, these principles form the basis for the
development of the Conceptual Architecture. This Conceptual Architecture contains
conceptual principles regarding the overall IT developments within Air France KLM.
19
Within the EWTA, domains are defined which represents a specific area of IT development,
such as E-business, Infrastructure, etc. These domains contain domain principles, each of
which is related to or derived from one or more conceptual principles. This mechanism with
the conceptual and domain architectures ensures that all principles are consistent with each
other and the essential goal of IT, which is reflected in the conceptual principles.
The same mechanism should be implemented for the EA. However, in stead of having
conceptual architectures for each enterprise perspective, the Business Architecture should be
considered as the same role as the conceptual architecture. The business architecture is
based on the enterprise objectives and in order to ensure the consistency between all
principles and the enterprise objectives, all principles in the other enterprise perspectives
should be traceable to one or more business principles.
3.2. Aerospace Logistics EA awareness

One of the remarks I made in the analysis chapter was that when I first started my internship
at AL the EA awareness there was close to zero. During my introduction meeting with the AL
management team (MT) where I explained the purpose of my thesis project, which was at that
moment defined as devising an EA for AL, I noticed that the MT members had no idea what I
understood under the term EA. This came as a surprise to me because my initial thought
about AF-KL Cargo was that the concept of EA was already well embedded in the
organization. I got this perception through various presentations on “EA at AF-KL Cargo” by
Jan Hoogervorst10 [2] and also through a presentation on the same topic by Hans Zwitzer11
back at DUT [21]. Additionally I understood from our professor Jan Dietz that AF-KL Cargo is
one of the front-runners in applying EA within the Netherlands [9].
With the situation as depicted above I had to revise my initial approach; instead of directly
going into the process of devising architecture, I must first raise the EA awareness at AL to a
point where everyone of the MT
1. knows what EA is,

2. understands what EA could mean for their organization and
12
3. is willing to participate in the development of EA .
I started with individual meetings with each of the MT members in order to achieve the above
three requirements. In these meetings I engaged into a dialogue where I try to relate the
interviewee’s work with EA and at the same time I avoided using terms like architecture and
principles. These terms tend to create confusion when used without a proper introduction
towards the terms. This is probably because there is still no uniform understanding on the two
terms; nowadays architecture is used for almost everything IT related [9] [11] and the notion
of principle could also deviate from person to person.
The approach I applied was to engage into the conversation in the “language” of the other
person. Although the appropriate language is slightly different for each individual, we could
state that the language of the AL MT is day-to-day business and operation orientated (e.g. the
13
usage of Scarlos [22] terms and practical examples in their explanations). For that reason I
backed my explanation on EA with a close-to-door example deduced from the Blueprint14 [23].
As stated earlier I did not throw the terms architecture and principles directly to my
conversational partner. Instead I used more familiar (or less confusion generating) terms like
(business) rules as oppose to principles. Of course the two are not synonyms of each other,
10
Former CIO of KLM.
11
Manager Business Architecture at AF-KL Cargo.
12
The MT members have to devise the principles. The architect has a facilitator role in this process.
13
Service Cargo Logistic System is the main and most important application at Aerospace Logistics that supports
the majority of the AL processes.
14
Assessment report by an external consultancy bureau regarding the repositioning strategy of Aerospace Logistics.
20
but if I state an architectural principle and I denominate it as a business rule and the other
person knows what I’m talking about, then there we have it; mutual understanding on the
subject.
As soon as the other person gets more and more familiar with the concept, I can carefully
state that the business rules are actually principles; a more general form of rules concerning a
class of systems. If then a sense of recognition is spotted, I can work towards saying that all
those business rules or principles can be considered the architecture of the organization.
In this way the concept and the accompanying terms are better accepted and understood.
Especially considering that the management overall agree that rules can help in improving the
organization by setting the work field boundaries of the employees. From that point the
analogy towards the value of principles and architecture is straightforward.
Although the above sketched approach did raise the awareness and the knowledge on EA of
the MT members, it was still not at a level from which I could start devising architecture with.
Partly due to that even with an example deduced from the Blueprint, the EA concept was still
hard to visualize. Also, it is not reasonable to expect that with just one example the concept of
EA will be clearly understood by management. Thus, I might have been too optimistic in
thinking that the meetings will fully persuade the MT members to comply into the architecture
program. However, I did get their attention and interest, and I have to elaborate on that.
The turning point came when I did a presentation for the AL MT about what EA could mean to
15
AL . Because it came to my attention that in order for people to be able to visualize what
exactly EA is all about, I had to show them a fully elaborated example of a system that is easy
to understand and recognizable. Moreover, the example should be unrelated to the business
of AL in order to avoid discussions about the different perceptions of the AL MT members on
the direction of AL. Such debates are undesirable at this stage where the focus should be set
on clarifying the notion of EA. Consequently Mario’s and Luigi’s pizzerias came to existence.
The simplicity of a pizzeria as an example proved to be a success. The value of EA was even
more visualized with the addition of the contrast depicted in Mario’s and Luigi’s business
architecture where it is shown that two completely different and contradictory approaches can
be used to achieve the same strategic goals. This was widely recognized by the MT members
and resulted in that the director of AL himself, Kees Buitelaar, requested to have a get-
together in order to devise the business architecture of AL. This point also signalled the start
of the process of devising architecture, as the three “awareness” requirements I set earlier
had just been met.
3.3. Aerospace business architecture

In the previous section I described the process of raising the EA awareness at AL. Here the
subject will be the process of devising the AL business architecture.
16
If we look at the project planning in my project proposal , an indication on my project
progress in relation with time is shown. At this point in time we are in the month July which
corresponds fairly with the initial planning; about 5 months in the project17.
3.3.1. Pre-study
In order to prepare and familiarize myself with the AL business and strategy, I have done
some pre-study before actually devising the principles with the members of the AL MT. This
18
includes studying the strategy documents such as the Blueprint, the Huizen presentation
15
The presentation slides are included in the appendix C.
16
Included as appendix F.
17
The period reserved for the process modeling will be handled in the next section.
18
Presentation slides for the AL management meeting concerning the AL strategy.
21
[24] and this financial year’s business plan. These documents are all presented in the
PowerPoint format with no additional notes for clarification. So in order to make sure I fully
understand the documents, I arranged meetings with some MT members where I could ask
them for clarification.
With the information gathered this way, I was able to deduce a set of AL business principles.
These principles could in turn serve as a reference during the actual session where the
principles will be devised by the MT members. Reference here meaning that I could bring up
my devised principles to the group as suggestions to avoid that an important principle or a
related principle is skipped or not thought of during the session.
Next to the above described document study, I also participated in a workshop concerning the
main AL application Scarlos [22]. The intention of the workshop was to identify the issues of
the Scarlos user interface (UI) and if possible find a solution on the spot. The workshop was
initiated because the management had the feeling that the application is not being used
correctly by the operational staff.
The workshop was participated by a mixed group consisting of people from the IS who are
responsible for the maintenance of Scarlos, someone from Operations representing the users
of Scarlos, representatives from invoicing and customs handling because the misuse/abuse
of the application ultimately results in problems at invoicing and customs handling, the AL
Information Manager and people from the AL management. Initially the workshop was
planned for one session of 2 hours, but in the end another session of 2,5 hours had to be held
in order to get the job done.
With the Scarlos UI projected on the big screen, the person from Operations explained how
he used the application by stating what he understood from each text field and what he then
fills in. This resulted in the observation that due to the user-unfriendliness of the application
some particular fields are misused to get the work done much quicker which matters the most
for the production work at Operations. The people from invoicing and customs handling then
points out that because of those input errors, they get problems when it comes to invoicing
and customs handling. But at the same time they show understanding that if the operational
staff were to use the application correctly, it would take too much overhead time to get the
daily work done on time. This dilemma formed the main discussion point during the workshop
and it wasn’t realistic to think that a solution on the spot could be found for this.
What I observed from the workshop was that it brought up essential issues regarding the
efficiency and user-friendliness of the Scarlos UI. It also made the different parties that holds
a stake in the application understand each other more. However, I do not think such approach
is correct when it comes to finding structural solutions to improve the application or the
operational process. The session was too much focused on the solution at hand, which is the
implementation of the Scarlos application. Such approach then seems to be rather risky
19
considering the history of Scarlos and can only result in solutions curing the symptoms
rather than the actual problems [25].
Nevertheless, the initiative could prove useful in realizing quick-wins, because some identified
issues are just a matter of clarifying the function of the particular text field. For more structural
20
solutions, however, the system development process should be applied.
The initial reason why I participated in the workshop was because of the AL process
modelling part in my master’s thesis project. The workshop concerned the order management
process at AL and thus I thought it could give me valuable insights on that part of the AL
process model. In the end participating did indeed help me understand the operational
processes along with their current issues much better, but moreover the workshop gave me
an idea on the current way of working regarding how the business-ICT alignment problem is
tackled at AF-KL Cargo, in this case: to what extent Scarlos supports the AL business.
19
Discussed in the analysis report.
20
See appendix E for an overview of the generic system development process.
22
21
The result of this workshop is a list of Scarlos UI issues. From what I have heard no follow-
up steps have been performed yet, not even the identified quick-wins. However, I was
ensured that actions on the matter will certainly happen soon.
Up until now all activities, from the analysis phase through the EA awareness program to the
pre-study, are performed in order to come to a stage where the actual business architecture
could be devised. In the next section I will describe the details on this process of devising the
AL business architecture.
3.3.2. Devising the AL business architecture
As mentioned earlier in the Aerospace Logistics EA awareness section, the director of AL

himself indicated to arrange a gathering to devise the business architecture. A workshop was
thus planned for just this. However, on the planned date for the workshop two members
(Vincent Sprenger from Engineering and Rob Ringersma from Sales) of the MT would be on
holiday. Because it is of importance to have the input of all the members of the MT, I manage
to schedule an individual session with the two members just before they went for holiday. The
findings/principles devised from these sessions will then be used as input for the actual
workshop so that Rob and Vincent’s perceptions are at least taken into account. At the review
of the devised business architecture the complete AL MT will then be present to have a
discussion on what the final business principles of AL are.
Workshop process
The intention of the workshop is to come to a business architecture with which AL should
22
approach its commercial terrain. To support this process Andrew Go and I have put together
23
a workshop tool, Group Decision Tool (GDT) [26], which is implemented in the form of a
24
website . The GDT is similar to the so-called “geeltjes-sessie” where participants write down
their input on post-its. In order for the GDT to work properly participants were requested to
bring their own laptops. A picture on the setting of the workshop is given in figure 5 below.
21
From Roland Spijker, responsible for the AL process model.
22
A fellow student who is also place at AF-KL Cargo for his master’s thesis project.
23
Also known as Group Support System.
24
http://afklcargoworkshop.awardspace.com
23
Facilitator
Participant Participant
Figure 5: Workshop setting.
Discussion on the advantages and disadvantages of the two approaches are left outside of
this report. The main reasons why we have chosen for the GDT are 1. it avoids that only the
input of the prominent individuals are heard, 2. all the input is stored nicely in the database
and easily exported to a text document, and 3. I was not familiar enough with the post-it
25
method to actually use it , as oppose to the GDT method which I got acquainted with in the
course designing multi-actor services systems at DUT. To give the reader an idea on how the
GDT works, I have included in appendix G its manual.
The workshop itself can be subdivided in several rounds, each round with its own objectives.
In table 1 the rounds with their objectives are shown. Further explanation will be provided
shortly hereafter.
Objectives:
Round 1: Generate principles.
Round 2: Cluster principles into the six business architecture domains.
Round 3: For each domain, cluster similar principles together.
Round 4: For each domain, discuss principles.
Table 1: Objectives table for each workshop round.
In round 1 the objective is simple; generating principles for each business architecture
domain, see figure 4, by the participants individually supported by the workshop tool. This is
the round where the participants have to be “creative” and actually be productive. To facilitate
26
this process I prepared some domain questions and pizzeria example principles . These
25
The first time I experienced a “geeltjes-session” was during a Business Analysts session about the CPM. To KLM
employees this method seems to be quite well-known.
26
See appendix D.
24
questions and examples serve as a kind of kick-off to get the thinking process started and
also to help the participants in the direction they could think of for their principles. Next to this,
it is of importance that the participants realize that the questions I prepared are not
exhaustive. The process is more like a brainstorm session and the participants are
encouraged to write down anything they think is a business principle. A nice feature of the
GDT here is that each participant is able to view the most up-to-date list of the devised
principles by all the participants on the same screen they use for generating his own
principles. This way a participant can use the list as an inspiration source, see figure 6.
Figure 6: The “Generate Principles” page.
In round 2 the group will collectively cluster the generated principles into the business
architecture domain they belong to. This activity didn’t have its own supportive functionality in
the GDT, simply because I haven’t thought of it during the development of the tool27. I
assumed that in each workshop only one or two domains will be handled which then wouldn’t
pose any lack of overview problems. One could imagine the situation would be quite the
opposite of what was assumed when 6 to 8 people individually generate principles for six
domains. Not only will there be quite a number of principles (turned out to be ± 100), the
principles about one domain will be scattered around principles about other domains. A
solution on the spot for this was found by creating a new cluster for each of the domains and
attaching the matching principles in those clusters. Thus at the end of round 2 we would have
six domain clusters with their related principles within them.
Round 3 is again a clustering round, but this time the group is requested to cluster similar
principles together from each domain. Practically this means that we choose one domain, let’s
say the customer domain, and we examine for each of the customer domain principle if there
isn’t already another similar principle in the list. If so, we attach the principle to the other one,
or the other way around depending on which of the two principles is “better”. If not, we go on
to the next principle. This procedure is repeated until we have gone through all of the
customer domain principles. The result of round 3 is that we have a list of distinctive principles
for each of the six domains.
In round 4 we will actually treat and discuss each of the clustered principles we now have.
Taking one principle at a time we go into the details on whether or not it is indeed a principle
for AL. Also it is in this round where the implications are devised along with refining the
27
The tool was implemented in a rather quick and dirty fashion and thus not conforming in today’s software
engineering practices.
25
principle statement and rationale. After round 4 we should have a first version of a “complete”
AL business architecture. The word complete is relative here, because an EA is never
finished; it should be continuously updated and evolves in time [27].
So above I have explained the workshop process that I had in mind to facilitate the AL MT in
devising their business architecture. However, I already mentioned that before this workshop,
I had two meetings planned with Rob and Vincent individually to obtain their input for the
workshop before they went for holiday. I will describe the process of these two sessions
below where after I will go into the details of the actual workshop.
Individual business architecture session Vincent Sprenger (14-07-2006, 1,5 hour)
The supporting website idea to generate principles was not recommended for use in an
individual session. Therefore I have decided that the best way to discover the business
principles here is to have a dialogue with the participant where I stimulate and steer the
participant into thinking about principles in each business domain.
28
Before the actual meeting I have sent Vincent some preparation material where I highlight
what exactly each business domain means with some domain questions that can help in
discovering the principles. Also some example principles of the pizzeria were included to give
an idea what I was looking for as the result of the session.
After going through the preparation material with Vincent and making sure he got the meaning
and intention of our session, I began asking him the domain questions in order to discover the
principles for each domain. I have avoided to end up in a typical Q&A situation where I state
the question after which the participant answers and then on to the next questions. Instead
the questions served as a kind of kick-off into a discussion where the participant typically
answers the question in a story-like fashion. Often practice situations are included in the
answers from which I then try to figure out and steer the participant into possible principles by
asking follow-up questions. In some cases I take the opportunity to state a possible principle
that I have deduced from the answers and ask the participant if it is indeed a principle he
follows. Besides sometimes a yes and a no, refinement on the stated principle and
clarification will then be given to me. This way I can get right to the point where I can directly
write down some business principles.
The direct result from the session was not a list of business principles, but more a set of notes
where I can deduce the principles from. Of course, there were some principles that I have
written down directly from the session as I have already depicted above.
After I have made a set of principle statements (12 principles) from my notes, I sent it back to
Vincent for feedback. Note that the rationale and implications for the principles were not
included mainly because it was not realizable to correctly figure them out from an 1,5 hour
session. Another note is that I was not able to arrange a separate meeting for feedback
because the session was too close to the date where Vincent is going on holiday. However, I
did manage to get some feedback during an informal talk at the coffee-machine.
Basically, Vincent finds the principles too black and white which make them in most cases not
viable because only under certain circumstances the statements are true. Another remark
was that the principles are too general and high level in which they become trivial and
therefore lack practical relevance. Vincent was also of the opinion that his boss is the one that
needs to answer the questions I asked him during the session and set up the principles. He
will then just follow the devised principles. However, although a boss tells his employees what
to do and to accomplish, the employees that are actually going to execute the boss’ requests
have some principles at the back of their head about how to do his work correctly. Next to this
each employee also has his own perception on what he understood the boss told him to do. It
is these principles and perceptions that need to be put on paper and discussed if they are
indeed correct in order to have everyone working towards the same company goals.
28
See appendix D.
26
Vincent’s first comment that the principles seemed too trivial to be of any use could be
explained by the fact that we didn’t have enough time during the session to handle the
implications of each principle. Although I did explain that the implications of a principle is
where the link to the practical relevance is to be found, because there it is shown how the
principle will impact the business and IT Community [14]. This is hard to realize when you
only have the principle statements without its implications.
The other comment that the principles are rather black and white and actually need further
explanation beside the statement is also something understandable. This is, however, a
matter that needs to be tackled in a group discussion where the principle is discussed to
sharpen the statement.
Individual business architecture session Rob Ringersma (21-07-2006, 1,5 hour)
This session has the same setting as the one with Vincent and the overall approach was the
same.
In the end I was able to deduce 14 principles from this meeting. Feedback on them was not
possible because the next day Rob already had his holiday.
Workshop 1 (26-07-2006, 5 hours)
In this section I will describe how I actually carried out the workshop process that was
discussed earlier. In other words, a report on the actual workshop will be presented next.
Prior to this workshop, a similar workshop about the same topic with business analysts was
organized as a kind of test session. The goal was to see if the workshop setting and approach
were feasible and effective. I especially wanted to test the practical use of the GDT.
In the end I received positive feedback from the business analysts and they also gave some
suggestions for improvements. One of those suggestions was that enough time should be
reserved for the discussion round. Because ultimately the true value of the workshop lies at
the discussions between the participants about the devised principles. There the alignment of
the various perceptions and interpretations of the participants takes place.
Another suggestion was that in order to save time the clustering of the principles should be
done in a break with just a few participants. They felt it was unnecessary to have the
complete group present to be able to cluster the principles.
About the workshop tool the business analysts were particularly positive. They found that the
tool was very effective in supporting the brainstorming phase and they also found it was very
easy to use.
Thus taking into account the remarks I received from the business analysts and having made
some minor tweaks on the workshop tool, I felt confident (enough) to carry out the workshop
for “real” with the AL MT.
As stated earlier the goal of the workshop with the AL MT is to identify principles with which
AL should approach its commercial terrain. The same preparation document as the one for
Rob and Vincent has been sent to the participants along with the workshop agenda29. The
participants were also requested to bring along their laptops in order to make use of the GDT.
I started with a presentation in explaining the Business Architecture Framework (with the help
of the pizzeria principle examples) after which I introduced the participants to the GDT.
Supported by this tool the participants started generating principles on their own laptops. We
started by handling one domain for a fixed period of time (10 min) where I served as a
facilitator by helping the participants on where they could think of (areas of concern and
domain questions) that might have some principles involved. Next to this I also inserted the
prepared principles from Rob and Vincent as input.
29
See appendix D.
27
The first few minutes in generating principles I could see the participants struggling a bit, but
after a while it went quite smoothly generating a total of 100 principles at the end of the
“generate principles” round. Also after some time I indicated that the participants could go on
to the next domain as soon as they cannot generate any principles for the current domain
anymore. Of course I also mentioned that they could just insert a previous domain principle
any time they came up with one.
I observed that sufficient time should be taken to let the participants write down their
principles, because coming up with principles and formulating them must not be hurried. Not
to mention the thinking time needed to actually come up with a principle. The participants also
took short breaks (getting a drink, walk around a bit, etc.) when they have a temporally blank
mind and couldn’t come up with principles. This apparently helped their creative mind
because after the breaks they started writing down principles again. Such a loose and free
setting was possible because we had a tight group which consisted of only AL MT members.
If we look at the agenda for the workshop30, we can notice that the clustering rounds (round 2
and 3) were not scheduled as activities. This was because I took the advice from the business
analysts to do the clustering with only a select few participants in the break in order to save
time. However, during the actual workshop we still ended up clustering the principles with the
complete group. In contrast to the case with the business analysts, the AL MT didn’t perceive
the clustering rounds as overkill and time-wasting. They rather appreciate the clustering
activity because it was a good way for each participant to learn what other participants have
inserted as principles.
We started the discussion round shortly after we concluded the clustering round. First I
explained what we were going to do in this round and then I took up a coordinating role. My
main concern here was to monitor the consistency between the principles and to steer the
discussions so that we can all agree on the correctness of each principle and at the same
time correctly formulate the principle statement, rationale and implications. Regarding Rob
and Vincent’s principles I explicitly stated that they served as input which we have to take into
account, but review on them will have to come when both Rob and Vincent are present.
The discussions we had were very lively and involved many practical examples that are used
to reason why a certain principle is true or, of course, false. At the end of the session we
managed to finish the customers and competitors domains and by initiative of the participants
a follow-up session was planned to discuss the rest of the domains. This was a pleasant and
encouraging event because initially I had only planned this session to devise the business
architecture. But also the fact that the next meeting is planned on just two days after the
current one with some of the participants having to reschedule already planned meetings
showed the participants’ commitment.
Workshop 2 (28-07-2006, 2,5 hours)
This follow-up workshop was intended to finish the business architecture by handling the
other four domains that we didn’t had time to discuss in the last session.
Little explanation on the process was needed, because the last workshop was only two days
ago and thus still fresh in the mind of the participants. So we started right to it by handling the
products & services domain. After which we did the economic & revenue model domain. Due
to the lengthy but rewarding discussions for these two domains we again ran out of time with
still two more domains left to handle.
Thus a next meeting had to be planned to finish the job, again by initiative of the participants
with some rescheduling and shuffling in the agendas involved.
30
See appendix D.
28
Workshop 3 (31-07-2006, 2,5 hours)
In this last workshop we handled the last two domains, namely partners & suppliers and key
resources & assets. We manage to finish the two domains with some extended meeting time.
I concluded the session by stating that I would sort out and touch up the result from the
workshops and plan a review meeting with the AL MT (with Rob and Vincent included). I also
asked for feedback from the participants on the whole process which I will discuss later on in
this report. First I will handle the review meetings on the business architecture.
Business architecture evaluation meeting 1 (25-09-2006, 2,5 hours)
It has almost been a period of two months between the last workshop and this review
meeting. The month August was skipped due to holidays of almost all the members of the AL
MT. Therefore the review meeting was planned at around mid September. This meeting was
also participated by my supervisor Hans Zwitzer. He was interested in the result of the
workshops and also in what the workshop participants thought about the whole process.
The purpose of this meeting was threefold: 1. Give an overview of the whole business
architecture that was devised during the workshop sessions, 2. Fill in the missing rationale
and implications at some of the principles and 3. Give Rob and Vincent the opportunity to give
their comments.
With the business architecture in Word projected on the big screen we collectively went
through each principle. For most of the missing rationale and implications I have inserted my
suggestions in red. It is then for the group to decide on the correctness of my suggestions.
While some of the principles were agreed upon straightaway by the group with sometimes
minor adjustments and/or additions, other principles invoked discussions where the group that
were present during the workshops explained the context of the principle to Rob and Vincent.
There were also cases where the workshop participants themselves needed to rethink what
the exact meaning of the principle was; it had been almost two months after all. It was then
my role as the facilitator to remind the participants what the focus and reasons were for that
principle.
In most of the cases I only needed to provide a short explanation on what the intention of the
principle was where after one of the participants recognized it again and took over in
explaining the principle’s context in detail. Thus, the session was not so much another
devising the business architecture workshop for Rob and Vincent, but more a session where
the business architecture got reviewed and where needed sharpened by not only the input
from Rob and Vincent, but input from the entire AL MT.
In the end of this session we covered almost half of the total number of principles. The
reaction of the participants was that we should hold another session to finish this review. They
commented that they thought the discussions they had in the session were useful and
certainly necessary in order to clarify the direction where AL wants to go. At the same time
the director of AL mentioned that such initiative is something he never did for AL before and
suggested to continue this on Thursday (3 days after the current session). Thus the next
session is planned on Thursday.
Business architecture evaluation meeting 2 (25-09-2006, 3 hours)
This meeting was planned in order to finish reviewing the rest of the business principles. After
projecting the business architecture on the screen we picked up where we left last meeting.
The session went the same like the last one and we managed to discuss all the principles
during this session.
Afterwards when I asked for feedback on the whole business architecture trajectory that we
had gone through the past few months, a discussion started about where to go from here and
what still needed to be done. The participants showed interests in the overall picture in the
29
system development process. They realized that having the business architecture is not
enough to properly develop “good” systems.
Thus with the picture in figure 7 [8] I explained that indeed we still need to devise the
organization and information architecture in order to properly guide the design of systems. I
also pointed out that a proper “white-box” model of AL is needed as the starting point for
(re)design initiatives.
I further mentioned that practically an AL process model could serve as this white-box model
and that I have already devised a great part of this process model in DEMO, as we shall see
further in this report. What we also have now is of course the business architecture. I
explained that devising the business architecture has been an important step because it
forms the basis for the development of the organization and information architecture. Coming
to this point where we are able to devise the business architecture is of course also a major
step towards working under architecture.
It was thus clear to the AL MT that what we still need were the organization architecture, the
information architecture and the completion of the AL DEMO model. The AL director then
showed determination in making sure that these things to be done are properly covered; he
didn’t feel like having just a semi-finished product and wanted to give continuation to the effort
spent by the AL MT in the EA trajectory. In this discussion the possibility for Andrew Go and I
to be involved in this after our master’s thesis project came up. We were certainly interested
in the proposition and decided was to discuss this possibility in a later stadium after our thesis
project.
Figure 7: System development process.
Workshop result
Having described in detail the process of devising the AL business architecture above, I will
discuss the actual result, the AL business architecture, in this section. The (practical) value of
a business architecture could be listed as follows:
30
• Ensures that management members are in line with each other on the business
approach of their organization.
• Assists the management in its (business) decisions.
• Forms a basis from which the organization and information architecture can be
devised.
• A communication tool to the outside31 and higher management in explaining the
organization’s business approach.
The AL business architecture document that is included as appendix A in this report, has
undergone a number of refinement changes during a total of five development sessions. It is
therefore not possible to report all of those changes here in detail. However, the type of
changes we encountered in the sessions will be highlighted hereafter.
The first type of change concerns the refinement of the principle so that the meaning and
intention of it becomes clear to everyone who reads it. Each element of the principle
(statement, rationale and implications) is tackled here. In most of the cases where a
refinement is needed a reformulation of the principle statement would suffice, but there were
also cases where additional explanatory text is added to the rationale and sometimes
implications were added.
Next there were also changes where we had to “degrade” a principle to an implication of
another principle, simply because the principle in question had to be considered that way.
Another change concerned a principle being moved to another business domain. The reason
for this is straightforward: the principle in question fits better in the other domain than the one
it is currently in.
The last type of change I would like to discuss is the deletion of a principle. After the review
sessions we deleted three principles. The reason for this was that the deleted principles
couldn’t be considered as principles. They didn’t signify a choice and they were more like a
general point of departure for the organization. A remark must be made here that deleting a
principle must be considered very carefully, because without a proper logging mechanism
deletion is an action that cannot be undone. Below the three deleted principles are shown.
Cluster: Competitors: Market information must be included in our positioning

strategy.
Rationale: Economic studies fundamentals.
Implications: Perform market research, etc.
Cluster: WE DELIVER GREEN STATISTICS.
Rationale: - We deliver what we promise.

- The services we deliver are market-conform.
- We can make the services we contract.
- We make the services at acceptable cost levels.
- We deliver at least at competitor levels.
- We deliver at higher level than market at SPL.
Implications: To be inserted.
Cluster: E&RM: Margins above general cargo margins; in line with or higher
than other PMG.
Rationale: Justify higher costs / fte.
Implications: To be inserted.
If we look at the principles in the AL business architecture, one could argue that some of them
are rather trivial, e.g. we only service customers who pay their bill. However, it is not without
reason why the AL MT considers this a principle they want to comply to. Apparently in this
31
Everyone that is not a member of the Aerospace Logistics department.
31
case AL keeps servicing customers who don’t pay their bill. One could imagine that doing this
is not good for the business. It is therefore understandable that the AL MT wants to make
clear (on paper as a business principle) that such malpractice has to stop and clearly indicate
the way to achieve this as implications for the principle.
Another act in the development of the AL business architecture was to check how it is related
to the General Cargo business architecture. Because as a company part of AF-KL Cargo the
two architectures should be consistent with each other, or at least no major contradictions
should be present.
The comparison I did was between the customer domains of the AL business architecture and
the General Cargo business architecture, because at the time only the customer domain for
the GC business architecture [4] had been fully developed. The result of this comparison was
that I didn’t find any inconsistencies between the two architectures.
The difference between the two lies in the focus and consequently in the principle
formulations; at AL the focus and formulations are more specific whereas at GC they are
more general. As an example, in the AL business architecture we can notice a clear
distinction between the three classes of customers AL considers, namely: E&M, forwarders
and shippers. This distinction is noticeable in the formulations of all the principle elements.
For GC the customers are per definition forwarders.
The reason for this might be related to the fact that the AL business architecture was devised
by the decision makers of AL themselves; the AL director can be considered the owner of the
AL business architecture. Thus it was “safe” there to be right to the point in the principle
formulations. On the other side, the customer domain of the GC business architecture was
devised by the Cargo CSO management, and because this architecture concerns the whole
AF-KL Cargo organization, the principle statements there are stated in a more general form.
Also if the owner of the GC architecture, if we consider this to be the GC chairman, was to be
involved in the development the principles might have been more specific, because then you
are sure that the devised principles are true and thus safe to elaborate them in more detail.
Another comparison activity I performed concerned the consistency check between the AL
business architecture and AL’s strategy documents (Blueprint, Huizen presentation, etc.).
This activity was also a request from the AL director towards me at the end of the last
workshop. He wanted to make certain that nothing in the strategy is overlooked that should
have been in the business architecture.
What I have found from this last comparison was that the strategy elements are all well
covered in the devised business architecture. The emphasis in those strategy documents was
laid in the synergy between AL and GC which we can clearly recognize in the architecture.
Also the customer focus on jewels and E&M is reflected back in the architecture.
Nevertheless, I did observe that in the business architecture emphasis is laid on the two main
differentiating AL products AOG and Engine, but I couldn’t directly uncover this aspect back in
the strategy documents. The same could be said for the specific knowledge (aerospace
market and customs handling) AL possess and wants to distinguish itself with. In reaction to
this finding the AL MT responded that in the Blueprint there is something said about with
which type of cargo the highest margin is made, which then can be deduced to the AOG and
Engine products.
My personal opinion on the matter is that I find it rather strange that such important strategic
points weren’t stated more explicitly. However, I do agree that ultimately we have this all
covered in the business architecture. Thus the conclusion here is that the devised AL
business architecture can be considered complete and consistent.
32
3.3.3. EA development evaluation
In this section I will reflect on the EA development trajectory and discuss what particularly
caught my attention in the process.
Starting with the process of raising the EA awareness, I noticed that using simple examples in
explanations is the key to achieve understanding on the subject. It helps in visualizing and
recognizing the matter which ultimately leads to understanding and acceptance.
Along with using examples it is important to adapt yourself in the interests of your
conversational partner. If you can relate his work with what you are trying to explain the
message will go through a lot easier.
I also noticed that regular meetings with the key persons about anything (e.g. devised
models/principles, evaluate those models, ask for advice/opinion, request for information,
etc.) contributes in raising or keeping the awareness. This will ensure that your explanations
on those difficult matters like EA won’t fade away, just because seeing you again reminds
them of it.
My first remark on the process of devising the AL business architecture is that it went
surprisingly well. Especially if we consider that such initiative has never been done before in
the business and can be considered pioneer’s work requiring a learn by doing approach.
Next to the achieved EA awareness, the GDT was also for a big part responsible for this
success. The GDT provided good support during the workshops enabling the process to go
very smoothly. In fact the tool was so appreciated that it is handed over to the BDO for further
development and exploitation. Another reason I believe contributed to the smooth workshop
progress was that I facilitated the workshop with the help of a partner. This way I can focus on
the participants while my partner operates the GDT.
One of the most valued aspects of the architectural approach I received from the business
was that the method forces you to (re)think about the company’s direction (strategy) and
explicitly put it on paper making it necessary to formulate each strategic point in an
unambiguous and specific way. This instead of having those rather vague ideas about the
strategy in the back of one’s head making it prone to misinterpretations.
Another thing that caught my attention was that in the architecturing sessions with the AL MT
the presence of the AL director, Kees Buitelaar, is of utmost importance. Ultimately it is Kees
who determines if a devised principle fits in the AL strategy. This is reflected back in the
sessions; he was the one leading almost all the discussions.
When devising the business principles an often heard comment is that a business decision
(e.g. how to approach customers) depends on several factors that cannot be formulated in
one principle statement belonging to one certain business domain. People got the
misconception that when they are asked to formulate a principle on e.g. how to approach
customers, they have to incorporate all the dependencies in a single principle statement. In
this situation it is the responsibility of the architect to explain that it is very well possible and
often even the case that for one business decision several principles are concerned. Each of
these principles has a different focus but have to be regarded all together in making the
business decision. Therefore several principles will have to be devised to cover the guidance
on that particular business decision.
I found the atmosphere during the sessions very pleasant; it was very loose and often small
jokes were made in between discussions which kept everything lively. The participants were
also very enthusiastic and willing to make an effort in getting a proper result from the
sessions. This is certainly reflected back in the amount of time spent in devising the AL
business architecture. The manner how the follow-up sessions were planned was also
something unprecedented. A session was planned in the short term (3 days max. in between)
every time we couldn’t finish the matter. This is something quite remarkable, especially
considering how hard it is to make an appointment with the complete AL MT present.
33
A suggestion I got from one of the AL MT members was that in order to avoid participants
taking longer breaks by engaging into conversations with other employees at the department
and doing other things an idea is to have such sessions at a remote location where
participants are shielded from such distractions (e.g. room at different department, etc.).
3.4. Aerospace Logistics process modelling

A part of my thesis project concerns the AL process model. The reason behind this was that
whilst one of my project objectives was to make a comparison between GC and AL on the
strategic (architectural) level, taking along the process level in the comparison will add even
more substance and value. This was especially encouraged because at the time a project
about modelling the AL processes was already on the agenda and thus the timing couldn’t be
better. Concretely this meant that a process model for AL was a deliverable in my project and
also the comparison of the model with that of General Cargo’s.
3.4.1. Pre-study
In the analysis report I have already paid a substantial amount of attention to the process
models that can be found at AF-KL Cargo, these are the Cargo Process Model (CPM) and for
AL specific the Air Transport Interface Process Model (ATI-PM). The overall conclusion was
that both models were incomplete, inconsistent, not up-to-date, rarely used and not easy
understandable, with a remark that the ATI-PM was at worse shape than the CPM.
Nevertheless, studying the models did help in understanding the AF-KL Cargo business and
operations which I can consequently use in the process modelling part of my project.
Considering the current shape of the ATI-PM it seemed better for me to start modelling the AL
business processes from scratch and use the ATI-PM as information source rather than a
model to work from. As one could imagine a proper business process model cannot be
devised with just the information deduced from the ATI-PM. Thus I started with interviewing
the members of the AL-MT to first get a good overall picture on the business of AL. With each
AL-MT member having a specific function and domain, I was able to inform myself on all the
aspects in the business of AL.
Through consultation with my supervisors at AF-KL Cargo and the person responsible for the
AL process analysis, Roland Spijker, we decided that I will be modelling the Order to Cash
(O2C) process. The O2C process represents the entire process from taking an order from a
customer through providing customer service to eventually bill and collecting the customer.
This process is mainly interesting to model because at AL quite some issues exits within this
particular process, as already mentioned in the EA development section. It was therefore a
good idea to analyze that part of the AL process model in detail.
I also reported that I participated in the workshop that concerned the main AL application
Scarlos in order to get the details on the order management process at AL. Next to this I
tagged along with the operational staff at AL for a day. This gave me very specific information
32
on how the workflow goes at Operations because I was experiencing the process first hand .
With all the gathered information I started modelling the O2C process in Protos Enterprise33
with the Petri-Net methodology [28]; this was the commonly accepted AF-KL Cargo way to
model processes. The results from this Protos modelling will be presented hereafter along
with my final results of the AL process model.
32
A description of the O2C process at AL is provided in appendix B.
33
A process modeling application.
34
3.4.2. Devising the AL process model
The Protos models34 were devised in compliance with the guidelines set by AF-KL Cargo [29].
These guidelines mainly regard the form aspect, e.g. how to model an OR situation, while a
sound theory or foundation is lacking. Furthermore, a derived form of Petri-Net is adopted and
therefore not all of its mathematical properties are still guaranteed. Amongst other things this
might also have contributed to the current shape of the CPM and ATI-PM.
During modelling I encountered several issues that made me feel rather uncomfortable and
made me question the current approach that I had taken. If we look at the Protos models, the
level structure makes the interrelationships between the activities hard to identify. For
instance, in the case where an activity at one level has to wait for input from an activity at a
higher level. Even though there is an option in the application to declare relationships, one
cannot directly identify them from the models. On account of the same reason it will be very
difficult to properly and accurately keep track on the effects from a redesign action. The risk
for inconsistency in the model would be considerable, especially if it concerns a large
35
model .
Regarding the level structure in Protos where one can zoom in to an activity to view its sub-
activities, no uniform guidelines are defined that indicates to which level of detail one has to
classify the activities. This is reflected back in my devised models where I unconsciously
modelled two similar activities, namely “handle import customs clearance” and “handle export
customs clearance”, in different levels of detail. The criteria I applied here was that handling
the import customs required the AL employee to perform certain activities, which I modelled,
while at the export side, the AL employee hardly had to perform any tasks for it other than
checking the information on the AWB, which I didn’t find necessary to classify as a sub-
activity. This issue I found the most bothersome and confusing.
Another thing was that I didn’t get the feeling that the Protos models completely covered all
the aspects of the order management process. I also didn’t think this issue could be solved
with the current approach. A more appropriate approach would be DEMO which describes an
organization on the ontological level [8]. With the experience I had with DEMO at the DUT it
then was a small step to throw the current approach overboard and start afresh using DEMO.
This decision was made with consent of my supervisors and people involved in the AL
process analysis.
AL DEMO models
With the information I have already gathered so far I devised a set of initial DEMO models for
the AL organization, namely the Interaction Model and the Process Model36. The intention
was to gradually develop these models by reviewing them with each of the AL MT members.
It came to my attention that DEMO models are rather hard to understand if the person does
not have the knowledge of the theory behind the methodology. That’s why in the meetings I
start with an extensive explanation on the DEMO axioms before going into the actual models.
Much like explaining what EA is all about; using simple examples and analogies helps greatly
in getting the message through.
Eventually the initial DEMO models evolved incrementally into the final models found in
appendix B. During each of the review meetings with an AL MT member, the models were
checked for correctness and completeness. This was best done by directly asking questions
like “is there something missing in this model according to you?”. With such questions one
forces the opposite party to seriously think about the model and get his involvement in the
process which ultimately will result in a better understanding of the models and better quality
models. From the feedback of the AL MT member adjustments were then made where
needed.
34
See appendix H.
35
Taking the CPM as reference, a complete AL process model in Protos could be considered large.
36
The final DEMO modeling results elaborated in accordance to the procedure described in the book Enterprise
Ontology by Jan Dietz are presented in appendix B.
35
In the end each and every member of the AL MT understood the value of the DEMO models
over the traditional workflow models. Commitments and models on the ontological level
independent from the implementation are things that should appeal to managers; after all
that’s what doing business and running the business is all about. The AL MT members
especially appreciated the fact that the essence of their organization is captured in one model
that fits on one A4 size paper, see figure 8.
Aerospace
make customer make supplier

agreement contract
A03:
CA01 T03 T04 CA02
Service
Developer
transport/customs
advice
A09:
T09 Transport
Advisor supplier
payment
A07:
Supplier T07 Supplier
customer Handler
invoicing
Customer T06
transport *2* transport

shipment shipment
A01:
T01 Shipment T02
Handler
handle
complaint/claim
A08:
Complaint & customs
T08 CA03
Claims handling
Handler
Regulatory
T05
Bodies
Figure 8: Complete Detailed ATD of Aerospace Logistics.
As already stated at the beginning of this chapter one of the intentions for modelling the AL
processes was to identify which processes at AL are compulsory for its department and which
are similar to the processes at General Cargo. The result of such an analysis has several
benefits next to the purpose of DEMO itself as the starting point for business change
37
initiatives . First, it will make clear what the differences and also what the similarities are
between AL and GC. This will help in the discussion of whether or not AL indeed belongs at
Cargo instead of at E&M. Second, DEMO models can be perfectly used to explain to the
outside38 what exactly AL stands for and what its business is without going into the
operational details. This transparency is needed because in the past (and maybe currently
still is) people didn’t really understand what exactly AL is doing. Third, the comparison result
can contribute in finding synergy opportunities between AL and GC (or maybe even between
KLM and Air France), business-wise, process-wise and application-wise.
Although it requires the complete DEMO models to give a justified evaluation for our
comparison, we could very well give a first assessment on the AL – GC comparison with the
current models at hand. Basing on the knowledge of AL MT members on both the AL
business itself and the GC business, I asked each member where (which transactions) they
see similarities and differences. All members unanimously pointed out that the transactions
T05: customs handling and T09: transport/customs advice are transactions distinctive for AL.
37
See appendix E for further substantiation.
38
Everyone that is not a member of the Aerospace Logistics department.
36
Although it must be mentioned that GC also does some customs handling. However customs
39
and CBS declaration/clearance activities belong to the business of AL.
So as we can see AL has quite some similarities with GC; GC either also has the same
transaction type or is involved in it (GC acting as the supplier role CA02). However, we must
be aware of the fact that this doesn’t mean that the AL transactions can just be merged with
the corresponding transactions at GC and thus e.g. cut off employees and/or migrate to GC
applications. As mentioned before, for such an evaluation further elaboration and study on
both the AL and GC processes are required. At this point we can only say that at certain
transactions there is a good possibility to seek for synergy opportunities.
3.4.3. Process modelling evaluation
In this section I will reflect on the process modelling trajectory and discuss what particularly
caught my attention in the course of development.
The first thing I would like to mention is that this process modelling affair went parallel with the
EA trajectory. In between my efforts to raise the EA awareness of the AL MT, I also kept
myself busy with developing the AL process models. In fact, just after I did my EA awareness
presentation with the pizzerias, I started my meetings with each of the AL MT members one
by one to review the DEMO models. I believe that these meetings also contributed in
maintaining the attained EA awareness because of the exact same reason I gave in the EA
development evaluation section; they keep previous events, in this case: the presentation,
alive. This remark also goes for the weekly meetings I had with one of the AL MT members
Roland Spijker where we discuss the progress and results of the process modelling project.
From the meetings with the AL MT members regarding DEMO I observed that it is still hard
for some members to do the paradigm workflow to transactions switch, this is especially hard
for the members that are in any way involved in process modelling. This might have to do with
that people are more familiar with the traditional workflow-like models and that those models
in general require little explanation to read and understand. This is of course strengthened by
the fact that people have already gotten used to such models in contrary to DEMO models.
DEMO models are a lot harder to understand without the proper explanation. Here again we
could reason that it is because people have never heard and seen the DEMO modelling
approach before. However, with a proper explanation of the DEMO ideas and axioms, people
(in particular managers) do recognize their business in the models and realize that modelling
as such could prove useful in designing their organization.
One matter that comes up often during the process modelling trajectory regards the question
how the DEMO models relate to EA and related to this question, how the DEMO models
relate to workflow models. In answering these questions I make use of a document that I have
included in appendix E. There we can notice that simple examples are used in the
explanations. Once again, simple and practical examples help a lot in getting your message
through. Basically, it is a misconception that DEMO models are redundant to Protos models.
It is not true that one excludes the other. In my perception I see the link between the two
types of models as the DEMO models serving as a rack for the workflow models (or quality
systems) to be put on, i.e. further elaborating the Action Model with workflow models attached
to it. Thus one can consider the DEMO models as the highest level process model (ontology)
and the lower level workflow models as how those processes are realized. This way a solid
structure and a clear separation of detail level (DEMO as implementation independent and
workflows as the implementation of the processes) are guaranteed.
The current state of affairs regarding DEMO is that both the BDO and AL are interested in its
continuation. After all, not all the DEMO models were in the scope of my thesis project, just
40
the Interaction Model and Process Model . In fact, plans for the continuation are already
taking shape; two AL members who are involved in the process modelling are going to follow
39
Statistics Netherlands, packages going in and out of the Netherlands have to be recorded by the CBS.
40
I also elaborated a small part of the Action Model.
37
a course on DEMO. Not only to familiarize themselves with DEMO so that they can work with
it, but also to see how exactly DEMO fits in their AL process (workflow) modelling project. And
just like the case with the continuation of EA, a role for myself in this process was considered
a possibility and will be discussed in a later stadium.
38
4. Discussion and recommendations

In this chapter I will first present some remarks that caught my attention but haven’t been
incorporated in the sections above. Next I will discuss how I experienced this whole
architecturing process and its most important learning points. And last I will give my
recommendation on the follow-up steps.
4.1. Remarks
The first remark I would like to point out regards the Enterprise Architecture maturity at AF-KL
Cargo and in particular at AL. As mentioned earlier, before my internship at AF-KL Cargo the
EA maturity at the IT side was already very sophisticated. This is reflected back at their way
of working conforming the Stemband. However, at the AL business/management side it was
not so promising. In fact one could consider that there was no EA awareness at all. Now, a
short seven months later, a safe conclusion could be made that within KLM Cargo, AL is the
furthest in the EA program.
To substantiate the progress we could apply an Enterprise Architecture Maturity Model

(EAMM). Many such models can be found in the literature nowadays which is undoubtedly
related to the hype around the term architecture; everything tends to be denominated as
41
architecture for all the wrong reasons . However, as most of the EAMMs are based on the
well-known Capability Maturity Model Integration (CMMI) [30], they seem to be rather similar
in essence. I have chosen for the NASCIO EAMM [31] in the evaluation of the EA program at
AL because of its clarity and applicability.
Following the CMMI concept the NASCIO EAMM also distinguishes five levels for an EA
maturity, depicted in the figure 9 below. The levels are labelled from 0 to 5 as: no program,
informal program, repeatable program, well-defined program, managed program and
continuously improving vital program.
Figure 9: Enterprise Architecture Maturity Model levels.
Each level contains statements that are indicative of an EA program at that level. These
statements have been organised into the following EA categories:
• Administration – Governance Roles & Responsibilities

• Planning – EA program road map and implementation plan
41
Further discussions on the matters around the term architecture are left outside of this report to avoid straying off
the report’s original topic.
39
• Framework – processes and templates used for Enterprise Architecture

• Blueprint – collection of the actual standards and specifications
• Communication –education and distribution of EA and Blueprint detail
• Compliance – adherence to published standards, processes and other EA elements,
and the processes to document and track variances from those standards
• Integration – touch-points of management processes to the EA
• Involvement – support of the EA Program throughout the organization
As one might have expected the initial maturity at AL would be classified at the level 0 (no
program). Nothing has been devised for each of the EA categories. For the current maturity at
AL the level of 2 (repeatable program) would be justified. The level 2 statements for each
category are presented below and argumentation for each of these statements can be
deduced from the discussions described in this report.
Administration
• A need for Architecture Governance has been identified.
• EA Program has begun to develop clear roles and responsibilities.
• Governance committees are starting to form.
Planning
• The organization has begun to develop a vision for Enterprise Architecture.
• Organization has begun to identify EA tasks, and resource requirements.
• Organization has decided on a methodology and begun to develop a plan for their EA
Program.
Framework
• The basic EA Program is documented.
• Processes are planned and tracked.
• The organization is beginning to reuse methods for capturing critical EA information.
Blueprint
• Business Drivers and strategic information have been identified.
• The need for an EA repository for storage and dissemination of the captured EA.
information has been identified.
Communication
• The need for Enterprise Architecture is being communicated to Senior Management.
• EA awareness activities are beginning to emerge or be developed.
Compliance
• The organization has begun to develop a compliance process to ensure that projects
and enhancements are consistent with EA standards.
Integration
• The need for integration to the EA Program Framework (Architecture Lifecycle
Processes) has been identified.
• The various touch-points between the Management Processes and the EA Program
Framework have been mapped (however, no details exist as to how the integration
will work).
Involvement
• The organization has begun to develop plans for EA educational sessions and
materials to increase the awareness and understanding of the EA concepts and
processes.
• EA concepts are beginning to be introduced and more consistently discussed in
normal day-to-day meetings.
40
As regard to the involvement category, which is closely related to the state of the EA
awareness, we might even conclude that AL is at level 3, see the level 3 involvement
statements below.
Involvement
• The organization begins to operate as a team, using the defined architecture program
and standards.
• Senior Management participates in various EA committees.
• Business and technical staff participate in EA committees.
The main question is now how to further mature the AL organization to level 3 (well-defined
program). The step from level 2 to 3 is quite a big one, because in a well-defined program a
complete EA has to be in place and used in organization (re)design initiatives. Furthermore,
the EA governance aspect has to be defined already as well. In my recommendations I will
discuss what next steps have to be taken first in order to mature towards a well-defined
program.
The next remark regards the involvement of Air France in this EA program. Up until now the
initiative to work under architecture is something from KLM. However, it seems that AF is
leading in the AF-KL alliance. For that reason AF has to be taken along in initiatives that aim
to structure the way of working of the whole enterprise. This doesn’t mean that AF has to
participate in the development, but they do have to be informed to avoid future conflicts. Who
knows maybe synergy opportunities with the French are possible in this matter when they like
the idea of working under architecture.
I would then like to stress that EA must not be seen as a panacea [32]. A very appropriate
statement from Gartner is at place here: EA won’t work if it is not used. Although very evident,
the statement is so very true. It’s about people getting aware of that the current way of
working is no longer viable to survive in the business and remain competitive. Continuity and
constantly looking for ways to improve one’s business is necessary. For that agility and
integration between every aspect of the organization is mandatory. A method to realize this is
working under architecture.
The last remark I would like to mention here is that it amazes me that even though almost
everyone agrees that Scarlos has to be phased out due to inadequate support to the business
in today’s standards, it is still the crucial application for AL on the present day. In fact currently
a technical update on Scarlos is in full execution.
4.2. Experiences and learning points

First and foremost, I would consider the hands-on experience of actually putting the theory on
EA into practice to be the most valuable learning point from the project. It has been a
challenge to figure out how the process of devising an EA purely base on principles could be
implemented such that it is successful. Successful meaning that working under architecture is
accepted as a method that helps in aligning the business with IT and that eventually
enterprise engineering is implemented by means of EA. Furthermore, many aspects and
issues regarding EA discussed in literature, such as business politics, organization’s history,
human measure, difference between principle and requirement, etc, will only be properly
assessed when one actually touches upon them in practice.
Regarding my expectation on the project, I could say that before I came to AF-KL Cargo I
thought that the architectural thinking was already well embedded in the organization. As I
have already mentioned, I formed this impression through presentations at the DUT regarding
EA at AF-KL Cargo and also through statements regarding the same topic from our professor
Jan Dietz [9]. This impression was soon to be nullified after my introduction meeting with the
AL MT because the term EA seemed to be totally strange to them.
41
Additionally, after several weeks in which I got to know the history of AL, especially about the
relation between AL and GC/BDO Cargo, I began to realize that it could be rather difficult to
push the architectural thinking through in the AL organization, let alone making a proper EA
for AL. I didn’t anticipate that the EA awareness at AL wasn’t there. My initial thought on my
thesis project was that with a solid foundation already in place I could go directly into the
development of an EA.
Nevertheless, with regard to the booked progress in the AL architecture program and its result
in the form of the AL business architecture, I would consider the project as a success.
Especially if the deliverables defined in the project proposal are taken along in this evaluation;
except for one, all of them have been met. Mainly due to the sudden deadline shift for the
project from November 30th to mid October, the deliverable AL Organizational Architecture
focused on the processes domain couldn’t be accomplished. Furthermore, the AL
organization can now be regarded as the front-runner in applying EA at the business side.
The same holds for the process modelling part in DEMO; within AF-KL Cargo the
methodology is first applied at AL.
One thing I learned during the workshops for devising the AL business architecture is that it is
crucial to have the right group for the sessions [33, 34, 35]. The group must consist of the
people that are responsible for making the principle decisions in the business domains. Even
though such group is usually equivalent with the users of the business architecture, this
doesn’t have to be always the case. The business architecture has to be verified with the
decision makers and its owner in order to “declare” the devised principles true. At AL this
group is simple because the AL MT meets all the requirements.
Another thing I observed was that the discussion about which direction the organization
should be going is not something that is only recognized at AL. This discussion is recognized
in almost every organization and is also the main cause for the high percentage of strategy
implementation failures [2]. I believe that EA could play an important role in the solution for
this matter which is partly substantiated by this project.
Something I experienced that worked very well in the development of an EA is to have it done
through workshops. Devising an EA is a group effort with a lot of discussions involved. A
setup like I have discussed in the development chapter is a way that has been evaluated
positively by the participants. Especially the GDT that had been used in the sessions was a
success.
I also learned what helps in getting your message through when you try to explain (new)
things. Next to backing your story up with simple and practical examples, you need to speak
the language of your conversational partner. You must figure out what his (work) interests and
function within the organization are in order to relate your story to that person and to make it
appealing to him. It is also important to feel if the other person is ready to get a little bit deeper
into the theory every time you want to further explain your story to avoid him getting lost in it.
In this way explaining serious matters like EA or DEMO has a lot in common with being a
door to door salesman who is trying to sell a top of the notch vacuum cleaner that will change
the vacuuming experience of every household.
One thing that I had to bear in mind during my project was that the people at AL weren’t
waiting for a student from the DUT to help them in their strategic alignment. Therefore I had to
take an active attitude if I were to accomplish something in my project.
The last statement I would like to mention about my experience at AF-KL Cargo is that it is
quite hard to arrange a meeting with a big group on a date that is favourable for each required
attendant. Luckily in my case the meeting requests worked out quite well, but it always
involved some heavy email traffic and rescheduling of the agendas. What does work here is
to plan the meeting when all the attendants are present on the spot. The reasons for this, if
there are any, aren’t things I concerned myself about in this report.
42
4.3. Recommendations
The first recommendation is to maintain the created awareness on EA and also on the
process modelling method. At the moment there is momentum to pursue a higher EA maturity
or at least efforts must be made to maintain the current status. It must be avoided that the
architectural thinking fades away by time. Therefore this new way of working should be
communicated to senior management in order to gain their support.
Following the first recommendation, continuing the path in the current set architecture
program will evidently contribute in maturing the organization. Now that we have made the
essential steps in making the business architecture for AL, initiatives to devise the other
architectures in order to have a complete EA, namely the organizational and information,
must be sought after.
In the spirit of completing things the next recommendation is to complete the DEMO models.
While I have devised a good part of the DEMO models for AL, the rest of the models should
also be completed. In appendix E this recommendation is elaborated in more detail.
EA must also be made into practice to show its relevance and benefits. Even though the
complete AL EA has not been devised yet, we do have the AL business architecture. With this
architecture the current project portfolio can be evaluated. Such evaluation can show if the
current projects comply with the strategy of AL and consequently discover business
opportunities in cases of non-compliance. In this way a better reasoned project portfolio for
the next years could be formed.
Next to the practical relevance of EA, that of DEMO must also be shown. This is discussed in
detail in appendix E. In the chapter about DEMO I have already stated briefly that the
practical link can be found by attaching workflow models or quality systems to the DEMO
Action Model.
The last recommendation regards the lack of communication and synchronization of

projects/initiatives between the departments within AF-KL Cargo (e.g. AL, Mail, GC, Equation,
etc.). This could lead to missed opportunities in cost savings (avoid doing repeated work,
missed reuse of knowledge and experience, etc.) and synergy advantages. For example a
new hub application is about to be implemented at KLM Cargo. However, there is little to no
knowledge about this new project at AL. Even though it may seem like that the project doesn’t
have much to do with AL, it is premature to conclude that no synergy opportunities is possible
here without consulting the higher management at AL. It may happen that the AL
management with a more business perspective sees some potential in the matter for their
business which hasn’t been thought of by the BDO or IS that looked at the matter with an IT
perspective. It is therefore my recommendation to periodically update the MTs of the
departments on the current state of affairs regarding new projects and initiatives. A brief
general description of the project and its goals during MT meetings should suffice. Below the
recommendations are summarized in a table.
Recommendations
1 Continue raising/maintain awareness on EA and DEMO.
2 Devise the AL organizational and information architecture.
3 Complete the AL DEMO models.
4 Evaluate the project portfolio with the AL business architecture.
5 Realize the link between DEMO models and workflow models or quality systems.
6 Realize better communication of projects/initiatives between departments.

Table 2: Summary of recommendations.
43
5. Conclusion
The first two sub problems defined in the introduction regard how to retrieve the enterprise
objectives and best practices. It is obvious that the first thing to do here is to deduce the
information from the organization’s strategic documents. However, at AF-KL Cargo almost all
documentation is presented in presentation slides format which makes it difficult to extract the
correct information without risking misinterpretation in the process. Additionally, it is common
that one can only find generic strategic statements, such as increase profitability, in those
documents which doesn’t help much because it can be interpreted in too many ways.
Therefore from my experience studying the strategic documents alone is not sufficient.
The next method I then took on is to interview key persons who are involved in the strategy
making. This proved to be a more effective method because this way I could get specific
information about the strategy and I could also find out if there are different views on the
strategy by the different persons.
Although interviewing is a good method to retrieve the enterprise objectives and best
practices, the method that was used in this project that had the most value must have been
the workshops. One must understand that the goal is to figure out a common understanding
amongst the decision makers as to which direction the organization wants to go. For this
strategic alignment to happen it is unavoidable to have a group discussion on the matter.
However, with undirected discussions one still wouldn’t be able to accomplish this. The
suggested method to structure such discussions can be found in Enterprise Architecture. With
a solid business architecture framework in which the essential business domains are
organized, the topics for the discussions can be identified in order to devise the organization’s
business principles. These principles represent a shared understanding on what needs to
happen if an enterprise wants to execute its strategy successfully.
The next sub problem regards how the principles should be formulated such that they are
applicable for the designers. Adopting the KLM template for architecture domain principles, a
principle should consist of four elements (principle statement, rationale, implications and key
actions). It is the element principle statement that stands out from the rest and because of this
the statement must be formulated such that the focus of the principle is clear to everyone.
Furthermore, a principle must reflect a choice made in advance. The conditions and effects of
the principle are elaborated in the principle elements rationale and implications.
Closely related to the formulation of a principle are its acceptance and its correctness. If there
is no support for the principle, it is likely that it won’t be used. Evidently the principle must also
be correct to be of any use at all. The acceptance of principles is best achieved by involving
the users and decision makers in the development. To ensure the correctness of principles
they have to be verified and a proper architecture governance process must be set up.
The last sub problem regards how the principles should be organized. In this project I have
adopted a business architecture framework, see figure 4, which is derived from Hedman and
Kalling’s business model and Hoogervorst’s Business Architecture Framework, to organize
the principles in business domains. The framework provides the context in which the business
principles must be used and consequently be organized to improve the manageability.
Now to answer the problem thesis, presented once more below.
The answer to this problem can be summarized with the path that has been taken in the
architecture program in the project. The first and most important step is to raise the EA
awareness to a point where everyone of the AL MT knows what EA is, understands what EA
could mean for their organization and is willing to participate in the development of the EA.
44
Efforts to raise this EA awareness include having individual meetings with each of the MT
members where the concept of EA is explained. But the required level of EA awareness was
finally achieved by a presentation for the AL MT in which an EA for a pizzeria was fully
elaborated. With such a simple and recognizable example the MT members were able to
visualize what EA is all about.
The next step in the architecture program is then the actual devising of the architecture. This
has been done in the form of workshops with the AL MT. The workshop starts with the
participants individually generating principles. This activity can be compared with
brainstorming but here it is supported by a Group Decision Tool which made the process
much more effective and efficient. The devised principles are then discussed in the group
where it is determined whether or not the principle in question is indeed a principle for AL. If
so, the principle will be further elaborated and included with its implications. The result of the
workshops is a first version of a complete AL business architecture.
This first version will then have to be reviewed to make sure that the principles are correct,
complete and consistent. This is best done in a separate meeting because in workshops a
clear overview of the whole business architecture is lacking.
Thus above is described a way to capture the AL strategy and best practices in an EA. Bear
in mind that this was a learn by doing project simply because it has never been done before.
Considering this fact, the booked progress in the AL architecture program, its result in the
form of the AL business architecture, the plans for continuing the program and the positive
feedback from all the people involved, one could carefully consider the applied method to be
a correct one or at least a method that has been proven to work.
Next to the success in the EA part of the project, successes in the process modelling part
have also been booked. DEMO is first applied at AL in modelling their business processes
and plans to complete the DEMO models that were out of the scope of my project are taking
concrete shape as well.
45
Appendix A: Aerospace Logistics business

architecture
For internal use only.
46
Appendix B: Aerospace Logistics DEMO models

47
Appendix C: EA awareness presentation
• One of the most important aspects of Enterprise Architecture is the fact that it is valuable
for the strategy implementation.
• In the strategy there are usually statements such as “increase profitability” and “realize
growth”. Very generic and ambiguous.
• For instance, realize growth; one person might consider something different as growth
than another person. If this isn’t made explicitly clear, both persons would think they’re
talking about the same thing, which eventually could lead to problems.
• To avoid this from happening and to have everyone pointing their noses in the same
direction, the strategy has to be clarified and more concrete. Enterprise Architecture (EA)
can help us with this.
48
• EA can be seen as an elaboration of the chosen strategy. Put differently, it specifies the
framework within which you can realize your vision.
• In practice, EA consist of principles and guidelines.
• Principles that are developed from the strategy and which have to be used to realize your
business.
• This will ensure that, for instance, the applications you are building are aligned with your
strategy and the business.
• The next question would be: what does an EA look like?
• EA consist of four domains.

• Every domain only consists of principles regarding that domain.
• The layered structure shows that from the strategy, business principles are devised,
which in turn have consequences for the organizational principles, etc.
• While devising principles, it is important to keep in mind that all principles have to be
consistent with all other principles.
49
• The example of a pizzeria presented on this and the following slides should give an idea
of how an Enterprise Architecture could look like.
• As mentioned before, the strategy can be interpreted and realized in various ways. This
can be illustrated by 2 different pizzeria’s that have the same strategy, but work according
to different principles.
• In the business domain, it’s about how to approach your field of commercial endeavor. In
short, what you want to do to realize your vision.
• Focus areas in this domain are for example, Products and Services, the Revenue Model
and Customers.
50
• As you can see, two totally different approaches are used in realizing the exact same
strategy. Mario wants to achieve his goal by offering high quality products and services.
Luigi wants to accomplish his goal by offering pizza’s cheap.
• By explicitly stating their principles, the difference is made clear.
• In practice, both Mario and Luigi have organizational, informational and technical
principles.
• For the example, only business principles of both pizzerias are presented.
• In the organizational domain, it’s about how the business should be organized.
• Focus areas in this domain are for example, Management, Competences and Processes.
51
• The information domain concerns how information has to be managed.

• Focus areas are e.g. the presentation of information, information quality and exploration
of information.
• In the technical domain its about how technology should be used to support the chosen
strategy.
• CIO/IS is already using such an architecture to prescribe how IT should be used.
• Focus areas are e.g. Data warehouse, information security, etc.
• There is little IT in our pizzeria example. Nevertheless, technology goes beyond IT, such
as ovens, tables, buildings etc.
• The principles in the architectural domains ensure that the enterprise is designed as a
whole according to your strategy.
52
53
Appendix D: Workshop preparation material
Workshop purpose
This workshop is intended to identify principles with which Aerospace should approach its
commercial terrain. Thus what we must do to realize our vision. These principles together will
form the business architecture that enables Aerospace to better determine how the strategy
should be implemented.
Workshop procedure and agenda

For this workshop each member is requested to bring their laptop along with them. This is
because the workshop will make use of a Group Decision Tool (GDT) which is implemented
in the form of a website http://afklcargoworkshop.awardspace.com . The GDT is similar to the
so-called “geeltjes-sessie” where participants write down their input on post-its.
The agenda is as follows:
• Introduction (30 min) 09.00 – 09.30

• Generate principles [1] (30 min) 09.30 – 10.00
• Break (15 min) 10.00 – 10.15
• Generate principles [2] (30 min) 10.15 – 10.45
• Introduction to discussion (15 min) 10.45 – 11.00
• Discuss principles [1] (60 min) 11.00 – 12.00
• Lunch (30 min) 12.00 – 12.30
• Discuss principles [2] (120 min) 12.30 – 14.30
• Review and closure (20 min) 14.30 – 14.50
When generating principles each participant will be able to individually input their principles
via the website in a free-format way. After this, the generated principles will be discussed in
the group and at the same time further elaborated. In the end we will have a set of business
principles that forms the Aerospace business architecture.
54

We will make use of the following framework to work out the business architecture.
Business
Trends
Strategy
Economic & Revenue Model Competitors Vision
Products & Services Customers
Key Resources & Assets Partners & Suppliers
Best Practices
...
Here & Now
Figure 1: Business Architecture Framework.
So the strategy, business trends, vision, best practices, here & now, etc. form the factors we
need to take into account when developing the business architecture. The following business
domains will then need to be considered when determining how to approach our commercial
terrain.
For each domain questions are stated to help in generating principles.
Customers
Hoe werven/benaderen we potentiële klanten?
Hoe behouden/verbeteren we de bestaande klanten?
Hoe moeten we ons naar de klanten presenteren?
Hoe moet de communicatie geregeld worden met de klanten?
Etc.
Competitors
Hoe moeten we omgaan met onze concurrenten? Wat is de relatie?
Hoe positioneren we ons op de markt? (lead, smart follower, …)
Etc.
55
Products & Services

Hoe moeten we onze producten/services aanbieden? (marketing, direct-sales, etc.)
Hoe moeten we onze producten/services ontwerpen?
Waar moeten onze producten/services aan voldoen?
Etc.
Economic and Revenue Model

Waar zit de focus? Op bestaande klanten of potentiële klanten? Of geen onderscheiding.
Waar moeten we rekening mee houden op het financiële gebied? Op welke manier moeten
we onze inkomsten genereren?
Etc.
Resources & Assets (network, people, capital, etc.)

Hoe moeten we omgaan met onze resources en assets?
Hoe moeten we ze ontwikkelen?
Hoe moeten we ze exploiteren?
Hoe moeten we ze waarborgen?
Etc.
Partners & Suppliers (AFI, G.C., PS, etc.)

Hoe moeten we omgaan met onze partners & suppliers? Wat is de relatie?
Hoe moeten we onze partners & suppliers selecteren?
Hoe moet de communicatie gaan?
Wat verwachten we van onze partners & suppliers? En vice versa?
Etc.
Examples of principles
In order to provide more clarity in what kind of principles we are eventually looking for during
the workshop, a number of examples will be provided. The example of Mario’s Pizzeria in the
Enterprise Architecture Explanation presentation is used to present principles for the
development of their customer relationships.
Example 1:
Customers must be able to communicate with Mario’s Pizzeria in multiple ways.
Rationale:
A backup communication method is necessary to maintain availability.
Different customers have different communication preferences.
Example 2:
Customers must perceive Mario’s Pizzeria as a classy pizzeria.
Rationale:
We want to differentiate ourselves from the cheap pizzerias.
Example 3:
The revenue model must be based on lifetime customer value.
Rationale:
• It is easier and more beneficial (financially) to maintain an existing customer than to
acquire a new one.
56
Appendix E: Enterprise engineering (overview)

In this document an overview is presented to depict and clarify how the notions of Company
Strategy, Enterprise Ontology (in our case DEMO), Enterprise Architecture (EA) and
eventually Application Implementation relate to each other in the overall picture.
Figure 1: Architecture approach.
From figure 1 we can see that at the top level we have the Company Strategy where (generic)
statements about how we wish to achieve our vision are stated. However, in order to come to
a proper strategy implementation, we need something to guide this whole process of
enterprise engineering. Thus, from the strategy, what steps need to be taken to come to
comprehensive, coherent, consistent, and – at the same time – efficient and flexible
organizational designs, such as processes and applications.
Practically, the first step requires us to translate and elaborate the strategy into architectural
principles so that we have an EA.
57
Figure 2: Generic system development process.
Now that we have the EA, we need a fully implementation independent representation of how
our enterprise works and what it stands for. Because only with such a model (say DEMO) we
are able to understand the construction and operation of our enterprise and from there, start
redesign and change initiatives. Without this stepping stone for redesign and change we won’t
be able to know where to redesign or change and also won’t be able to know what to redesign
or change.
In figure 2, this DEMO model can be seen as the ontological model of the US. We can also
see from this picture that the design process ideally starts from the ontological model (again
we can say DEMO) to devise the requirements for an application to support whatever our
enterprise needs. When devising these requirements architectural principles (organization
and information) are used in order to make sure that the requirements fit in the strategy and
thus making sure the application has business value and does what we want (business – ICT
alignment). Bear in mind that at this point we are still not talking about the implementation of
the desired application.
So now we have the application requirements, the next step is to devise the specification or
the implementation model of the application. Here again architectural principles (informational
and technical) will be used to guide this process of devising the specifications. Practically this
means that IS makes the implementation model (say UML models) with the guidance of the
architectural principles. These models will then be further elaborated into i.e. the source code.
Then in the end when the source code is compiled we get the actual application which fits in
the picture as the technology.
So in figure 1 we depicted the first process of how to devise the EA. Then figure 2 depicts the
second process of how to develop systems, in our case how to develop an application. Their
relation is then depicted by how EA must be used in the second process. In figure 3 the
overview of what is described above is depicted.
58
Figure 3: From top to actual application overview.
Practically, for my project it means that after I have devised the Aerospace ATD and PSD, the
remaining DEMO models must be made. This will, as said before, provide the stepping stone
for process and application (re)designs. The business or BDO determines the requirements
for the application through EA and the DEMO models. This way we can make sure our
designs will be aligned with the business. Then these requirements will be passed on to IS for
them to start their software engineering process where they also need to comply with the
applicable architectures, namely the information and technical architectures. For IS the
DEMO models can also serve as the context where their designs must fit into. In the end we
will receive a workable program from IS of which we can be certain that it supports our
business perfectly because it is developed under architecture.
In the table below is shown who is responsible for delivering the products.
products sub-products assigned to

Architecture BA Calvin Lee
OA/processes Calvin Lee
OA/rest <name>
IA <name>
Enterprise Ontology ATD Calvin Lee
PSD – discourse Calvin Lee
PSD + discourse <name>
DEMO/rest <name>
Functional Model List of requirements Business and IM
Software Engineering UML models IS
… IS
Source Code IS
Program Executable IS
59
The following abbreviations have been used in the table:
ATD : Action Transaction Diagram

BA : Business Architecture
DEMO : Design & Engineering Methodology for Organizations
IA : Information Architecture
IM : Information Manager
IS : Information Services
OA : Organization Architecture
PSD : Process Step Diagram
UML : Unified Modelling Language
A more detailed plan on what actions still need to be performed in order to picture the
practical link between DEMO and workflow models (e.g. quality systems and work
instructions) is provided below. In my perception I see this link to be that the DEMO models
will serve as a rack for the workflow models to be put on, i.e. further elaborating the Action
Model with workflow models attached to it. This way a solid structure and a clear separation
of detail level (DEMO as implementation independent and workflows as the implementation of
the processes) are guaranteed.
Essential products:
1. Process Structure Diagram including the discourse steps (PSD with discourse).
2. Action Model (AM).
Non-essential products:
42
The state model (SM), which models all the essential information objects in FCO-IM style,
could be considered non-essential for our purpose. However, including it could be interesting
for the completeness of the devised DEMO models.
Essential Non-essential
PSD with discourse SM
AM
Time required
The required time for the models is dependant on both the knowledge of the Aerospace
Logistics organization and the knowledge on the DEMO modelling method. In this case we
could take myself, Calvin Lee, as a reference point in this scheduling.
For the PSD with discourse model it is just a matter of identifying if at each process step
(request, promise, execute, state and accept) a discourse is applicable and if it should be
included in the process model. In other words, for each case, is there a “negative path”? If so,
do we need to handle it accordingly?
For the AM, detailed information in what actions need to be performed for each process step
is required. I have already made an AM for one transaction (make customer agreement) as
illustration; to show how an AM looks like. Thus the correctness of that model is not
accounted for.
Of course, the time required is also dependant on how many employees needs to be
interviewed in order to get the required information. For instance, if a total of five employee
functions cover all the transactions and their availability is favourable, we could say the PSD
with discourse can be done in 2-3 weeks. Following the same assumption, the AM is
estimated to take 3 weeks and for the SM a time-span of 3 weeks is estimated.
42
Fully Communication Oriented Information Modelling.
60
Products Required time

PSD with discourse 2-3 weeks
AM 3 weeks
SM 3 weeks
61
Appendix F: Project proposal

Project Name: Master’s Thesis Project for MSc Information Architecture
Start Date: March 2006 End Date: December 2006

Background: The concept of Enterprise Architecture (EA) isn’t new for the people working at Air
France Cargo – KLM Cargo (AF-KL Cargo). In fact, an Enterprise Wide Technical
Architecture is already in place and being used to aid designers in developing
technical systems. However, the Enterprise Business Architecture, Enterprise
Organization Architecture and Enterprise Information Architecture have yet to be
made and the need for an Enterprise Architecture that is complete has been growing
in the last few years. Therefore, the process of designing these architectures is in the
scope of the master’s thesis project of Andrew Go (a fellow student also placed at
AF-KL Cargo).
Regarding the history and the role of the Product Market Group (PMG) Aerospace, it
can be considered to have a “special” position within AF-KL Cargo. There are some
Aerospace business processes that are compulsory to the General Cargo business
processes. The way of working and the (information) systems at Aerospace also
differ from how it is organised at General Cargo. Consequently, Aerospace
should/could have its “own” EA (Aerospace-EA). Most likely this Aerospace-EA
would then be an extension of the General Cargo EA. The process of designing this
Aerospace-EA is in the scope of my master’s thesis project.
Another important thing to mention is that in this project raising the architecture
awareness of the people at Aerospace is one of the primary focuses. Because
without the needed support “working under architecture” will not have a chance to
succeed, especially considering the fact that it is a complete different way of working
Aerospace is used to.
Emphasis is also laid on the business processes at Aerospace. Modelling the as-is
processes will not only help me understand what is going on at Aerospace, it will also
identify which processes are compulsory for Aerospace and which processes are
similar to the processes at General Cargo. Furthermore, the as-is process model
provides a good starting point for enterprise redesign and change. This result has
value for AF-KL Cargo regarding cost-savings and organization.
Problem thesis: How can the Aerospace Logistics strategy and best practices be captured correctly in
an Enterprise Architecture?
Sub problems: • How can the enterprise objectives be retrieved?

• How can the best practices of the enterprise be retrieved?
• How should principles be formulated such that they are applicable for
designers?
• How should principles be organized?
Objectives: • Raise the architecture awareness of the people at Aerospace.

• To come to an Aerospace-EA that is in line with the General Cargo EA as an
extension.
• Emphasize the relation of Aerospace with General Cargo. Both at process
and strategic level.
• Identify which processes at Aerospace are compulsory for its department
and which are similar to the processes at General Cargo.
62
Result: • Analysis report.

• Support from the people of Aerospace to work under architecture.
• Aerospace Business Architecture.
• Aerospace Organizational Architecture focused on the processes domain.
• Comparison/fitting Aerospace-EA with General Cargo EA.
• Process analysis/model.
• Enterprise Architecture implementation process.
Project approach: 1. Collect and analyze documents regarding Aerospace and General Cargo
business strategy and goals.
2. Collect and analyze documents regarding the way of working at Aerospace and
General Cargo.
3. Raise the architecture awareness of the people at Aerospace by giving
presentations/workshops on EA and involving them in the process of devising the
Aerospace-EA.
4. Work with the project team (stakeholders) that is responsible for the process
analysis.
5. Interview persons who are responsible for realizing the strategy at Aerospace
(e.g. Aerospace managers).
6. Identify which processes at Aerospace are compulsory for its department and
which are similar to the processes at General Cargo.
7. Analyze if the processes can be redesigned to fit better in the General Cargo
way of working.
8. Develop the Aerospace-EA/Aerospace-BA.
9. Evaluate the Aerospace-EA/Aerospace-BA.
10. Comparing/fitting the Aerospace-EA with the General Cargo EA proposed by
Andrew Go.
Project Planning: 1 month Orientation and get to know the AF-KL organization.
1 month Analysis report.
1.5 months Process analysis/model and comparison with the Cargo Process Model.
2 months Devise Aerospace-BA and Aerospace-OA/Processes.
1 month Evaluation and discussion of Aerospace-BA with Aerospace
management.
1 month Comparison Aerospace-BA with General Cargo BA.
Σ=
7.5 months
Project organization: Supervisor at TU Delft: Prof. J.L.G. Dietz.
Supervisors at AF-KL Cargo: Hans Zwitzer and Marco Koole.
Project executor: Calvin Lee.
Other points of • A risk could be that in the beginning the abundance of information that is
attention: collected for analysis will delay the project’s progress.
• The course of development in the Aerospace process analysis project.
• The course of development of Andrew’s master thesis project.
• The availability of key persons for the necessary interviews and information,
especially during the holiday season.
63
Appendix G: Group Decision Tool manual

Tool functions:
• Generating principles
• Viewing principles
• Viewing clustered principles
Generating principles
Principles can be generated on the “Generate Principles” page. In order to generate the 2
designated text areas have to be filled in. The tool doesn’t accept principles without a
statement and/or a rationale. Leaving one or both text areas blank will result in an error.
Pressing the button labelled “Submit” will store the principle.
While generating principles, all principles generated so far will be shown to all participants.
The user is able to click on a principle, which results in the rationale of the clicked principle to
be shown.
Figure 1: The “Generate Principles” page.
Viewing principles
The generated principles can be viewed by navigating to the “Show Principles” page. Clicking
on a principle will show the rationale of the principle.
Viewing clustered principles
Once all generated principles are grouped together into clusters, these clusters can be
viewed in the “Show Clustered Principles” page. Clicking on a cluster will show all elements of
the cluster:
• Principle statement,
• Rationale and
• Implications.
64
Appendix H: Aerospace Logistics Protos models

65
Appendix I: List of abbreviations

AF = Air France
AFI = Air France Industries
AF-KL = Air France - KLM
AL = Aerospace Logistics
AM = Action Model
AOG = Aircraft on Ground
ATI = Air Transport Interface
ATI-PM = ATI Process Model
AWB = Air Waybill
BDO = Business Development Office
BU = Business Unit
CBS = Statistics Netherlands
CIO = Corporate Information Officer
CMMI = Capability Maturity Model Integration
CPM = Cargo Process Model
CSO = Costumer Service Office
DEMO = Design & Engineering Methodology for Organizations
DUT = Delft University of Technology
E&M = Engineering & Maintenance
EA = Enterprise Architecture
EAF = Enterprise Architecture Framework
EAMM = Enterprise Architecture Maturity Model
EWTA = Enterprise Wide Technical Architecture
FTE = Fulltime-Equivalent
GC = General Cargo
GDT = Group Decision Tool
ICT = Information and Communication Technology
IS = Information Services
IT = Information Technology
KLM = Koninklijke Luchtvaartmaatschappij
KPI = Key Performance Indicator
MT = Management Team
NASCIO = National Association of State Chief Information Officers
O2C = Order to Cash
PMG = Product Market Group
Q&A = Question & Answer
Scarlos = Service Cargo Logistic System
SLA = Service Level Agreement
SOx = Sarbanes Oxley
SPL = Schiphol
UI = User Interface
66
References
[1] Dietz (ed.), J.L.G., (2004), extensible Architecture Framework (xAF), version 1.1
(formal edition)
[2] Hoogervorst, J.A.P., (2005), Enterprise Architecture: Integrated Business,
Organizational, Information and Technology Design, slides for the course in4153
Architectural Design of Business Systems
[3] AF-KL Cargo, (2006), Corporate Information Office – Enterprise Architecture,
http://enterprisearchitecture.cio.klm.nl/home/home.asp
[4] Go, A.C.S., (2006), Implementing Enterprise Architecture, Action Research at Air
France Cargo – KLM Cargo, master’s thesis report
[5] Lee, C., (2006), How to set up an Enterprise Architecture for Aerospace?, analysis
report
[6] van Beele, J. (2003), Archicultuur
[7] Book review by Prof. Dr. Daan Rijsenbrij on the book: Lankhorst et al, M., (2005),
Enterprise Architecture at Work (Modeling, Communication and Analysis).
[8] Dietz, J.L.G., (2006), Enterprise Ontology, Theory and Methodology
[9] Nieuwenhuizen, M., (2006), Ware architectuur nog in kinderschoenen, Computable
[10] Oxford Advanced Learner’s Dictionary 7th edition, Oxford
[11] Rijsenbrij, D., (2005), Architectuur: een begripsbepaling, chapter from syllabus
Inleiding Digitale Architectuur,
http://www.digitalarchitecture.net/dictaat/hoofdstuk%201%20inleiding.doc
[12] Lindström, Å., (2006), On the Syntax and Semantics of Architectural Principles,
Proceedings of the 39th Hawaii international Conference on System Sciences
[13] Hoogervorst, J.A.P., (2004), Enterprise Engineering & - Architectuur: een antwoord
op falende strategie-implementaties, Holland Management Review
[14] AF-KL Cargo, (2000), Architecture Domain Principle.dot, Microsoft Word Template
[15] Blunt, J., (1998), Making Principles Work, Info|Ed
[16] Weinberg, G.M., (2001), An Introduction to General Systems Thinking, Dorset House
[17] Hoogervorst, J.A.P., (2003), Enterprise Architecture, Enabling Integration, Agility and
Change, academic paper for LAC 2003
[18] Morgenthal, J.P., (2005), Enterprise Architecture: The Holistic View: Design Your
Hinges of Business, DMReview.com,
http://www.dmreview.com/article_sub.cfm?articleId=1039841
[19] Hedman, J., Kalling, T., (2003), The business model concept: theoretical
underpinnings and empirical illustrations, European Journal of Information Systems
12
[20] META Practice, (2000), EAS Process Model: Evolution 2000, META Group Inc.
[21] Zwitzer, H., (2005), Architecture in practice, slides for the course in4153 Architectural
Design of Business Systems
[22] AF-KL Cargo intranet: Cargo Application Overview, Scarlos
[23] KLM Cargo Aerospace Logistics, (2004-2005), Project “Blue Print Aerospace”
[24] AF-KL Cargo Aerospace Logistics, (2005), KLM Cargo PMG Aerospace Logistics
meeting 3 and 4 November Huizen
[25] Bruegge, B., Dutoit, A.H., (2000), Object Oriented Software Engineering
[26] Talbott, S.L., (1995), Thoughts on a Group Support System, Chapter 10 of The
Future Does Not Compute: Transcending the Machies in Our Midst
[27] Ambler, S.W., (2006), Agile Modeling,
http://www.agilemodeling.com/essays/enterpriseModelingAntiPatterns.htm
[28] Peterson, J.L., (1981), Petri Net Theory and the Modeling of Systems
[29] AF-KL Cargo, (2004), Business Process Modeling Manual version 1.21
[30] Software Engineering Institute, (1995), The Capability Maturity Model: Guidelines for
Improving the Software Process
[31] NASCIO, (2003), NASCIO Enterprise Architecture Maturity Model version 1.3,
http://www.nascio.org/hotIssues/EA/EAMM.pdf
[32] Schekkerman, J. (2005), The Economic Benefits of Enterprise Architecture
[33] Dijk, R. and Kamminga, M. (2004), Het roer moet om! Maar hoe doe je dat?
67
[34] Verbraeck, A., Kohse, U. (2003), Project Management, reader for the course
epa1411
[35] de Bruijn, J.A., ten Heuvelhof, E.F., in ‘t Veld, R.J., (2002), Procesmanagement, Over
procesontwerp en besluitvorming, Academic Service
68

Aerospace Logistics Architecture Program

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aerospace Logistics Architecture Program

Uploaded by

Copyright:

Available Formats

Master’s thesis report: Aerospace Logistics architecture program Calvin Lee

Project: Master’s Thesis Project for MSc Information Architecture

This page is left blank intentionally.

4. Discussion and recommendations........................................................................................39

Appendix A: Aerospace Logistics business architecture..........................................................46

Appendix B: Aerospace Logistics DEMO models ....................................................................47

Appendix C: EA awareness presentation.................................................................................48

Appendix D: Workshop preparation material............................................................................54

Appendix E: Enterprise engineering (overview) .......................................................................57

Appendix F: Project proposal ...................................................................................................62

Appendix G: Group Decision Tool manual ...............................................................................64

Appendix H: Aerospace Logistics Protos models.....................................................................65

Appendix I: List of abbreviations...............................................................................................66

1.1. Project definition

Formally the problem thesis for the project is formulated as follows:

1. How can the enterprise objectives be retrieved?

1.2. Project approach

3.1. Principle definition

3.1.1 Elements of a principle

3.1.2. Principle formulation

As mentioned earlier, principles should represent a shared understanding on how the

• The acceptance of principles and

• Verification of the principles,

Guidelines for principle formulation

Implications present effects of a principle if it is applied. This is achieved by formulating

Besides considering implications to be an effect of the application of the principles,

3.2. Principle organization

3.2.1. Enterprise architecture perspectives

Figure 1: Different perspectives on an enterprise.

3.2.2. The Business Architecture Framework

Business Domain Definition

Hedman and Kalling business model concept

• The market level,

Figure 2: Hedman and Kalling business model concept.

As already mentioned before, the functional or business perspective of an enterprise is similar

Hoogervorst Business Architecture Framework

The business architecture framework suggested by Hoogervorst is depicted in figure 3. The

Mission Market Competitors

Sense making Market mix Lead/follow strategy

Customization Type/source Relationships

Figure 3: Hoogervorst Business Architecture Framework.

• Marketing should move from mass marketing to one-on-one marketing,

The Business Architecture Framework

Business Architecture Framework

Economic & Revenue Model Competitors Vision

Products & Services Customers

Key Resources & Assets Partners & Suppliers

Here & Now

Figure 4: The Business Architecture Framework.

3.2.3. Domain Definitions

Below each domain in the business architecture framework will be defined.

Products and services

Economic & Revenue Model

Key Resources and Assets

Partners & Suppliers

3.2.4. Principles in the EWTA

3.2. Aerospace Logistics EA awareness

1. knows what EA is,

3.3. Aerospace business architecture

3.3.2. Devising the AL business architecture

As mentioned earlier in the Aerospace Logistics EA awareness section, the director of AL

Figure 5: Workshop setting.

Figure 6: The “Generate Principles” page.

transport 2 transport