1 Introduction

After the global financial crisis in 2007, a significantly increasing number of regulations addressing national, European and international financial markets forced financial organizations to implement a holistic RCM [1]. Kharbili defines RCM as the task “…of ensuring that enterprises are structured and behave in accordance with the regulations that apply …” [2]. Thus, financial institutes need to be aware of the relations among their strategy, processes, applications and infrastructures to be able to rapidly react on complex and changing regulatory requirements. The EA research domain contributes to this purpose by providing methods and tools to establish a more holistic perspective on organizations [3, 4]. EA models represent different architectural layers of an enterprise, such as business, application and technology architecture [5]. Since EA projects are highly time- and resource-consuming, organizations would benefit from reference models for EA. A Reference Enterprise Architecture (R-EA) can be defined as a generic EA for a class of enterprises that is used as foundation in the design and realization of the concrete EA [6]. In prior work we developed a reference compliance organization (R-CO), which uses R-EA structures and was developed by adapting methods from the reference modeling (RM) research domain [7]. Since the R-CO aims to be used by financial organizations to improve their RCM, an application design has to be provided to R-CO users. Although there exists research in both fields of RM application [8] and R-EA development [9], IS research lacks in giving guidance how to develop a sufficient R-EA application design. Hence, the research objective of our work is to develop an application design for the R-CO. To reach this aim we deploy a design DSR, which is presented in Sect. 2 and guides this work’s structure.

2 Research Design

We structure our work in terms of the DSR methodology suggested by Peffers et al. [10]. Based on discussing literature on RM application we present an application design of the prior developed R-CO as this work’s artefact. We define an application design as a framework, which systematically documents in what context the R-CO can be applied and what benefits it offers to its user. Peffers et al. define five activities for DSR projects (i–v). We performed them as follows:

The (i) problem identification revealed the need for a sound application design for the R-CO, since an absence of such was identified in IS literature (see Sect. 1). Consulting related literature in the general RM domain we identified relevant aspects in the RM application domain and clarified the requirements towards the artefact during the DSR process (ii) define the objective for a solution (see Sects. 3.1 and 3.2). During the step (iii) design and development we built a framework for RM application (Sect. 3.3) and elaborated an application design for the R-CO that contains various application scenarios (see Sect. 4). One of these application scenarios is (iv) demonstrated afterwards, which provided a first (v) evaluation of the artefact (see Sect. 5). On this basis, we discuss benefits and drawbacks of the presented artefact and draft future research in this domain (see Sect. 6).

3 Reference Model Application

RMs are information models developed for a certain problem in a certain application domain in order to be reused by a specific enterprise of that domain. RMs are characterized by their universality, recommendation and reusability [11]. The life cycle of RMs can be distinguished between the phase of construction and the phase of application [12]. However, these phases cannot be distinctively delineated from each other. For example, the designer of a RM may have concrete beliefs how the model should be applied. Meanwhile, the user of the RM may have a different perception of the model’s value [13]. Therefore, Fettke and Loos suggest a phase that integrates with both and call it “reuse”, in which the RM designer prepares the model for its reutilization and the RM user retrieves it [8]. We contribute to a more precisely definition of the reusability attribute of RMs and thereby suggest an artefact that supports the reuse and application phase of the RM lifecycle. Before presenting the RM application framework (Sect. 3.3) and its application the R-CO (Sect. 4), we discuss the value of RMs (Sect. 3.1) and analyze literature that investigates RM application (Sect. 3.2).

3.1 The Value of Reference Models

In order to justify the effort of RM application, the RM user (e.g. an enterprise) has to understand a RM’s value. IS researchers do agree that the main value of RMs is to make the design and development of information systems more efficient and effective [14, 15]. Becker and Knackstedt explicitly state metrics that describe the economic effects RM applications offer from a user perspective: a decrease in costs due to the reusability; a decrease of modeling time for enterprise-specific models; an increase of the model quality; a competitive advantage; and, a decrease in modeling risk since reference models are already validated [16]. Other IS researchers agree with these metrics [14, 17].

Despite this consensus, IS research misses to empirically investigate the value of reference models [18]. Only two contributions were identified that conducted a cross-sectional analysis of reference model application benefits. Schütte surveyed 22 RM users and his findings revealed that most RM users applied the RMs primarily for means of cost reduction. Only a minority did so for aspects of proceeds or risk mitigation. In concrete, the majority of RM users stated efficient realization of organizational concepts and the minimization of software lead times as the main reasons for RM application. Interestingly, more than every second RM user stated that they further observed unquantifiable effects. Unfortunately, Schütte did not inquire them explicitly [14]. These findings could imply that both the RM designers and the RM users are not completely aware of the value a RM can generate.

Fettke interviewed users of the Supply Chain Operations Reference Model (SCOR) [18]. The basis of his study was the hypothesis that the success of reference modeling depends on RM application. He operationalized these two variables and interviewed 153 enterprises of the Supply Chain Council. He evaluated how the degree of SCOR application influenced the success of supply chain management. To measure success, he used three of the earlier mentioned metrics (i.e. costs, time, and quality) and added flexibility. His findings show that the SCOR model application had a significant positive influence on the success on supply chain management. Further, he concludes that the RM application enhances the effectivity and efficiency of considered information systems development. Still, his findings are based on cross-sectional data and are yet to be verified by a longitudinal study that analyzes the effects of the SCOR model application in a longer period in certain use cases.

Based on these finding one can derive that the application of reference models offers various advantages to the RM user. Nevertheless, there are also disadvantages a user has to be aware of before applying RMs. First, the application of RMs may negate an already existing competitive advantage since competitors can gather the same knowledge. Second, the maintenance and especially the adjustment to an enterprise-specific context can be time- and resource-consuming. Last, the application of a complex RM requires high knowledge [18]. In consequence, Fettke argues that the sole existence of a RM does imply neither its value nor its success if it is applied. More certainly this depends on the context, in which the RM is applied [18]. For example, Hars mentions highly regulated domains as a suitable reference models application context [19]. Therefore, the analysis of a RM’s intended value is an essential aspect when developing its application design. Such an analysis and its documentation within the RM may mitigate the risk of a diverse value perception between RM designer and user. Thus, we deem it essential to create a shared understanding of a RM’s value among RM designer and RM user by documenting its application design by dint of a framework.

3.2 Aspects of Reference Model Application

The majority of research activities focuses on RM construction, while research regarding RM application is scarce [15]. Nevertheless, few methodological works exists.

Fettke and Loos suggest a procedural model that they attach between the construction and application process and name it “reuse”. The main processes therein are: (i) design of RM reusability, during which the designer makes the RM accessible; (ii) RM retrieval, during which the user searches, selects and procures the RM; (iii) RM adjustment, where the user might change the RM for his or her specifics; and, (iv) evaluation, where both designer and user change feedback of the process, such as problems or experiences. To support the procedure of reuse the authors characterize RMs by static means: model type, perspective on structure or behavior, and modeling language [8].

Based on his procedure for RM construction, Schütte describes how to apply model in two different application scenarios from the perspective of the RM user [14]. This procedure requires the RM to be already prepared for its application and, thus, may be used after the reuse procedure from Fettke and Loos. Becker and Knackstedt provide a procedure model for the application of configurative RMs [16], which can be seen as an equivalent of their procedure model for configurative RM construction [20].

Further, vom Brocke defines five design principles for both RM construction and application [13]. From the perspective of the RM user, such principles support the RM adjustment during its application. Wolf argues that it is hardly possible to develop scientific methods for RM application. He understands it as a communication task between the RM designer and user, who may not instantly comprehend the RM’s value [21]. Thus, he suggests documenting the intention, context, the addressed problem and the suggested value. This is in line with the prior depicted argument that the RM application is context-dependent. We conclude that this may take place in the application preparation of a RM.

In line with Wolf we argue that it is important for both the RM designer and the RM user to explicate possible application scenarios [21]. Analyzing related literature, we identified typical application scenarios presented in Table 1.

Table 1. Overview on application scenarios in the literature
Full size table

3.3 An Application Framework for Reference Models

We understand the application design of a RM to be an important instrument for a successful application process. In consequence, this section summarizes prior depictions using an application framework that contains six application aspects, which should be considered when preparing and conducting RM application. We motivate this with the works by Fettke and Wolf, who agree that the application of a reference model is vague, depends on its context and is full of pitfalls due to implicit knowledge that it requires [18, 21]. Thus, we suggest the presented aspects as a useful tool for the application process of a RM. Not only does it help RM designers after and during the construction process, but further improves the quality of communication with the RM user as well as it concretizes his or her expectations.

The framework for RM application in Table 2 expresses each of the six application aspects by various application items, which we identified in related literature. All aspects can be related to the process steps for RM reusability provided by Fettke and Loos (see Sect. 3.2) [8]. While aspect (1) RM Specifics relates to the static characteristics defined in [8], aspect (2) RM Reuse addresses the strategy of the model designer how to make the RM available. Both (1) and (2) relate to the (i) reusability design from [8]. Then, aspect (3) RM communication recommends the designer to document the addressed problem and what different stakeholders might be addresses by the RM. This enhances the interface between process (i) and (ii) RM retrieval. In the latter process (ii) the aspects (4) RM values and (5) RM application scenarios are important for the model user to make an informed choice for an appropriate RM. The value of an RM can both be documented by means of known metrics or model-specific values depending on what model scope is used by the RM at hand. Further, the RM designer should define different application scenarios addressing certain stakeholders and hold different values [18]. For the process (iii) model adjustment the model designer should define an (6) adjustment strategy, which – next to undefined compositional adjustments by the user – should include specific design principles appropriate for the problem domain, which need to be elaborated by the model designer during the construction process.

Table 2. Aspects for reference model application design
Full size table

4 Application Design of a Reference Enterprise Architecture

This section uses the framework for RM application design, which is presented in Sect. 3.3 and applies it to the specifics of a prior developed RM. The addressed problem domain of the RM is regulatory compliance in the financial domain. The RM aims to holistically represent all relevant aspects of the financial institute that is affected by regulation. In other words, the RM intends to support institutes to effectively and efficiently implement a RCM that uses an integrated IS approach. Therefore, the RM is based on the structure of EA models. In specific, we developed a “Reference Compliance Organization” (R-CO) using concepts and methods from the EA domain. In the following we present the application design of the R-CO by discussing the six aspects depicted above.

For reasons of comprehensibility we start with aspect (3) RM communication, which includes describing the addressed problem, the RM’s intention and the context it was developed in. The R-CO addresses the problem that financial institutions currently do not approach a coherent RCM systems and rather implement isolated solutions, which only realize single regulations due to short-term deadline of those [24]. Such isolated compliance solutions typically span organizational structures and processes supported by information systems and IT-based instruments [25]. The intention of the R-CO is to offer financial institutions a holistic model that captures common and best practices of RCM providing insights regarding organizational procedures, their interrelations with necessary information structures and an integrated IS support. At the moment, the R-CO focuses on the context of the German legal sphere and, thus, addresses German financial institutions. The R-CO addresses different stakeholders of the problem domain as RM users. First, (i) financial institutions can use the R-CO to build or improve a holistic RCM. Second, (ii) independent software vendors that focus on compliance systems for financial institutions can use the R-CO to advance their products or broaden their product range. Third, the R-CO is the body of knowledge (iii) business consultancies could use as a foundation in order to analyze their clients. Fourth, (iv) accountancy firms can use this body of knowledge as well as an auditing framework. And last, one day a complete, sound and thorough R-CO could be an instrument for (v) the Financial Supervisory Authority that represents a RCM standard.

Based on these considerations the R-CO has the following (1) RM Specifics. Using the categorization by Fettke and Loos for RM scope the R-CO represents an enterprise model, capturing the RCM division of financial institutions and focusing on both business and IS concepts [8]. Thus, the R-CO represents both behavioral and structural perspectives, i.e. it defines compliance processes but also necessary information structures. In this context, the R-CO uses the modeling language ArchiMate in its current version 3.0 [5]. It is based on The Open Group Architecture Framework and divides an EA model into a business layer, an application layer and a technology layer [26]. The R-CO utilizes the business (RCM structures and procedures) and application layer (information structures and IS utilized in RCM), because the infrastructural realization of the RCM is out of the problem domain’s scope. Further, the R-CO is structured by several architecture views that address certain concerns regarding the R-CO, like process responsibilities or application usage. On the one hand, the decision to use EA is sufficiently motivated from the perspective of the problem domain [24, 25]. On the other hand, it is in line with EA research findings, since EA models can be used as a regulative instrument (i.e. to guide enterprises in certain aspects) or an informative instrument (i.e. to enable decision making by sharing knowledge) [27].

The development of the R-CO was funded by a group of nine companies organized in a committee of the German IT-association Bitkom [28]. The companies’ representatives are experienced in the field of IT-based compliance as they operate as consultants and software vendors in this domain. In consequence, the (2) Approach for RM Reuse was developed within this committee. To date, the RM model is not publicly accessible and managed by both the Bitkom association and the participating companies. Potential RM user can retrieve the R-CO by contacting the right holders.

In general, the (4) RM Value of the R-CO is that it addresses a prevalent problem in the practice of RCM in the financial sector. As discussed in prior work both research and practice highlight the absence of reference models for RCM, which holistically offer insights from a business as well as an IS perspective and base on real-life scenarios and actual organizational behavior [1, 25, 29]. Depending on the different stakeholders that are addressed as potential RM users and further depending on the application scenario the value of R-CO application to the user may vary. With regards to the metrics described in [16] the R-CO designers claim the following advantages when applying the R-CO:

  • a decrease in costs since a correct R-CO helps institutes to avoid penalty charges when applied or a reduction of development costs for regulation-specific software development;

  • an improvement in quality due to transforming isolated RCM solutions into an integrated and IS supported RCM approach by applying best practice approaches;

  • the application of the R-CO mitigates the risk of the institute’s reputational and financial damage in case of an unidentified case of money laundering or fraud;

  • a decrease in expenditure of time from implementation of regulatory requirements.

The stated advantages are neither complete—since it highly depends on the application context—nor are the effects validated so far. However, they reflect the experiences made during the construction process and were elaborated together with the domain experts of the Bitkom committee. Although we do not completely exclude competitive advantage as a benefit of R-CO application, we do not specifically claim that an enterprise will gain a competitive advantage from it. The R-CO rather addresses a domain that financial institutes consider as a cost driver. However, an inefficient and ineffective RCM may result in a competitive disadvantage due to the damage regulatory violations cause. Next to these RM value metrics, the R-CO holds model-specific values. Since the R-CO uses EA structures, general benefits of EA are valid for the R-CO as well. For certain regulatory domain like money laundering or fraud prevention, the R-CO does not only capture necessary organizational processes, but further relates certain process steps to the demanded information and data structures and presents automation potentials due to integrated IS landscapes. The R-CO can be used as a TO-BE model and be compared to the AS-IS model of a certain financial institute [3, 27]. On this basis, migration paths can be derived in order to reach a state of holistic RCM implementation.

The R-CO holds various possible (5) RM Application Scenarios. They can be related to the above mentioned stakeholder and further to a value they create. The following Table 3 summarizes five R-CO application scenarios and documents addressed stakeholders as well as created values. The scenarios were developed together with the Bitkom committee and their potential was confirmed in interviews we conducted during the R-CO construction. While there are various scenarios how to use the R-CO, the extent to which the model is used may also vary. Fettke defines five dimensions of RM application, which can be transferred to the R-CO: breadth, detail, depth, volume and use of language [18]. The R-CO covers different regulations like anti-money laundering (AML) or prevention of other criminal acts. They can be applied altogether or separately as R-CO modules (breadth). Further, the R-CO consists of several level of details. While in one application context an aggregated model may be sufficient, another may require the detailed R-CO application (detail). Then, financial institutes or other RM users may intend to extend the application to their business partners in order to trigger some synergy effects (depth). Still, the RM user could also just realize certain segments of the R-CO (volume) or use another terminology for the phenomena described in the R-CO (use of language).

Table 3. Application scenarios of the R-CO
Full size table

In line with vom Brocke, we understand the construction process of the R-CO as “design for reuse”, which constructs the RM, but simultaneously considers mechanisms that support the RM user during the application [13]. Therefore, the R-CO uses the principles of aggregation and specialization. The different regulatory domains (e.g. AML) can be applied as modules or also be aggregated in order to utilize synergy effects when expanding the model scope. Moreover, the R-CO does not intend to cover the plethora of enterprise specifics for a single RM user. Thus, the model documents, where RM users have to specialize certain aspects (e.g. certain processes or application landscapes). Next to these design principles the R-CO user most likely will require adjustments, we did not consider during the construction (compositional adjustments). Based on our experience in applying the model we identified the need to mark compulsory R-CO elements (e.g. aspects that are definitely required by regulations) and optional elements, which may include best practices that improve the RCM but may not be necessary to comply with the law.

5 Results of a First Application Use Case

In order to demonstrate the application of the R-CO in more detail, this section illustrates one application scenario that is stated in Sect. 4. In the context of a two-day workshop we applied the R-CO at a German financial thrift institute using application scenario (I) Gap Analysis with Individual Models.

Next to the workshop facilitator and EA modeler, two employees from the thrift institute participated for the whole course of the workshop: the institute’s chief compliance officer and anti-money laundering manager, who holds this position for more than twenty years; his deputy, who is employed there for twenty years and also worked for more than five years in customer advisory. The overall objective of the R-CO application was to identify gaps between the institute’s as-is situation and the R-CO regarding two specific segments of the model: the onboarding process of business clients and the processing of suspected cases in the anti-money laundering (AML).

The workshop agenda was divided into six parts, while each day had a distinct focus. On the first day the as-is situation of the institute was examined. In the first part, the participants were surveyed regarding the general RCM approach of the institute. This aimed to understand how the participants understand and structure the field of RCM and its related tasks. Further, RCM domains were discussed and the two topics AML and onboarding were related to other domains. In the second part, we interviewed the participants about the AML process in detail. Therefore, we utilized the method of participative modeling using a facilitator’s toolbox, a whiteboard and a bulletin board [30]. While the facilitator worked together with the participants and asked questions, the EA modeler took notes of the spoken word and simultaneously structured the results in a first structure using an EA modeling tool—still, he asked questions at times. For this task, the team used a prior developed catalogue of questions that related to the aspects captured in the R-CO. Nevertheless, also additional questions were raised and answered during the session. In summary, they addressed organizational processes, used information structures and supporting information systems. Similar to this approach the third part focused on the onboarding process. After these sessions, the facilitator and EA modeler reviewed the results and developed an as-is EA model based on the gathered material. This institute’s EA model was constructed using the same structure and ArchiMate views as the R-CO is based on. It captured AML and onboarding processes, information structures and application landscapes.

The objective of the second workshop day was to identify similarities and differences between the institute and the R-CO. After a short introduction of the R-CO and the ArchiMate modeling language, we performed a gap analysis using a professional modeling tool. The tool helped us to visualize the similarities and differences of the models and proofed to be a very conducive approach to trigger reasoning about them. Different reasons for such differences emerged: (a) parts were missing in the institute EA model because it wasn’t discussed on during the modeling sessions; (b) there was a misunderstanding between the participants and the workshop team; (c) aspects captured in the R-CO did not apply to the institute; (d) the institute applied processes that were not captured by the R-CO yet, since they were just implemented after the R-CO construction; and, (e) the R-CO unveiled room of improvement of the institute’s compliance approaches. While case (a) and (b) are often observed in modeling sessions [30], cases (c) and (d) confirm claims by vom Brocke—saying that RM application also should integrate a feedback loop to the RM designer [13]. Nevertheless, the most interesting discussions emerged in case (e). Without any further input, both participants directly started thinking whether missing elements should be implemented in their compliance division and why. In Fig. 1 a simplified model view illustrates the gap analysis for the IS support of the AML case handling process. While the institute by the time of the workshop already used a new system for the official reporting instead of a fax system (case d), discussion arose whether the support of a risk analysis system and sanction screening should be implemented in the institute’s process (case e). At the end of the workshop the participants were asked for consultation to completely understand the process or data set at discussion and whether they should integrate it in their organization. Later, the participants especially assessed the visualization of the models from the first day and its transparent comparison as very helpful. Further, they never felt lost or misunderstood. In addition, the participants agreed with our overall approach for using EA structures for the R-CO and pointed out that the R-CO together with the application scenario helps institutes to understand their current state in RCM.

Fig. 1.
figure 1

GAP analysis of the AML case handling IS support (red element indicate elements the institute did not implement) (Color figure online)

Full size image

6 Discussion and Conclusion

Using a DSR methodology, we develop a structured application design for the Reference Compliance Organization (R-CO). After discussing the problem at hand, we analyze related literature from the reference modeling domain to derive a basic application framework that can be understood as an interface between R-CO designers and R-CO users. It depicts the value of the R-CO and describes different aspects of the application – such as addressed stakeholders, application scenarios or adjustment mechanisms. For demonstration purposes, a concrete application scenario is presented. We contribute to the IS research community by deducing relevant aspects of RM application, present their application to R-EA specifics and elaborate application scenarios for R-EA application. Further, practitioners from the financial domain gain insights how the R-CO support their regulatory compliance management (RCM). From the perspective of validity, we already evaluated one application scenario in detail as depicted in the demonstration use case. Further, scenario (II) development of compliance software was also verified since one IS vendor of the Bitkom committee expanded his product range based on the R-CO. Nevertheless, the remaining scenarios are still to be evaluated. To date, they are based on expert’s experiences from the RCM domain. The main direction of future research is to further evaluate and expand the application scenarios. For example, to use the R-CO to build a coherent RCM for a certain institute (scenario IV). This may result in a more advanced adjustment mechanisms of the R-CO according to [13]. This will also raise detailed conclusions regarding the R-CO’s value.