Resumen Ejecutivo (español)

Another important part of our findings in order to establish a continuous EA assessment is the awareness of the necessities to achieve goals in a desired manner, namely requirements. They state what functional and constructional properties an artefact should have dependent on stakeholder goals (Greefhorst and Proper 2011). Additionally, they form the basis for evaluation criteria (cf. Sec. 6.5.1) and are closely related to EA principles which drive requirements design and conversely impact the design of architecture principles (cf. Sec. 5.1.3). These requirements are part of the method design and therefore part of our main research question. Requirements management plays a central role in the TOGAF Architecture Development Method (ADM) (The Open Group 2011b) as it is continuously driven by a requirements management process. Thereby, the ability to cope with changes in requirements is crucial. Stakeholders have goals that are supported by requirements. When defining requirements, we need to take assumptions, constraints, principles, policies, and standards into account as these are present in the organizational environment. Incorrect requirements are largely responsible for failure of

information system projects (Hsu et al. 2012). We need to be aware of the fact that despite properly defining requirements, there exists a gap in practice between requirements fulfilment and user acceptance and hence adoption for different stakeholders (Gohmann et al. 2013). Requirements impact the definition of principles (cf. Sec. 3.1.4) which ensure their attainment. Moreover, requirements impact the design of EABV assessment approaches whereas principles guide their design. The resulting view on requirements in context is depicted in Figure 4-1.

Figure 4-1: EABV requirements in context

(Bernus and Nemes 1997) distinguish between strategic and technological requirements. For our purposes, we discern four types of EABV assessment requirements (Robertson et al. 2006) which also comprise strategic and technological requirements:

 Business requirements capture the needs from a business managerial perspective and deal with financial and strategic issues as well as organisational aspects and participating stakeholders.

 Architectural requirements frame the scope and integration issues for assessments. In addition, the adherence to architecture principles, policies, and standardisation is handled.  Functional requirements target the actual execution of process-based assessments and define the necessary specifications for users, i.e. stakeholders conducting the assessments. Additionally, they are concerned with technological intricacies. Functional requirements are handled by many methodologies, especially in software architectures (Chung et al. 1999).

 Non-functional requirements elaborate qualitative issues regarding the input and output of the assessments, e.g. data quality and reasonable reports.

When looking at related work, we can find few well defined requirements. Hence, we want to formulate requirements for continuous EA assessments. When designing IT artefacts for an organizational context we need to be aware of what our method needs to achieve in what manner given this context. In Table 4-8, we summarize the requirements for our EA assessment method. For each type of requirements, we list several requirement statements that can be subsumed to a particular requirements class. A requirement class is the quality of an IT artefact that a given requirement will impact to achieve and sustain its intended purpose or objective respectively. Architectural qualities are often expressed as requirements (Gross and Yu 2001) which therefore can be stated for IT artefact qualities. Our DSR profile (cf. Sec. 2.5) effects these IT artefact qualities which become especially relevant when choosing DSR evaluation criteria (cf. Sec. 6.3).

Type Requirement Statement Requirement Class DSR Profile

Business

 Must be feasible

 Must integrate into current

practices

 Overhead must be minimized

 Must improve decision making

 Feasibility  IT flexibility  IT efficiency  Utility  Practicality  Flexibility  Practicality  Practicality Architectural

 Must be adequately scoped

 Must integrate into current

practices

 Must adhere to EA principles and IT Building Codes (Policies)  Must be aligned with the EA

framework   IT flexibility  Conformance  IT flexibility  Simplicity  Flexibility  Conformance  Evolvement Functional

 Must provide user interface  Must be supported by current tools

 Must close feedback loop on

project scope

 Must be aligned with periodic (maturity) assessment  Utility  IT flexibility  Utility  Utility  Practicality  Flexibility  Practicality  Flexibility Non- functional

 Results must possess a certain quality

 Results must be meaningful

 EABV assessment must be

understandable  Data quality  Data quality  Understandability  Rigor  Rigor  Simplicity

Feasibility is an important requirement class for all IT artefacts since it determines whether a project or a set of activities in general is able to be executed within given constraints such as budget and personnel availability. Feasibility is a consequence of the practicality demand in the DSR profile (cf. Sec. 2.5). Moreover, feasibility becomes relevant for our evaluation and will be discussed in Section 6.3.1. Flexibility is of major concern for our approach. In management literature, it is defined as the ability of a resource (asset) to be used for more than one end product (Duncan 1995). In that regard, IT artefacts are in fact assets. As we outlined in our DSR profile (cf. Sec. 2.5), flexibility in terms of design science means that we must employ a research process that is able to cope with a change in requirements or the organizational environment respectively. Hence our DSR ABC inherently embraces dynamic environments and allows for defining and revising requirements for each of the IT artefacts as part of their design. In an information system context, flexibility is conceptualized along two dimensions (Byrd and Turner 2000): (1) modularity which is the capability to add, remove, or change IT artefacts easily avoiding major drawbacks, and (2) integration which is the capability to connect IT artefacts (connectivity) and to exchange information (compatibility). Efficiency is the ability to build and operate an IT artefact without wasting resources or assets respectively. In other words, it represents the relationship between the IT artefact output and the invested efforts to build it (Schmidt and Buxmann 2011). Efficiency is impacted by practicality in terms of the DSR profile. Conformance is characterized by the adherence of IT artefacts to certain rules, policies, or regulations. This is most relevant in the domain of IT and EA governance (cf. Sec. 3.1.3) and is also a criteria for the DSR profile. Utility means that an IT artefact must assist in some way to achieve business goals and benefit the organization (Österle et al. 2011). We also employ utility as one of our evaluation criteria (cf. Sec. 6.3.4). It is impacted by both, practicality and flexibility regarding the DSR profile. Data quality refers to the degree data represents the real-world construct and is fit for its intended uses. It is impacted by rigor. More on information and data quality including its dimensions can be found in (Heinrich et al. 2007; Pipino et al. 2002; Wang and Strong 1996). Understandability as a quality is the ability to grasp or know the meaning of built IT artefacts. It is greatly impacted by complexity or its antipode simplicity that determines how comprehensive an IT artefact is in terms of certain criteria, such as involved components and the nature and number of their relationships. Understandability is also a DSR evaluation criteria for our approach (cf. Sec. 6.3.4). It is impacted by a simplicity demand in terms of the DSR profile.

Since the list of requirements, qualities, and DSR research profile dimensions are adaptable, we need to mention that these may vary depending on the business need and organizational

environment. In the next Section, we describe our solution proposal and how to address the business need regarding all requirements.