Compliance Assessments of Projects Adhering to Enterprise Architecture

Compliance Assessments of Projects Adhering to Enterprise Architecture

Ralph Foorthuis, Frank Hofman, Sjaak Brinkkemper, Rik Bos
Copyright: © 2012 |Pages: 28
DOI: 10.4018/jdm.2012040103
OnDemand:
(Individual Articles)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

This article examines how to assess projects, which implement business processes and IT systems, on compliance with an Enterprise Architecture (EA) that provides them with constraints and high-level solutions. The authors begin by presenting the core elements of EA compliance testing. Next, the authors discuss the testing process and four types of compliance checks (i.e., correctness check, justification check, consistency check, and completeness check). Finally, an empirical case is reported in which a real-life project has been tested on conformance, demonstrating and evaluating the authors’ approach. The results indicate that objective compliance testing cannot be taken for granted. Therefore, several suggestions are presented to decrease the subjectivity of assessments, such as operationalization of EA prescriptions.
Article Preview
Top

Introduction

When studying the literature, Enterprise Architecture (EA) can be said to have two major ideal type functions. One function is to provide decision-makers with a clear and comprehensive descriptive overview of the organization, or relevant aspects thereof. Such insights into the enterprise form the basis for making high-level management decisions (cf. Johnson et al., 2004; Riempp & Gieffers-Ankel, 2007; Gammelgård et al., 2007), determining, e.g., which programs or projects to initiate. This reflective function of EA targets mainly managers as its users. The EA can be expected to demonstrate a heavy focus on depicting the (problematic) as-is situation. A second ideal type function of EA is to provide a prescriptive framework that guides and constraints subsequent development of business and IT solutions (cf. Kaisler et al., 2005; Boh & Yellin, 2007; Op ‘t Land & Proper, 2007; van Bommel et al., 2007; Foorthuis et al., 2008; Hoogervorst & Dietz, 2008; Meschke & Baumoel, 2010). This normative approach, focusing strongly on the to-be situation, should ensure that both enterprise-level and local initiatives within the organization are consistent with the overall strategy, and enable a coherent and integrated development of business, information and IT. This directive function of EA targets not only managers as its users, but also business analysts, system analysts, software architects and other roles in projects (re)designing the business and its IT support. In this article, we focus mainly on this latter function, a prescriptive EA providing constraints and high-level solutions to which business and IT systems – and in particular the projects implementing them – should conform. Prescriptive EAs prove to be common in practice. One example is the Enterprise Architecture of a manufacturing company, which uses principles, policies and models to ensure that business and IT initiatives are consistent with the business strategy (Bruls et al., 2010). Another example is a national statistical institute’s architecture, consisting of principles and models to which projects much adhere in order to save costs and increase the quality of statistical products (Foorthuis & Brinkkemper, 2008).

An EA’s norms or prescriptions are often applied in projects. Although EA typically focuses on the entire enterprise and compliance is indeed demanded at this level, in practice it is unrealistic for an entire organization to become EA-compliant at short notice. It can therefore be expected that conformance will be achieved incrementally at the local level, step by step – or rather, project by project (cf. Ross et al., 2006). However, philosophers have acknowledged for hundreds of years that, although compliance with ‘contracts’ might be better for the group as a whole and it might also be in an individual actor’s best interest to agree to contracts, it may not be in his interest to actually comply with them. In contractarian ethics this is one of the issues of the so-called compliance problem (cf. Gauthier, 1991; Hartman, 1996). Because of this potential conflict of interest, it should be tested whether actors actually conform to the contract. If we consider a specific project to be the actor, then an EA could be seen as the contract that needs to be complied with. In other words, although conformance is required for obtaining EA benefits, it cannot be expected to occur automatically (Boh & Yellin, 2007). This is especially relevant here as compliance with EA norms may be in the best interest of the organization as a whole, but not optimal per se to the local projects and departments that actually have to comply. Assessments should therefore be carried out at the level at which EA is applied, i.e., the project level. Testing at this level also allows for correcting non-compliant aspects, at least if it is performed while EA is being applied. Assessing projects on conformance is crucial, as a large survey study (n=293) has shown not only that project compliance with EA is positively associated with various strategic benefits, but also that the most important determinant of conformance is in fact conducting compliance assessments of projects (Foorthuis et al., 2010).

Complete Article List

Search this Journal:
Reset
Volume 35: 1 Issue (2024)
Volume 34: 3 Issues (2023)
Volume 33: 5 Issues (2022): 4 Released, 1 Forthcoming
Volume 32: 4 Issues (2021)
Volume 31: 4 Issues (2020)
Volume 30: 4 Issues (2019)
Volume 29: 4 Issues (2018)
Volume 28: 4 Issues (2017)
Volume 27: 4 Issues (2016)
Volume 26: 4 Issues (2015)
Volume 25: 4 Issues (2014)
Volume 24: 4 Issues (2013)
Volume 23: 4 Issues (2012)
Volume 22: 4 Issues (2011)
Volume 21: 4 Issues (2010)
Volume 20: 4 Issues (2009)
Volume 19: 4 Issues (2008)
Volume 18: 4 Issues (2007)
Volume 17: 4 Issues (2006)
Volume 16: 4 Issues (2005)
Volume 15: 4 Issues (2004)
Volume 14: 4 Issues (2003)
Volume 13: 4 Issues (2002)
Volume 12: 4 Issues (2001)
Volume 11: 4 Issues (2000)
Volume 10: 4 Issues (1999)
Volume 9: 4 Issues (1998)
Volume 8: 4 Issues (1997)
Volume 7: 4 Issues (1996)
Volume 6: 4 Issues (1995)
Volume 5: 4 Issues (1994)
Volume 4: 4 Issues (1993)
Volume 3: 4 Issues (1992)
Volume 2: 4 Issues (1991)
Volume 1: 2 Issues (1990)
View Complete Journal Contents Listing