Capturing Decision Making Strategies in Enterprise ...

Capturing Decision Making Strategies in Enterprise Architecture - A Viewpoint Georgios Plataniotis1,2,3 , Sybren de Kinderen1,3 , and Henderik A. Proper1,2,3 1

Public Research Centre Henri Tudor, Luxembourg, Luxembourg 2 Radboud University Nijmegen, Nijmegen, the Netherlands 3 EE-Team, Luxembourg, Luxembourg?? {georgios.plataniotis,sybren.dekinderen,erik.proper}@tudor.lu

Abstract. Enterprise Architecture modeling languages describe an enterprise holistically, showing its business products and services and how these are realized by IT infrastructure and applications. However, these modeling languages lack the capability to capture the design rationale for decisions that lead to specific architectural designs. In our previous work we presented the EA Anamnesis approach for capturing architectural decision details. In this paper, we extend the EA Anamnesis approach with a viewpoint that captures and rationalizes decision making strategies in enterprise architecture. Such a viewpoint is useful because it helps enterprise architects reconstruct the decision making process leading up to a decision and understand how and under which circumstances this decision was made. For example, under time pressure an architect may rely on heuristics instead of examining the decision problem in depth. More specifically, we contribute: (1) a metamodel for capturing decision making strategies, which is grounded in established decision making literature, (2) an illustrative example showcasing the potential usefulness of capturing the decision making process.

Keywords: Enterprise Architecture, Decision making strategies, Design Rationale, Decision Capturing

1

INTRODUCTION

Enterprise Architecture (EA) [1, 2] is a steering instrument that connects an organization’s IT infrastructure and applications, to the business processes they support and the products/services that are in turn realized by the business processes. Such a holistic perspective on an enterprise helps clarify the business advantages of IT, analyze cost structures and more [3]. A variety of Domain Specific Languages for the modeling of Enterprise Architectures have been created, such as the Open Group standard ArchiMate [4]. ??

The Enterprise Engineering Team (EE-Team) is a collaboration between Public Research Centre Henri Tudor, Radboud University Nijmegen and HAN University of Applied Sciences (www.ee-team.eu)

2

Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper

While Enterprise Architecture modeling languages allow for modeling an enterprise holistically, the design decisions behind the resulting models are often left implicit. Although we should be careful with the analogy, experience from the field of software architecture shows that leaving design rationales implicit leads to ‘Architectural Knowledge vaporization’ (cf. [5]). This means that, without design rationale, design criteria and reasons that lead to a specific design are not clear. Also, alternatives that were considered during the design process are not captured. Among others, such lack of transparency regarding design decisions can cause design integrity issues when architects want to maintain or change the current design [6]. This means that due to a lacking insight of the rationale, new designs are constructed in an adhoc manner, without taking into consideration constraints implied by past design decisions. Also, according to a survey for software architecture design rationale [7], a large majority of architects (85,1%) admitted the importance of design rationalization in order to justify designs. Another interesting finding of this survey was that architects declared that after some time they frequently forget their own decisions. Moreover, anecdotal evidence from six exploratory interviews we conducted with senior enterprise architects, suggests that Architects are often external consultants. This situation increases the architectural knowledge gap of the Enterprise Architecture. The successor architect tries to understand and analyze the architecture by searching through architectural designs and unstructured information of requirements documentation. In our previous work [8] we introduced an approach for the rationalization of enterprise architectures by capturing EA design decision details. We refer to this approach as EA Anamnesis, from the ancient greek work αν´ aµνησις (/­ænæm"ni:sIs/), which denotes memory and repair of forgetfulness. The metamodel is grounded in Decision Representation Language (DRL) [9] and is based on similar approaches from the software engineering domain. At this stage, EA Anamnesis complements the ArchiMate modeling language [4] by conceptualizing decision details (alternatives, criteria, impacts) and by grouping EA decisions in three different enterprise architecture layers (Business, Application, Technology) in accordance with the ArchiMate specification. However, decision details captured by EA Anamnesis do not describe explicitly the decision making process during the architectural design. Although our approach captures alternatives and criteria of EA decisions, it does not provide information on how the decision process was executed. EA Anamnesis does not capture what decision strategy was used, and what factors led to the adoption of such a strategy. Yet, if considerations during the decision process are not captured, one looses the insight of the factors that also contributed towards taking the actual decision. For example, a decision could have been made under time pressure, and as such, a heuristic decision strategy may have been used instead of considering all criteria and their respective importance. In this paper we extend the EA Anamnesis approach in order to capture the decision making process. Specifically, we contribute: (1) a decision making

Capturing Decision Making Strategies in EA - A Viewpoint

3

strategy viewpoint metamodel that captures the basic characteristics of decision making process (decision strategies, criteria). The concepts from this metamodel are grounded in established decision making literature [10–14]. (2) we illustrate with a fictitious scenario how such a viewpoint can be used to capture the decision making process. Our approach helps an enterprise architect (probably not the actual designer) to reconstruct the decision making process and understand how his predecessor made an EA decision. It does so by making explicit, amongst others, the decision making criteria, the respective importance of criteria, the used decision making strategy and the rationale for selecting a decision making strategy. This would nicely complement our EA Anamnesis approach in the sense that it would allow for comparing the results of a decision with the criteria and used decision making process leading up to the decision. In such a way, architects can compare past decision making criteria to observed outcomes to learn from captured decisions. While we acknowledge that decision making often involves multiple parties [1], this paper focuses on a single decision maker: the enterprise architect. This paper is structured as follows. Section 2 presents the background literature in decision strategies and challenges, Section 3 introduces the decision strategy metamodel, while Section 4 illustrates the use of our approach with an insurance industry example. Finally Section 5 concludes.

2

BACKGROUND LITERATURE

The work reported in this paper is based on established literature of decision making strategies. This section reports on the two streams that were examined: (1) actual decision making strategies, and (2) factors that influence the decision making. 2.1

Decision making strategies

Decision making strategies generally fall in two main categories: compensatory and noncompensatory [10–12, 15]. We briefly explain these strategies with a car buying example. In this example, a customer selects a car based upon the criteria ‘color of car’, ‘carbon emission’, ‘small size of car’ and ‘gasoline consumption’. In compensatory decision making [10], alternatives are evaluated exhaustively, taking all criteria and their trade-offs into consideration. Criteria with high values compensate for criteria with lower values. Finally, the alternative with the highest score is selected. For our car buying example, this implies that a customer considers all four criteria ‘color of car’, ‘carbon emission’, ‘small size of car’ and ‘gasoline consumption’. For example: s/he can state that ‘color of car’ is of high importance, and ‘carbon emission’, ‘small size of car’ and ‘gasoline consumption’ are of less. By doing so the customer then selects a car that best complies with all these criteria. Compensatory strategies aim to provide the best possible decision outcomes given the decision data at hand. However, compensatory strategies require full

4

Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper

information on how alternatives score on all criteria, and they are time consuming [10]. Noncompensatory strategies [10], on the other hand, are consistent with the concept of bounded rationality. This means that the rationale to make a decision is limited by factors such as hard constraints, time constraints and the cognitive load of the decision maker. As such, noncompensatory strategies evaluate alternatives heuristically, using only a limited number of criteria and trade-offs. Considering a noncompensatory decision strategy for our car buying example, let us now assume that the customer lives in the city and selects between two cars: a small and a big one. Now, ‘small size of car’ is a hard constraint for the customer due to the limited parking space available in the city. Therefore, regardless of the criteria ‘carbon emission’, ‘color of car’, and ‘gasoline consumption’ s/he excludes the big car from her/his choice set. The main characteristics of noncompensatory strategies are twofold: (1) they reduce the decision making effort, (2) they are not demanding regarding the information needed to make the decision. As such, it is a common practice for decision makers to use noncompensatory strategies in situations (time stress, hard constraints) the limitations of which affect the decision making process [16]. However, by definition decision makers do not take all criteria into account when using noncompensatory decision strategies. Last but not least, in some cases the use of a combination of compensatory and noncompensatory decision strategies (a hybrid) is required [17, 18, 15]. For example, a decision maker starts his evaluation process by excluding alternatives that do not meet certain noncompensatory criteria, and only thereafter evaluates the remaining alternatives with a compensatory strategy. 2.2

Factors influencing the decision making

Decision making, in particular the choice for a decision making strategy, is influenced by factors such as time, information completeness, cognitive load of the decision maker, and more [13]. We describe briefly those factors and how they influence the decision making process. Time stress: One of the most common situations in decision making processes is time stress [14]. Decision makers under time pressure must take critical decisions. Usually these decisions are made last moment, in an adhoc manner, and without sufficient rationalization. Ill-structured problems: A decision problem is often complex in terms of cause-effect relations, correlations and feedback loop between relevant factors [14]. As such, decision problems are difficult to understand, also in terms of the impacts and outcomes that they have. Information incompleteness: meaning that in practice information can be ambiguous or even missing [14]. Shifting, ill-defined, or competing goals: A decision maker can have conflicting goals during the decision making process. Decision maker should weight appropriately each of these goals in making a decision [20].

Capturing Decision Making Strategies in EA - A Viewpoint

5

Action and feedback loops: Decision making contains a series of loops that the decision maker should deal with [14]. Early mistakes and poor information generate decisions that should be reexamined. For example violations in architectural design are not disclosed early enough and this implies that the decision making process should be repeated. High stakes: Decision makers have also to cope with high risk decisions, especially when the problem they are called to solve is of high importance [14]. Multiple player situations: When multiple stakeholders are involved in a decision making process the situation gets more complicated [14]. Stakeholders have different interests, goals and expectations from a specific decision. Another common issue is the lack of shared understanding between stakeholders for a particular problem. Multiplayer situations may result in delays in the decision making possibly leading to a revision of the decision, with high cost impact [21]. Organizational goals and norms: Organizations operate under specific goals and norms [14]. Decision makers should make decisions in the context of these goals and norms and should avoid making decision based only on their personal preferences. Decision makers, regardless of their personal preferences, must evaluate alternatives with criteria that the organization sets. Note that our approach does not provide rationalization support for decision strategies with multiple decision makers. As we mentioned before, this paper focuses on single decision maker environments.

3

THE DECISION STRATEGY VIEWPOINT

In this section we introduce the motivation for the decision making strategy viewpoint. In line with [22], we use a separate viewpoint for capturing the decision strategy to concentrate on concerns that are of interest for the decision making process itself (such as time pressure, the use of heuristics in decision making). Thereafter, we discuss the conceptualization of the decision making strategies and how these concepts extend EA Anamnesis approach for EA rationalization. 3.1

Motivation

Decision making for architects can be challenging. This is due to, amongst others, the cross organizational nature of enterprise architecture: inherently, architects involve stakeholders from different backgrounds and with differing concerns [1]. As a result, Enterprise architects as decision makers have to cope with various challenges in the decision making process such as time stress, ill structured problems, uncertain dynamic environments and others [14]. As we mentioned in Section 2.2, these factors affect the decision making process. Decision makers should be able to adopt a decision strategy that is appropriate for these challenges. The proposed viewpoint captures and reconstructs decision making processes for EA decisions. By comparing the captured decision strategy with the observed outcome of a decision, architects can understand if the decision making strategy

6

Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper

was successful or had negative consequences. This helps enterprise architects to follow or avoid decision making practices. For example: the viewpoint presented in this paper can be used to capture whether a decision was made under time pressure. Subsequently, if the outcomes of a decision was negative, we can use this information to make transparent why the decision was made.

3.2

Decision Strategy viewpoint metamodel

Figure 1 presents the metamodel of the Decision Strategy viewpoint. The idea of using different viewpoints for representing different types of information was taken from the ISO/IEC/IEEE 42010 standard for Architectural descriptions in Systems and Software Engineering [23]. The decision strategy viewpoint focuses on capturing (1) decision making strategies that were used during the architectural design process for a specific EA decision, (2) the rationale behind this specific decision strategy choice, and (3) available alternatives and criteria that were taken into account. Decision-Making Strategy: This is the central concept of our viewpoint. It captures the decision making strategy used by the enterprise architect to (1) evaluate the alternatives, and make the actual EA decision. As we mentioned in Section 2.1, decision strategies are characterized as compensatory, noncom-

Fig. 1. Metamodel of Decision Making Strategy viewpoint

Capturing Decision Making Strategies in EA - A Viewpoint

7

pensatory, or as a hybrid of these two. In our metamodel, we specify this as follows: – Compensatory strategy • Weighted additive (WADD): In WADD strategies the criteria that evaluate the alternatives have different weights. The score of each alternative is computed by multiplying each criterion by its weight and then by taking the sum of these values. The alternative with the highest score is chosen by the decision maker [15]. • Equal weight: The score of each alternative is calculated by the same way as WADD strategies. The difference is that criteria have the same weight [15]. – Noncompensatory strategy • Conjunctive: In conjunctive strategies, alternatives that fail to comply with a minimum threshold level of one or more criteria, are immediately excluded from the decision maker’s choice set [15]. • Disjunctive: In this strategy alternatives are evaluated based on the maximum threshold level of one or more criteria. Those which fail to meet the maximum level, are excluded from the choice set [15]. In line with Section 2.1 a hybrid decision strategy is supported by our metamodel. The relationship ‘trace to’ signifies the combination of two or more decision strategies during the decision making process. We should also mention that there is no restriction in the use of additional decision strategies. We include a set of common decision strategies, but we also denote in the strategy viewpoint metamodel that more decision strategies can be supported. Strategy rationale: In a decision making process, the architect not only has to choose amongst some alternatives (actual decision making process), but has also to select the decision strategy that satisfies his current evaluation needs. Actually, this concept represents the rationale for the decision strategy that was selected for the evaluation process. This is what is referred as metadecision making, decision making about the decision process itself [24]. As we discussed in Section 2.2, different factors affect the decision making process and decision makers should adjust accordingly their decision making strategy. The concept of a strategy rationale enables a decision maker to justify the reasons for his metadecision. For example, budget issues may be a strategy rationale for selecting a noncompensatory decision making strategy. Criterion: Criteria play an important role in the decision strategy viewpoint. Depending on the decision strategy that was used for the evaluation process, criteria can be compensatory or noncompensatory. For example, if a disjunctive strategy was used, the criteria that were used for the evaluation with this strategy are disjunctive. Furthermore, the concepts value and weight of criterion are included in our viewpoint. Value concept represents the value that the decision maker assigns to this criterion during the evaluation process and weight concept represents the importance of this criterion. Weight concept is

8

Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper

used in WADD strategies.This gives the ability to the architect to trace back the decision making process and analyze the value as well as the importance of each criterion during the evaluation process. By capturing the type, value and weight of criteria, stakeholders that analyze in depth the architecture, can understand which criteria had a determinant role in the selection process and on which strategy they were based. EA decision: An EA decision represents the actual decision that was made after the evaluation process. EA decision is the central concept for EA Anamnesis approach [8]. As such, EA decision can act as a bridging concept between our EA Anamnesis approach (see Introduction) and the Decision Strategy viewpoint. The EA decision captures the actual decision made, while the decision strategy viewpoint describes the strategy leading up to the decision. Alternative: The concept of alternative represents the available choices that are under evaluation by using a specific decision making strategy.

4

ILLUSTRATIVE EXAMPLE

We now show how the EA Anamnesis approach can be used to capture architectural decision details as well as decision making strategy details by using the proposed strategy viewpoint. The strategy viewpoint enhances the rationalization information that EA Anamnesis provides. For illustration purposes, we use an insurance company case study presented in our previous paper [8]. We aim to illustrate that the proposed strategy viewpoint can assist Enterprise Architects in understanding not only architectural details of each EA decision, but also how decision making process for this specific EA decision was done. 4.1

ArchiSurance: moving to an intermediary sales model

ArchiSurance is an insurance company that sells insurance products using a direct-to-customer sales model. The company used this disintermediation scheme to reduce its operations and product costs. Although, disintermediation reduces operational costs, the use of intermediaries in insurance sector is very important because they provide accurate risk customer profiles [25]. ArchiSurance management decides to adopt this practice and to change its selling model to intermediary sales. The role of the Insurance broker is added to the business operation of the company. 4.2

Capturing a decision process for ArchiSurance

In our scenario, an external architect called John is hired by ArchiSurance to change the Enterprise Architecture and analyze the impacts that the intermediary sales of insurance has on the company. John uses the EA modeling language ArchiMate to capture the impacts that selling insurance via an intermediary has in terms of business processes, IT infrastructure and more.

Capturing Decision Making Strategies in EA - A Viewpoint

9

Fig. 2. ArchiSurance intermediary EA model

The resulting ArchiMate model is depicted in Figure 2. The initial ArchiMate model (before the transformation) is left out because of space limitations. Please refer to our previous work [8] for this EA model. Here we see for example how a (new) business process ‘customer profile registration’, owned by the insurance broker (ownership being indicated by a line between the broker and the business process), is supported by the IT applications ‘customer administration service intermediary’ and ‘customer administration service ArchiSurance’. However, John (by using ArchiMate) can not capture the rationale behind this model. For example, he captures the change for the different application architecture that supports the new business process, but he is not able to capture the justification for his decision. To capture design rationales behind the ArchiMate model, John relies on the EA Anamnesis approach (our previous work, see [8]). For this simplified scenario 13 Architectural decisions were made. Table 1 shows an example application of the EA Anamnesis approach (EA decision 13). As it can be observed, decision facets such as the decision rationale (why the decision was taken), criteria (factors, such as cost), observed impact (ex-post) are captured. For further details, see [8]. However, what we lack in the EA Anamnesis approach is the idea of the decision making strategy leading up to the captured decision. For example: we cannot see if a decision was taken under

10

Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper Table 1. EA decision 13 details Title: EA issue:

Acquisition of COTS application B Current version of customer administration application is not capable to support maintenance and customers administration of intermediaries application service John

Decision Maker: Layer: Application Intra-Layer EA decision 10 dependent Decisions: Inter-Layer None dependent Decisions: Alternatives:COTS application A COTS application C Upgrade existing application (inhouse) Rationale: Scalability: Application is ready to support new application services Criteria: Customized reports capability, interoperability, scalability, cost Observed Interoperability issues. Application COTS B can not Impact: communicate with existing applications of some insurance brokers.

time pressure, or what decision strategy was used to make a decision based upon the importance and tradeoffs of available criteria (as discussed in Section 2). Therefore, we now replay the decision process leading up the the creation of the EA decision captured in Table 1. In doing so, we illustrate the EA Decision making strategy viewpoint. Capturing a decision making process: For the purposes of this paper, we focus on capturing and analyzing decision making strategies. Therefore, we assume that John is a single decision maker, who is capable to identify the above concepts and he has full information to evaluate them. We thus abstract away from identifying the specific alternatives, criteria and their respective scores (as briefly touched upon in Section 2.2. To start the decision making process, John based on the requirements of the new business process, defines the criteria that the new application should satisfy (the criteria for application selection are grounded in [26]). For our illustrative example, John considers that the most important architectural criteria are ‘customized reports capability’, ‘interoperability’ and ‘scalability’. Based on these criteria he identifies four alternatives to choose from: three alternative Commercial Off-The-Shelf (COTS) applications and one to upgrade the existing application in house.

Capturing Decision Making Strategies in EA - A Viewpoint

11

Let us also assume that John receives a constraining budget reduction of 10000$ for the acquisition of new IT systems. John is now faced with a hybrid decision strategy: on the one hand, he wants to carefully evaluate the four alternatives on the criteria ‘customized reports capability’, ‘interoperability’ and ‘scalability’ (via a compensatory strategy), but on the other hand John has to account for the hard constraint of ‘budget limitation’ (via a non-compensatory strategy). At this time John uses the decision viewpoint to capture and justify his strategy selection, as well as the alternatives and criteria of his decision problem. For the noncompensatory part, John wants to discard all alternatives that fail to meet the cost criterion. Because of this hard constraint, he chooses a disjunctive noncompensatory strategy (for an explanation, see Section 3.2) to exclude from his choice set alternatives that exceed the maximum value of one or more criteria. Table 2 summarizes the score of each alternative. COTS application C is eliminated from the choice set because it failed to meet the maximum cost requirement. As we mentioned before, disjunctive noncompensatory strategies evaluate alternatives using a maximum threshold level on one or more criteria. In this example the disjunctive criterion is ‘cost’. The alternatives ‘COTS A’,‘COTS B’ and ‘Upgrade application’ comply with this criterion (Table 2) and will be evaluated further in the next step of the decision making process. ‘COTS C’ cost exceeds the maximum limit and is eliminated from the choice set. For noncompensatory strategies, alternatives either comply or not to some criteria and their score are Boolean data types. The scores of the alternatives are also captured based on our metamodel. For the compensatory part, John evaluates the three remaining alternatives based on the values and the weight of each of the criteria. Scalability is the most important factor because, according to John, this application should be able to support changes in the business processes of ArchiSurance. This is important in order to support the addition of extra intermediaries. Customized reports capability and interoperability are also important, but not as important as scalability. Given the fact that criteria that evaluate alternatives have different weights, John selects the use of a weighted additive compensatory strategy. At this moment John captures again his decision strategy as well as the weights and the values of the compensatory criteria. The score of each alternative is calculated Table 2. EA decision 13 noncompensatory disjunctive strategy Alternatives COTS A COTS B COTS C Upgrade app

cost score 9000$ 1 8000$ 1 12000$ 0 5000$ 1

12

Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper

by multiplying the value of each criterion by its weight, and then by taking the sum of these values. Here, the weights range from 1 - not important - to 10 - important. The alternative with the highest score is chosen by the decision maker. Table 3 shows us: (1) the criteria. ‘Scalability’, the most important criterion for John, has a weight of 10, while ‘Custom reports’ and ‘interoperability’ have weights of 7 and 5 respectively, (2) the score on a particular criterion for each alternative. For example: the alternative ‘COTS B’ scores 9 on ‘scalability’, whereas ‘Upgrade app’ scores 4. (3) the total score of each alternative. For example: ‘COTS B’ receives the highest score and as such, is selected by John. Reflecting upon the captured decision making process. So far, we have illustrated the decision process as captured by John. Let us now illustrate how decision making process for EA decision 13 can be useful by the new enterprise architect, Bob. Bob’s predecessor, John, captured the decision making process with the EA Anamnesis decision strategy viewpoint. Bob can now analyze (1) the used strategy, (2) why this strategy was selected, and (3) the importance of criteria for this evaluation process. Figure 3 shows the decision making process for EA decision 13 based on the decision strategy metamodel. From the decision making process, Bob understands that a hybrid model was used. More specifically, he realizes that the criterion ‘cost reduction’ was used to discard an alternative, with the use of a disjunctive noncompensatory strategy. Furthermore, Bob observes that a compensatory weighted additive strategy was used to evaluate the remaining alternatives. He realizes that his predecessor used this strategy, because the criteria ‘customized reports capability’, ‘interoperability’ and ‘scalability’ did not have the same importance for the selection of an appropriate application that would support the new business process of ArchiSurance. He can also see the weight of each criterion, as well as the final score of each of the alternatives. This reconstruction of the decision making process makes transparent how an EA design decision has been made. Amongst other, this transparency allows an architect to compare the outcome of an EA decision with the decision making criteria that led to this decision. As a result, s/he can learn which factors in the decision making process had a positive/negative impact to the EA design and follow/avoid these decision making practices for future decisions. After a period of time, COTS application B does not have a sufficient performance due to interoperability issues. Bob, is asked by management to explain Table 3. EA decision 13 compensatory weighted additive strategy Alternatives custom reports interoperability scalability score COTS A 7x7 7x5 7x10 154 COTS B 8x7 3x5 9x10 161 Upgrade app 5x7 5x5 4x10 100

Capturing Decision Making Strategies in EA - A Viewpoint

13

Fig. 3. Decision making process for EA decision 13

the choice for COTS application B. He can reconstruct and examine the decision making process using Tables 2 and 3. First, he observes that COTS application C was eliminated because of budget issues. Second, from the weight assigned to the different criteria in Table 3, he observes that scalability was an important criterion for his predecessor to select COTS application B, but not interoperability. By examining the captured criteria and their weight as well as the observed impact of the EA Decision (Table 1) Bob can learn that interoperability is an important requirement for Archisururance enterprise architecture and should be weighted and compared against other criteria more carefully. For example: in a future decision making process, Bob can provide a weight of 7 or 8, instead of 5, to the criterion interoperability to better weight it against other criteria such as scalability.

5

CONCLUSION

In this paper we introduced a metamodel for capturing the decision making strategies in enterprise architecture. Furthermore, we argued why capturing the decision making strategy, next to the decision itself, is useful (1) by argumentation, (2) by means of an illustrative example. For future research, first and foremost we intent to confront the illustrative examples of capturing and rationalizing a decision strategy to practitioners. As an example of such evaluation would be the estimation of the level of understanding of existing enterprise architectures and the decisions that led to them.

14

Georgios Plataniotis, Sybren de Kinderen, and Henderik A. Proper

Second, we aim at conducting case studies to capture architectural decision making strategies. Furthermore, we aim to further extend our approach by facilitating the selection of decision making strategies during the decision making process. We deem such an extension relevant, because it helps the architect select an appropriate decision strategy based on the characteristics and constraints (such as time stress) imposed by the decision making environment. Last but not least, one of our major challenges is to investigate the return of capturing effort for our approach. Our design rationale assists architects to better understand existing EA designs, but the effort of capturing this information might be a dissuasive factor. To address this issue our research will focus on ways to decrease the capturing effort. One way of doing this is by evaluating the actual practical usefulness of the concepts in the decision making strategy viewpoint. For example we capture the strategy rationale for selecting a decision making strategy, but it remains to be seen if the effort for capturing this, outweighs the received benefits.

Acknowledgments. This work has been partially sponsored by the Fonds National de la Recherche Luxembourg (www.fnr.lu), via the PEARL programme.

References 1. Op’t Land, M., Proper, E., Waage, M., Cloo, J., Steghuis, C.: Enterprise architecture: creating value by informed governance. Springer (2008) 2. Hoogervorst, J.: Enterprise architecture: Enabling integration, agility and change. International Journal of Cooperative Information Systems 13(03) (2004) 213–233 3. Lankhorst, M.: Enterprise architecture at work: Modelling, communication and analysis. Springer (2009) 4. The Open Group: ArchiMate 2.0 Specification. Van Haren Publishing (2012) 5. Jansen, A., B¨ osch, J.: Software architecture as a set of architectural design decisions. In: Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on, IEEE (2005) 109–120 6. Tang, A., Jin, Y., Han, J.: A rationale-based architecture model for design traceability and reasoning. Journal of Systems and Software 80(6) (2007) 918 – 934 7. Tang, A., Babar, M.A., Gorton, I., Han, J.: A survey of architecture design rationale. Journal of Systems and Software 79(12) (2006) 1792 – 1804 8. Plataniotis, G., de Kinderen, S., Proper, H.A.: Ea anamnesis: towards an approach for enterprise architecture rationalization. In: Proceedings of the 2012 workshop on Domain-specific modeling. DSM ’12, New York, NY, USA, ACM (2012) 27–32 9. Lee, J.: Extending the potts and bruns model for recording design rationale. In: Software Engineering, 1991. Proceedings., 13th International Conference on, IEEE (1991) 114–125 10. Einhorn, H.: The use of nonlinear, noncompensatory models in decision making. Psychological bulletin 73(3) (1970) 221

Capturing Decision Making Strategies in EA - A Viewpoint

15

11. Payne, J.: Task complexity and contingent processing in decision making: An information search and protocol analysis. Organizational behavior and human performance 16(2) (1976) 366–387 12. Svenson, O.: Process descriptions of decision making. Organizational behavior and human performance 23(1) (1979) 86–112 13. Alenljung, B., Persson, A.: Portraying the practice of decision-making in requirements engineering: a case of large scale bespoke development. Requirements engineering 13(4) (2008) 257–279 14. Orasanu, J., Connolly, T.: The reinvention of decision making. (1993) 15. Rothrock, L., Yin, J.: Integrating compensatory and noncompensatory decisionmaking strategies in dynamic task environments. Decision Modeling and Behavior in Complex and Uncertain Environments (2008) 125–141 16. Payne, J., Bettman, J., Johnson, E.: The adaptive decision maker. Cambridge University Press (1993) 17. Elrod, T., Johnson, R., White, J.: A new integrated model of noncompensatory and compensatory decision strategies. Organizational Behavior and Human Decision Processes 95(1) (2004) 1–19 18. Jeffreys, I.: The use of compensatory and non-compensatory multi-criteria analysis for small-scale forestry. Small-scale Forestry 3(1) (2004) 99–117 19. McAllister, D., Mitchell, T., Beach, L.: The contingency model for the selection of decision strategies: An empirical test of the effects of significance, accountability, and reversibility. Organizational Behavior and Human Performance 24(2) (1979) 228–244 20. Ruhe, G.: Software engineering decision support: methodology and applications 21. Regnell, B., Paech, B., Aurum, A., Wohlin, C., Dutoit, A., och Dag, J.: Requirements mean decisions!–research issues for understanding and supporting decisionmaking in requirements engineering. In: First Swedish Conference on Software Engineering Research and Practise: Proceedings, Citeseer (2001) 22. Nuseibeh, B., Kramer, J., Finkelstein, A.: A framework for expressing the relationships between multiple views in requirements specification. Software Engineering, IEEE Transactions on 20(10) (1994) 760–773 23. IEEE: Systems and software engineering – architecture description. ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std 1471-2000) (1 2011) 1 –46 24. Mintzberg, H., Raisinghani, D., Theoret, A.: The structure of unstructured decision processes. Administrative science quarterly (1976) 246–275 25. Cummins, J., Doherty, N.: The economics of insurance intermediaries. Journal of Risk and Insurance 73(3) (2006) 359–396 26. Jadhav, A., Sonar, R.: Evaluating and selecting software packages: A review. Information and software technology 51(3) (2009) 555–563