# Towards an Approach for Stakeholder-Oriented Elicitation and Identification of Concerns in EA

Carsten Lucke, Ulrike Lechner

► To cite this version:

Carsten Lucke, Ulrike Lechner. Towards an Approach for Stakeholder-Oriented Elicitation and Identification of Concerns in EA. 4th Practice of Enterprise Modeling (PoEM), Nov 2011, Oslo, Norway. pp.147-161, 10.1007/978-3-642-24849-8_12. hal-01572401

HAL Id: hal-01572401

https://inria.hal.science/hal-01572401

Submitted on 7 Aug 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Towards an Approach for Stakeholder-Oriented Elicitation and Identification of Concerns in EA†

Carsten Lucke, Ulrike Lechner

Professur für Wirtschaftsinformatik
Universität der Bundeswehr München
85577 Neubiberg, Germany
{carsten.lucke, ulrike.lechner}@unibw.de

**Abstract.** The concept of concern is used in Enterprise Architecture (EA) to express a stakeholder’s area of interest in a system whose architecture is to be described. Many EA-related problems are rooted in weak stakeholder orientation. We propose an approach to explicitly model stakeholders’ concerns as part of an architecture description. Our contribution is a modeling notation for concern elicitation and a method for concern identification. Our approach is based on goal-oriented requirements engineering and is compatible to the conceptual framework of the ISO 42010 international standard. We claim that our approach allows for a more thorough understanding of stakeholders’ concerns and facilitates a stronger stakeholder orientation in EA.

**Keywords:** Goal-oriented requirements engineering, GORE, enterprise architecture, concern elicitation, concern identification, stakeholder orientation.

## 1 Introduction

Several predominant challenges in the field of enterprise architecture (EA) are related to stakeholders and caused due to a weak stakeholder orientation [1-4]. Stakeholder orientation means the careful consideration of EA stakeholders and their concerns, which is an important success factor for any enterprise architecting effort [1, 2, 5, 6]. In terms of an enterprise architecture description (EAD) a proper stakeholder orientation comprises identifying stakeholders and their architecture-related concerns (cf. [7]). Despite the availability of EA frameworks, notations, models or tools, alignment of EADs to stakeholders’ requirements remains a problem in EA practice [1-3]. Determining stakeholders’ architecture-related concerns is critical to identify suitable architecture viewpoints (cf. [7]).

We develop an approach (i.e., ASTEAM – Approach for STakeholder-oriented EA Modeling), which facilitates the determination of architecture viewpoints tailored to stakeholders’ requirements. ASTEAM comprises a modeling notation and a method

<footnote>† We thank Dr. Tobias Lehmann from Inopus GmbH and our colleague Sascha Krell for helpful comments and the opportunity of collaboration on this project. We gratefully acknowledge the fruitful collaboration of our workshop participants as well as our project partners.</footnote>
to guide development. In this article we present these parts of ASTEAM that are
targeted at eliciting stakeholder requirements and identifying their concerns. Our
contribution is (1) a modeling notation to develop concern models and (2) a method to
identify concerns based on these models. Particular to our approach is that we model
requirements in a GORE-based fashion and derive stakeholders' concerns from these
requirements. Structural patterns aid this derivation process. The design of ASTEAM
is compatible to the ISO 42010 standard [7] and based on goal-oriented requirements
modeling (GORM) and goal-oriented requirements engineering (GORE) [8-10].

We claim three advantages. First, our approach allows for a more thorough understanding of stakeholders’ concerns. Second, requirements that form the basis of concerns can be directly elicited in interviews and meetings. This allows for a more tailored stakeholder orientation than featured by EA frameworks or concern list based approaches (cf. section 2). Third, we claim that more tailored concerns eventually lead to more tailored viewpoints taken in an architecture description and therefore to a better stakeholder orientation.

Section 2 covers theoretical foundations. Section 3 presents our research approach. In section 4 we propose a conceptual model integrating GORE and EA concepts as described by the ISO 42010 standard. We present sample models from an EA project, introducing our modeling notation for concern elicitation and the associated method guiding concern identification. Section 5 concludes.

## 2 Definitions and State of the Art

In this paper we conform to the definitions and concepts provided by the ISO 42010 international standard [7]. It defines architecture as the “fundamental conception of a system in its environment embodied in elements, their relationships to each other and to the environment, and principles guiding system design and evolution” [7]. The architecture of a system is captured in an architecture description (EAD) defined as a “collection of work products used to describe an architecture” [7]. The ISO 42010 standard provides a conceptual model of architecture description (cf. Fig. 1).

<figure><img src="image_2.png" /><figcaption>Fig. 1. Conceptual model of architecture description: content model (cf. [7])</figcaption></figure>

This conceptual model captures that an architecture description shall identify stakeholders. We conform to the ISO 42010 standard's definition of a stakeholder as “individual, team, organization, or classes thereof, having concerns with respect to a system” [7]. According to ISO 42010, an *architecture-related concern* (cf. **Fig. 1**) is an “area of interest in a system pertaining to developmental, technological, business,
operational, organizational, political, regulatory, social, or other influences important to one or more of its stakeholders" [7]. Within an architecture description the stakeholders' concerns are framed by one or more viewpoints. A viewpoint is a "work product establishing the conventions for the construction, interpretation and use of architecture views and associated architecture models" [7].

Identification of stakeholders and concerns is considered both in EA and requirements engineering (RE). Although the importance of requirements engineering for EA is acknowledged in a number of publications [2, 6, 11-15], we are aware of only a few approaches, which offer methodological guidance for a stakeholder-specific identification of concerns in connection with requirements engineering. EA frameworks (EAF) for instance are typically rather abstract (cf. [2, 16]). Since they are designed in regard to certain generic stakeholders and concerns they prescribe viewpoints applicable to this generic stakeholder/concern combination only.

We see the need for an approach that aids the enterprise architect in capturing stakeholders' requirements and information demands and in identifying architecture-related concerns based on these. There are a few approaches guiding stakeholder-oriented concern identification most of which use predefined concern lists to identify stakeholders' actual concerns.

The Enterprise Architecture Management Pattern Catalog (EAMPC) [17, 18] utilizes a best practice list of EAM concerns and amongst others identifies dependencies between these concerns, methodologies required to address these concerns (M-Patterns) and viewpoints, addressing these concerns (V-Patterns).

Another approach for stakeholder-oriented modeling and analysis of EA is developed at the HSG St. Gallen [1, 2]. It comprises a modeling and analysis framework, a viewpoint system and a development method. The method defines steps to identify stakeholders' concerns, elicit requirements, select viewpoints and define an information model. For concern identification this approach advocates the use of a list of potentially useful concerns as for instance provided by the EAMPC [2]. The concern identification step is followed by a requirements elicitation step to gather detailed requirements in regard to concerns identified relevant.

The Pedigreed Attribute eLicitation Method (PALM) [19, 20] is "a lightweight method based on goal oriented requirements engineering that begins with a canonical list of business goals and elicits specific business goals from the perspective of various stakeholders" [19]. "Outcome of the business goal elicitation method is a set of quality attribute requirements with a pedigree rooted in business goals" [20]. Business goals are interpreted in terms of quality attribute requirements in order to inform the definition of a system's software architecture. Lists of business goals as well as architecture-related quality attributes (e.g., ISO 9126) are used and discussed to identify and agree on relevant architecture quality attributes.

All aforementioned approaches are able to identify a large range of stakeholder concerns; their flexibility relies on the quality and extent of the concern- or quality attribute lists. The approaches offer a good opportunity to quickly identify common concerns (i.e., in the sense of best practices). Conversely, this means they have weaknesses to address specific or uncommon concerns. Concerns that are not captured in the concern or quality attribute lists will not be found as a result of RE activities.
# 3 Research Design

Our research design follows an iterative approach. A first concept of ASTEAM was developed based on theory and the proposition that typical GORE concepts hold for a reasonable representation of the notion of *concern*, making this concept easier to hypostatize [4]. To consider practitioner needs a workshop was held, resulting in a prototype version of ASTEAM. This prototype was then applied in a project to gain practical experience and reach a mature version of ASTEAM; the paper at hand presents the state of our ASTEAM approach after this project.

The practitioner workshop was held on the topic of stakeholder-orientation in EA modeling to discuss the early concept of ASTEAM. This half-day workshop took place in September 2010. Three EA researchers and five EA practitioners of companies and organizations operating in public business, government and the defense sector attended this workshop. The workshop had three topical parts, each of which was preluded with a short presentation followed by a round of discussions. These three parts were: (1) stakeholder-related issues and means to a stronger stakeholder orientation in EA; (2) the ASTEAM methodology and its integration into the typical enterprise architecting process; (3) the ASTEAM modeling notation, its model types and model elements. We discussed, which model elements the attendees expected, based on their experiences, to be part of EA models that aim at understanding stakeholders' requirements related to an EA effort. Discussions were tracked in a workshop protocol and criticism and suggestions were used to craft a revised version of the ASTEAM prototype.

The ASTEAM prototype as defined after the workshop was applied in an EA project for an industry partner (IP) operating in the aviation industry. The project went from September 2010 to January 2011. About 150 people are employed in our IP's department, which is part of a leading manufacturing and support company in the aviation industry. The main area of activity of our IP is software maintenance (SWM) of avionic software used in two different types of aircrafts with a lifetime period of thirty years “plus”. The goal of the project was to develop a department-wide baseline EAD on the subject matter of review support for aircraft software (SW) to be maintained. The first author of this publication participated in the project as an architect.

We used the following sources of evidence to inform our concern modeling activities:

* *Stakeholder interviews.* Interviews were open-ended; question asking was semi-structured (tending to unstructured) to gain substantial insight [21]. Initial question asking was informed by contract and strategy documents.

* *Contract documents.* These documents give important information about project goals.

* *Strategy documents* are used as source to an understanding of IP's organizational goals, helping to understand the organizational context of the project.

Interviews were not recorded; contract and strategy documents are confidential and only accessible in the IP's intranet. Important information was therefore written down if possible and directly captured in an ASTEAM concern model.
# 4 Concern Elicitation and Identification

This section presents our concern elicitation modeling notation and concern identification method. The presentation of our modeling notation and method follows the order of their application in practice. The conceptual model underlying our concern model is presented in section 4.1 and the concern modeling notation in section 4.2. Our method comprises of three steps:

1. Stakeholder identification;

2. Concern elicitation (cf. section 4.3); and

3. Concern identification (cf. section 4.5).

A prerequisite to concern elicitation is identification of (key) stakeholders. ASTEAM makes no explicit specification for this step. We refer to stakeholder theory (e.g., [22]) or enterprise architecting methods (e.g., [6, 23]) for guidance regarding this task. How to conduct concern elicitation is described in section 4.3 and here we exemplify our approach with sample models from our practical project. Section 4.4 presents structural patterns of concern models; section 4.5 presents our method that guides the identification of concerns utilizing these structural patterns.

## 4.1 Conceptual Model

Our ASTEAM approach to improve stakeholder orientation in EA is to explicitly model stakeholders and their concerns. In our opinion concerns like “functionality, performance, reliability, security, ..., cost, schedule, quality of service [7]” can hardly inform the definition of architecture viewpoints for an architecture description. We define a notation for the goal-oriented elicitation of stakeholders’ requirements and the derivation of concerns from these requirements, facilitating a more precise understanding of stakeholders’ concerns.

**Fig. 2** illustrates our concepts of GORE-based concern modeling in conformance to the ISO 42010 conceptual model of architecture description.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** ASTEAM conceptual model of GORE-based concern modeling in conformance to the ISO 42010 conceptual model of architecture description</figcaption></figure>

A *stakeholder* [has] *architecture-related concerns*, which s/he [considers important]. Groupings of the elements of *goal*, *belief*, *question* and *assessment* make up the concept of architecture-related concern. This is indicated by the dotted line drawn around these four elements. Each of these four elements can be related to a
stakeholder (i.e., [has / is important to]). Question, belief, assessment or another goal can be related to a goal. A common case is one goal [contributing to] another goal. An assessment describes a current situation, which positively or negatively [contributes to] (i.e., influences) a stakeholder's goal. A belief can be related to a goal in so far, that it indicates expectance of a positive or negative [contribution] (i.e., influence) to this goal. A question helps to formulate new goals (i.e., [leads to]) and supports goal refinement (cf. [24]). Moreover a question provides rationale for the existence of a goal. A question can be evoked (i.e., [called forth]) by a belief, a goal or another question. The *task* element is directly connected to the goal element. This is a [means-end] relationship. A task is required to be fulfilled in order to accomplish a stakeholder's goal. We do not consider the task element to be inside the concern boundary because we believe a stakeholder will not care about, who accomplishes a goal or how it is accomplished. By identifying stakeholders' concerns we are able to [reveal] their information demands in the form of *information objects*, which are relevant to them. According to our experiences, especially the question and goal elements are helpful in that regard. Therefore, these elements are directly connected to information object. Information objects are identified based on stakeholders' concerns, represented by their goals and questions. To actually develop an EAD, *viewpoints* are chosen, that [frame] the stakeholders' concerns.

Subsequently we explain the elements that are used in the ASTEAM concern model to render the concept of architecture-related concern more precise.

**Goal.** This is the central aspect in GORE and present in all goal-oriented modeling approaches. "A goal is an objective the composite system should meet" [25].

**Belief.** This element is inspired by the aforementioned practitioner workshop and the i* modeling notation [26, 27]. It is best described with the following quote: "A belief is a condition about the world that the actor holds to be true" [28].

**Question.** The *question* element is inspired by discussions led at the practitioner workshop. We aim to capture stakeholders' information demands with the question element, which tend to be expressed in the form of questions. We observed two things about questions: First, they can often be traced to a goal and second, they often lead to refined goals. This observation is backed by the Goal/Question/Metric method [24]. Thus, we find questions to provide valuable rationale for goal refinement.

**Assessment.** The Merriam Webster online dictionary defines an assessment as "the action or an instance of assessing: appraisal" [29]. Appraisal is defined as "a valuation of property by the estimate of an authorized person" [30].

**Task.** The *task* element is inspired by i* [27, 28], GRL [31] and KAOS [32]. The Merriam Webster online dictionary defines a task as "a usually assigned piece of work often to be finished within a certain time" [33].

**Information object.** Information objects are actual domain elements captured in different models defined by architecture viewpoints. Information objects are important in regard to concern elicitation since they are the actual, real-life objects of stakeholder interest that are to be captured in an EAD [34].

We would like to explain how we developed our notation. GORE has been identified as a possible means to reach an improved stakeholder orientation in EA by facilitating a more precise understanding of stakeholders' concerns (cf. [4]). We design ASTEAM to be compatible with the ISO 42010 standard representing typical
EA concepts and integrate common GORE concepts due to our proposition that these concepts hold for a reasonable representation of the notion of concern.

The concepts used in our notation originate from three streams of literature: (1) The ISO 42010 and related EA literature. We consider the standard itself as well as literature discussing it, which we found with a Google search for the terms "enterprise architecture iso 42010" and "enterprise architecture ieee 1471". (2) Common and widely cited GORE frameworks and approaches: i* [27, 28], GRL [31] and KAOS [32]. (3) Articles discussing the adoption of GORE in EA. We searched for such articles using various combinations of "GORE" and "EA" in abbreviated and non-abbreviated form using Google Scholar, IEEE Xplore and AIS Electronic Library. Few scholarly publications exist about leveraging GORE and GORM in enterprise architecture [15, 35]. Our search yielded one modeling approach: ARMOR [15], a goal-oriented requirements modeling language for enterprise architecture.

Our conceptual model contains these elements we identified in our literature analysis which are as well considered relevant by participants of our aforementioned workshop. **Table 1** illustrates the respective concepts and their origins.

<table><caption>**Table 1.** GORE and EA concepts and their origin</caption><thead><tr><th>Concept</th><th>i*</th><th>GRL</th><th>KAOS</th><th>ARMOR</th><th>ISO 42010 [7, 36]</th><th>Software cartography [34]</th></tr></thead><tbody><tr><td>Assessment</td><td>n n n</td><td>y y y</td><td>n n n</td><td>y y y</td><td>n n n</td><td>n n n</td></tr><tr><td>Belief</td><td>y y n</td><td>y y y</td><td>n n n</td><td>y y y</td><td>n n n</td><td>n n n</td></tr><tr><td>Concern</td><td>n y n</td><td>y y y</td><td>n n n</td><td>y y y</td><td>n n n</td><td>y n n</td></tr><tr><td>Goal</td><td>y y y</td><td>y y y</td><td>n n n</td><td>n n n</td><td>n n n</td><td>y n n</td></tr><tr><td>Information Object</td><td>n n n</td><td>y y y</td><td>n n n</td><td>n n n</td><td>n n n</td><td>y n n</td></tr><tr><td>Question</td><td>n n n</td><td>y y y</td><td>n n n</td><td>n n n</td><td>n n n</td><td>y n n</td></tr><tr><td>Stakeholder</td><td>y y y</td><td>y y y</td><td>n n n</td><td>y y y</td><td>n n n</td><td>y n n</td></tr><tr><td>Task</td><td>y y y</td><td>y y y</td><td>n n n</td><td>y y y</td><td>n n n</td><td>y n n</td></tr><tr><td>Viewpoint</td><td>n n n</td><td>y y y</td><td>n n n</td><td>y y y</td><td>n n n</td><td>y n n</td></tr></tbody></table>

"y" = concept exists in approach, "n" = concept does not exist in approach

## 4.2 Modeling Notation for Concern Elicitation

This section introduces the ASTEAM concern modeling notation. It is based on the i* visual syntax (cf. [26, 28]) because i* is a well-accepted GORM notation that allows to take goals of different stakeholders into account. We keep elements and symbols already present in i* and add elements for question, assessment and information object. Fig. 3 depicts the element symbols defined for our concern modeling notation.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Element-symbols used in an ASTEAM concern model</figcaption></figure>

The modeling rules of our modeling notation used in the concern models is illustrated in Fig. 4. The relationships of goal contribution, task decomposition and means-end
exist in the original i* notation [26, 28]. According to our conceptual model we add the following relationships: *assessment contribution*, *question decomposition* and *calls-forth question*. Elements and relationships we propose to elicit concerns have been explained on the basis of our conceptual model in section 4.1.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Modeling rules for an ASTEAM concern model</figcaption></figure>

## 4.3 Concern Elicitation

Aim of the concern elicitation step is to collect and capture stakeholders' requirements in an ASTEAM concern model in a GORE-based style. We assume that stakeholders have been identified prior to concern elicitation.

This phase identifies stakeholders' goals, questions, beliefs, assessments and tasks and the relations between them. Activities to collect these requirements are for instance workshops, interviews or document reviews. These requirements are captured in models as described in section 4.1 and 4.2. For each requirement the connection to the issuing stakeholder needs to be documented. The ASTEAM approach extends typical requirements engineering activities conducted in an EA undertaking.

We exemplify concern elicitation with sample models from our practice project. Our sources of requirements were interviews, strategy and contract documents.

The context for our sample models is as follows. Our IP's department is responsible for the "transfer" of aircraft computer units' software and the development environments required to build these software components. A number of computer units (LRU; line replaceable unit) are operated in both types of aircrafts for different purposes, making up the avionic system. Many different manufacturers produce these LRUs and their software. "Transfer" means our client has to be able to reproduce software builds, originally created by other manufacturers. These software builds have to be identical to the originally built software (SW). To ensure good software quality and meet strict aviation industry standards in software development, the IP's department has decided to conduct an EA project describing the department's baseline architecture to:

* Investigate review processes and the state of documentation guiding review activities;

* Inform the harmonization of processes as well as process documentation in case necessary; and

* Evaluate the options for information system support for review accomplishment and evaluation.
We consider two goals in our example – i.e., *Comprehensive taxonomy of “Reviews”* and *Clearly defined review actions*. These goals are part of the overall objective to understand what reviews are conducted by teams of the department and how these reviews are conducted. The first author led and analyzed interviews as well as strategy and contract documents to gather requirements as done in traditional RE. Gathered requirements were analyzed for goals, questions, beliefs, assessments and tasks. Partly, requirements were rephrased in this process to exhibit a model-handleable form. In **Fig. 5** we show the exemplary model capturing the two goals *Comprehensive taxonomy of “Reviews”* and *Clearly defined review actions*.

<figure><img src="image_6.png" /><figcaption>**Fig. 5.** Sample of the project’s concern model</figcaption></figure>

The customer wanted us to discover which teams conduct what types of reviews and to clearly define these review actions. These objectives were named in interviews as well as the contract document. Both goals are in a means-end relationship with the task *EA effort “Review Support”* because they represent main requirements of the IP. Since both goals are rather imprecise, they are further refined. The goal *Comprehensive taxonomy of “Reviews”* leads to a question (i.e., *What review activities exist*). This question calls forth another question (i.e., *How are review activities embedded in SW dev. Process*). Decomposition of these two questions yields the more precise goals *SW development process captured* and *Overview of review activities exists*. Further on, means-end tasks are captured, which shall be performed to achieve the respective goals. The refinement of the goal *Clearly defined review actions* works in a similar way and is not discussed in detail for the sake of brevity.

Up to now the model is mostly identical to what a traditional goal model would yield – apart from some additional concepts being captured (e.g., question elements providing additional rationale for goal refinement). We find that this model captures motivation and vision of the EA undertaking much explicit than often done in EA.
For each model element we maintain meta information, most importantly associated stakeholders. This way we can trace requirements back the respective stakeholders allowing us to identify who has which goals or questions; or who is considered responsible for a certain task. Capturing this information in the form of a stakeholder element directly in the model would make the models more difficult to read and understand; maintainability would be impaired as well. To capture structured attribute information about goals and beliefs we use business goal scenarios as described by Clements and Bass [19, 20].

Once stakeholder requirements are captured in a concern model it forms the foundation for the next step – i.e. concern identification.

## 4.4 Structural Patterns for Concern Identification

We define a model-structure-based concern identification method, which offers guidance to an otherwise merely subjective concern identification process. We propose structural patterns guiding concern identification for every possible element link (e.g., contribution, decomposition, etc.). These patterns are a result of our concern identification experiences in the project as well as based on common sense considering the link semantics. Three exemplary patterns are presented in **Fig. 6**. The direction of traversal defines in which direction concern identification is conducted.

<figure><img src="image_7.png" /><figcaption>**Fig. 6.** Structural patterns guiding concern identification</figcaption></figure>

The *means-end pattern* represents a conditional statement: If task T is means-end to goal G, then T is of the same concern as G. This means if G is considered to belong to a certain concern, T belongs to that concern as well.

The *decomposition pattern*, which is relevant for tasks and questions, indicates that an element's sub-elements are of the same concern or of a sub-concern (cf. [37] on aggregation of concerns): If composition-parent P is of concern C, composition leafs L1-Ln are most likely of concern C as well. Depending on individual judgment, L1-Ln might belong to sub-concerns of C (i.e., C<sub>a</sub>, C<sub>b</sub>, etc.). Using this pattern concern identification still depends on the discretion of the architect but it provides guidance by determining that L1-Ln to not belong to a completely different concern.

The *calls-forth question* pattern is relevant for all element combinations that describe the forth calling of a question (i.e. goal, belief, question). Based on a goal, belief or question another question is formulated which represents a stakeholder's demand for more information. From our experience the pattern indicates the
identification of the same or a sub-concern for the questions being called forth.
However, both elements (i.e., the source element E and the question Q being called
forth) might as well be of different concerns if the architect's rationale suggests so.

**4.5 Concern Identification**

Aim of the concern identification step is to identify architecture-related concerns
based on the requirements captured in an ASTEAM concern model. We define a
method for concern identification comprising the following steps:

1. Determination of concern-belonging for the concern model elements. This is conducted in a depth-first search (DFS) manner combined with use of our patterns introduced in section 4.4. Concern-ids are assigned to model elements, where different numbers represent different concerns. Elements with multiple concern-ids assigned are taken into account for the generalization of multiple concerns.

2. Highlighting of concerns (i.e., groupings of requirements elements).

3. Phrasing of concerns – i.e., giving the concern groups a name.

4. Analysis of inter-concern dependencies.

As a result every concern model element is assigned at least one concern.

We continue our example (cf. section 4.3) by conducting the aforementioned steps
resulting in the model depicted in **Fig. 7**.

<figure><img src="image_8.png" /><figcaption>Fig. 7. Concern model after concern identification is completed</figcaption></figure>

We start to assign concern-ids with the top-left-most element, connected to the task
that represents our EA effort. Thus, we start with the goal element *Comprehensive*
taxonomy of "Reviews", which is assigned a (1). The calls-forth pattern is used to assign a concern-id to the connected question *What review activities exist*. We consider it a sub-concern and thus assign the id (1.a). The contribution relationship to goal *Clearly defined review actions* is not used for concern identification, since this relationship is not considered helpful to guide concern identification; the goal is not assigned a concern-id at this point. For concern identification of the question's (i.e., *What review-activities exist*) related elements we use the *calls-forth* and *decomposition* pattern. We consider the question *How are review activities embedded in SW development process* representing a sub-concern (1.a.1); asking about how review activities are anchored in the whole of activities conducted during SW development. It is therefore a more specific aspect of the original concern regarding review activities in general. The question is further decomposed to the goal *Overview of review activities exists*. We decide not to annotate a sub-concern but keep the concern (1.a). We use the decomposition and means-end patterns for concern identification for the remaining elements of this part of the graph. Once the last element in a part of the graph is reached, concern identification continues with the element at the top-left-most position, which has not yet been assigned a concern-id; DFS will inform the decision which element to take. In most cases a new concern-id will be assigned to this element because top-level goals are often rather distinct and thus belong to different concerns. In our case it is the goal element *Clearly defined review actions*, which we assign concern-id (2). Further pattern-based decomposition leads to the resulting concerns shown in Fig. 7.

We group concerns with equal concern-ids by drawing colored boundaries around them. The colors are used to distinguish different concerns and have no special meaning. **Table 2** summarizes the concerns we identify based on the underlying concern model. Concern names are chosen by discretion of the architect. Our conceptual model and the chosen concern subjects represent a concern understood as a stakeholder's area of interest in a canonical, goal-oriented and practitioner-friendly way. We call it practitioner-friendly because the elements making up the concept of concern can easily be perceived and captured in interviews or meetings with relevant stakeholders. Note that we do not try to provide an answer to the question what a concern is in an epistemological sense.

<table><caption>**Table 2.** Concerns identified on the basis of the concern model</caption><thead><tr><td>Id</td><td>Concern</td></tr></thead><tbody><tr><td>1</td><td>Taxonomy of "reviews"</td></tr><tr><td>1.a</td><td>Review activities</td></tr><tr><td>1.a.1</td><td>Anchoring of review activities in SWM process</td></tr><tr><td>2</td><td>Review actions</td></tr><tr><td>2.a</td><td>Review-relevant LRU artifacts</td></tr><tr><td>2.a.1</td><td>Conducted reviews overview</td></tr><tr><td>2.b</td><td>Review participants</td></tr></tbody></table>

We identify inter-concern dependencies, which are colored red in Fig. 7. Inter-concern dependencies are helping viewpoint identification in a later step of the ASTEAM method. The relationships between concern model elements help to determine relationships between different concerns. We utilize *goal contribution* and
calls-forth links to investigate inter concern relationships, since these links connect model elements belonging to different concerns. For instance a goal belonging to concern A contributing to a goal belonging to concern B indicates an inter-concern relationship between these two concerns. Another indication of two or more concerns being in a relationship with each other is one model element being assigned two or more concern-ids. This is the case with three elements in the model displayed in Fig. 7.

The immediate benefit of the concern model after the conduct of our method is the stakeholder-oriented identification of concerns and a thorough understanding these concerns. Moreover the inter-concern dependencies help to inform the selection and/or definition of architecture viewpoints. A convenient by-product of the model is the identification of a project's work packages – in case they have not been defined at this stage of the project; the task elements of the concern model resemble a large part of the work packages defined for our project.

# 5 Conclusions and Discussion

The concept of architecture-related concern is rather dim and hard to observe or investigate in practice. Although EA frameworks and procedure models acknowledge the importance of RE, they hardly consider method support specifically guiding elicitation and identification of stakeholders' concerns. Typically, it also remains unclear how knowledge about concerns should be captured and documented.

In the article at hand we present the concern elicitation and identification part of our ASTEAM approach for stakeholder orientation in EA modeling. We propose a conceptual model, a modeling notation and a method to guide and facilitate a more precise elicitation and identification of EA stakeholders' concerns.

Our goal is to achieve a stronger stakeholder orientation in EA. Can we achieve that with our concern modeling approach ASTEAM? Our initial application in a practical EA project shows promising results. Concerns are captured and derived from stakeholders' requirements allowing for traceability between stakeholders, requirements and concerns. When faced with communication of architectural knowledge related to a certain concern it is immediately clear which stakeholder(s) to address. Adopted in the practical project our approach yielded reasonable concerns and at the same time facilitated a precise understanding of these concerns and the inter-concern dependencies. This thorough understanding of concerns facilitated the determination of stakeholder-appropriate architecture viewpoints. Moreover our models provide valuable information about the vision for an EA undertaking – lack of such is named as a frequent issue in EA [3, 15, 35]. For these reasons we consider an ASTEAM concern model a worthwhile addition to an enterprise architecture description.

The additional workload caused by the adoption of ASTEAM was reasonable and in our opinion well worth the effort. ASTEAM is compatible to the ISO 42010 standard [7], which is well accepted by EA practitioners and research alike. It can be combined with existing EA frameworks without any problems or changes to the framework. We want to emphasize that argumentation, exemplification and results of
this work are fitted for the enterprise architecture domain. As ISO/IEC 42010 [7]
holds for all software intensive systems, we assume that a generalization to the field
of system architecture is feasible and sensible.

The results of the adoption of ASTEAM look promising so far. We intend to obtain
further empirical validation to support these first insights and eventually enhance
ASTEAM.

6 References

1. Aier, S., Kurpjuweit, S., Riege, C., Saat, J.: Stakeholderorientierte Dokumentation und Analyse der Unternehmensarchitektur. In: Hegering, H., Lehmann, A., Ohlbach, H., Scheideler, C. (eds.) INFORMATIK 2008: Beherrschbare Systeme – dank Informatik, vol. 2, pp. 559-565. GI/Köllen, München (2008)

2. Kurpjuweit, S.: Stakeholder-orientierte Modellierung und Analyse der Unternehmensarchitektur unter besonderer Berücksichtigung der Geschäfts- und IT-Architektur. Inst. für Wirtschaftsinformatik, doctoral thesis, pp. 419. Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG), St. Gallen (2009)

3. Lucke, C., Krell, S., Lechner, U.: Critical Issues in Enterprise Architecting – A Literature Review. 16th Americas Conference on Information Systems, Paper 305, Lima, Peru (2010)

4. Lucke, C., Lechner, U.: Goal-oriented requirements modeling as a means to address stakeholder-related issues in EA. In: Bernstein, A., Schwabe, G. (eds.) 10. Internationale Tagung Wirtschaftsinformatik, pp. 714-723, Zürich, Switzerland (2011)

5. Niemi, E.: Enterprise Architecture Stakeholders - a Holistic View. 13th Americas Conference on Information Systems, Paper 41 (2007)

6. The Open Group: TOGAF Version 9 - The Open Group Architecture Framework (TOGAF). The Open Group (2009)

7. International Organization for Standardization: ISO/IEC 42010 (WD4). Systems and Software Engineering — Architecture Description, (2007)

8. Cheng, B.H.C., Atlee, J.M.: Research Directions in Requirements Engineering. 2007 Future of Software Engineering, pp. 285-303. IEEE Computer Society (2007)

9. Nuseibeh, B., Easterbrook, S.: Requirements engineering: a roadmap. Conference on The Future of Software Engineering, pp. 35-46. ACM, Limerick, Ireland (2000)

10. Lamsweerde, A.v.: Goal-Oriented Requirements Engineering: A Guided Tour. 5th IEEE International Conference on Requirements Engineering, pp. 249-262 (2001)

11. Bender, G.: Designing a Stakeholder-Specific Enterprise Architecture Management based on Patterns. sebis, master's thesis, pp. 136. TU München (2009)

12. Chief Information Officer Council: A Practical Guide to Federal Enterprise Architecture. (2001)

13. Lankhorst, M., Quartel, D.: Architecture-Based IT Valuation - Supporting portfolio management and investment decisions. VIA NOVA ARCHITECTURA (2010)

14. Op't Land, M., Proper, E., Waage, M., Cloo, J., Steghuis, C.: Enterprise Architecture: Creating Value by Informed Governance. Springer, Berlin (2009)

15. Quartel, D., Engelsman, W., Jonkers, H., van Sinderen, M.: A Goal-Oriented Requirements Modelling Language for Enterprise Architecture. IEEE International Enterprise Distributed Object Computing Conference, pp. 3-13 (2009)

16. Schekkerman, J.: How to survive in the jungle of enterprise architecture frameworks: creating or choosing an Enterprise Architecture Framework. Trafford Publishing (2004)
17.Buckl, S., Ernst, A., Lankes, J., Matthes, F.: Enterprise Architecture Management Pattern Catalog (Version 1.0, February 2008). Technical Report TB0801, Chair for Informatics 19 (sebis), Technische Universität München (2008)

18.Chair for Informatics 19 (sebis). EAM Pattern Catalog, http://www.matthes.in.tum.de/wikis/eam-pattern-catalog/home. Accessed June 6, 2011.

19.Clements, P., Bass, L.: Using Business Goals to Inform a Software Architecture. 18th IEEE International Requirements Engineering Conference (RE), pp. 69-78 (2010)

20.Clements, P., McGregor, J.D., Bass, L.: Eliciting and capturing business goals to inform a product line's business case and architecture. 14th international conference on Software product lines: going beyond, pp. 393-405. Springer-Verlag, Jeju Island, South Korea (2010)

21.Bortz, J., Döring, N.: Forschungsmethoden und Evaluation für Human- und Sozialwissenschaftler. Springer, Berlin (2006)

22.Mitchell, R.K., Agle, B.R., Wood, D.J.: Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What Really Counts. The Academy of Management Review 22, 853-886 (1997)

23.Spewak, S., Hill, S.C.: Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. QED Publishing Group (1993)

24.Solingen, R.v., Berghout, E.: The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development. McGraw-Hill (1999)

25.Lamsweerde, A.v.: Handling Obstacles in Goal-Oriented Requirements Engineering. IEEE Transactions on Software Engineering 26, 978-1005 (2000)

26.Yu, E.: Modelling Strategic Relationships for Process Reengineering. Graduate Department of Computer Science, vol. Doctor of Philosophy, pp. 178. University of Toronto (1995)

27.Yu, E.S.K.: Towards modelling and reasoning support for early-phase requirements engineering. 3rd IEEE Int'l Symposium on Requirements Engineering, pp. 226-235 (1997)

28.i* Wiki. http://istar.rwth-aachen.de. Accessed 07.08.2010.

29.Free Merriam-Webster Dictionary. Assessment, http://www.merriam-webster.com/dictionary/assessment. Accessed 9 February, 2011.

30.Free Merriam-Webster Dictionary. Appraisal, http://www.merriam-webster.com/dictionary/appraisal. Accessed 9 February, 2011.

31.International Telecommunication Union: Z.151 : User requirements notation (URN) - Language definition. (2008)

32.Lamsweerde, A.v., Letier, E.: From Object Orientation to Goal Orientation: A Paradigm Shift for Requirements Engineering. In: Goos, G., Hartmanis, J., Leeuwen, J.v. (eds.) Radical Innovations of Software and Systems Engineering in the Future (Lecture Notes in Computer Science - LNCS), vol. 2941, pp. 153-166. Springer, Berlin (2004)

33.Free Merriam-Webster Dictionary. Task, http://www.merriam-webster.com/dictionary/task. Accessed 9 February, 2011.

34.Lankes, J., Matthes, F., Wittenburg, A.: Architekturbeschreibung von Anwendungslandschaften: Softwarekartographie und IEEE Std 1471-2000. Software Engineering 43-54 (2005)

35.Yu, E., Strohmaier, M., Xiaoxue, D.: Exploring Intentional Modeling and Analysis for Enterprise Architecture. 10th IEEE International Enterprise Distributed Object Computing Conference Workshops, (2006)

36.Emery, D., Hilliard, R.: Every Architecture Description Needs a Framework: Expressing Architecture Frameworks Using ISO/IEC 42010. European Conference on Software Architecture, pp. 31-40 (2009)

37.Buckl, S., Krell, S., Schweda, C.M.: A Formal Approach to Architectural Descriptions – Refining the ISO Standard 42010. In: Albani, A., Dietz, J.L.G. (eds.) Advances in Enterprise Engineering IV, vol. 49, pp. 77-91. Springer Berlin Heidelberg (2010)