Aerospace Logistics Architecture Program

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

1

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


2

This page is left blank intentionally.


3

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:

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.

How can the Aerospace Logistics strategy and best practices be captured correctly in an Enterprise Architecture?


4

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.


5

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


6

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]. Regarding the history and the role of the Product Market Group1 (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).



7

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 learning by doing or an action research3. 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.


8

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.


9

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 in my project8, 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.


10

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.


11

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.


12

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


13

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.


14

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]


15

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.


16

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.

Sense making

Purpose

Mission

Learning

Renewal

Adaptation

Choices

Strategy

Market mix

Market exploitation

Market

Lead/follow strategy

Relative position

Competitors

Impact

Contribution

Environment

Impact

Contribution

Stakeholders

Customization

Value

Quality

Integration

Standards

Products

Services

Relationships

Personalization

Interaction

Interfaces

Org. focus

Customers

Type/source

Deployment

Key Resources

Channels

Partners

Operating Method

Core focus

Income mix

Economic and

Revenue Model

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


17

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.


18

Here & Now

...

Business

Trends

Vision

Best Practices

Products & Services Customers

Key Resources & Assets

CompetitorsEconomic & Revenue Model

Partners & Suppliers

Business Architecture Framework

Strategy

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.


19

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.


20

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 3. is willing to participate in the development of EA12.

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 usage of Scarlos13 [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.


21

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 AL15. 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. If we look at the project planning in my project proposal16, 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 includes studying the strategy documents such as the Blueprint, the Huizen presentation18

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.


22

[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 considering the history of Scarlos19 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 solutions, however, the system development process20 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.


23

The result of this workshop is a list of Scarlos UI issues. From what I have heard21 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 approach its commercial terrain. To support this process Andrew Go22 and I have put together a workshop tool, Group Decision Tool23 (GDT) [26], which is implemented in the form of a website24. 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


24

Participant

Participant

Participant

Participant

Participant

Participant

Facilitator

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 method to actually use it25, 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 this process I prepared some domain questions and pizzeria example principles26. 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.


25

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.


26

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 Sp renger (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. Before the actual meeting I have sent Vincent some preparation material28 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.


27

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 Ringer sma (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.


28

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.


29

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-2 006, 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-2 006, 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


30

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:


31

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


32

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.


33

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.


34

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 on how the workflow goes at Operations because I was experiencing the process first hand32. 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.


35

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


36

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.

Customer

Supplier

Regulatory

Bodies

T03A03:

Service

Developer

T04

make customer

agreement

T06

A07:

Supplier

HandlerT07

T01A01:

Shipment

Handler

T02

T05

A08:

Complaint &

Claims

Handler

CA01 CA02

CA03

make supplier

contract

customer

invoicing

supplier

payment

transport

shipment

*2* transport

shipment

customs

handling

Aerospace

T09

A09:

Transport

Advisor

transport/customs

advice

T08

handle

complaint/claim

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


37

Although it must be mentioned that GC also does some customs handling. However customs and CBS39 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 the Interaction Model and Process Model40. 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.


38

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.


39

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 architecture for all the wrong reasons41. 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.


40

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


41

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.


42

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.


43

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.


44

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.



45

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.


46

Appendix A: Aerospace Logistics business architecture For internal use only.


47

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


48

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.


49

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


50

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


51

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


52

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


53


54

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.


55

Business Architecture Framework We will make use of the following framework to work out the business architecture.

Here & Now

...

Business

Trends

Vision

Best Practices

Products & Services Customers

Key Resources & Assets

CompetitorsEconomic & Revenue Model

Partners & Suppliers

Business Architecture Framework

Strategy

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.


56

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.


57

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.


58

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.


59

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

BA Calvin Lee OA/processes Calvin Lee OA/rest <name>

Architecture

IA <name> ATD Calvin Lee PSD – discourse Calvin Lee PSD + discourse <name>

Enterprise Ontology

DEMO/rest <name> Functional Model List of requirements Business and IM

UML models IS … IS Source Code IS

Software Engineering

Program Executable IS


60

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: The state model (SM), which models all the essential information objects in FCO-IM42 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.


61

Products Required time PSD with discourse 2-3 weeks AM 3 weeks SM 3 weeks


62

Appendix F: Project proposal Project Name: Master’s Thesis Project for MSc Infor mation 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.


63

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. 1 month 1 month 1.5 months 2 months 1 month 1 month

Project Planning:

Σ = 7.5 months

Orientation and get to know the AF-KL organization. Analysis report. Process analysis/model and comparison with the Cargo Process Model. Devise Aerospace-BA and Aerospace-OA/Processes. Evaluation and discussion of Aerospace-BA with Aerospace management. Comparison Aerospace-BA with General Cargo BA.

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 attention:

• A risk could be that in the beginning the abundance of information that is 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.


64

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.


65

Appendix H: Aerospace Logistics Protos models For internal use only.


66

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


67

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?


68

[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

Documents

Aerospace Logistics Architecture Program