Keywords

1 Introduction

Business/IT-alignment (BITA) was first documented in the late 1970’s and has been a top IT-management issue ever since [1]. This insight comes as no surprise as BITA realizes value from IT investments, ties the business and IT plan and drives competitive performance [2, 3]. Moreover, Lee and Kim [4] argue that BITA—resulting from specific socio-technical arrangements in organizations’ infrastructure—is positively associated with business performance.

According to Luftman [5], BITA refers to applying information technology (IT) in an appropriate and timely way, in harmony with business strategies, goals, and needs. He states that BITA focuses on the activities that management performs to achieve cohesive goals across the IT and other functional organizations (e.g., finance, marketing, human resources, manufacturing). Additionally, Luftman and Kempaiah [1] state that “alignment must focus on how IT and the business are aligned with each other; IT can both enable and drive business change.”

Henderson and Venkatraman [3] argue that alignment is the degree of fit (alternative labels for alignment) and integration among the domains of the business strategy, IT strategy, business infrastructure and IT infrastructure. The first two domains focus on the external environment, whereas the last two focus on the internal organization.

Recent studies argue that BITA is optimal when harmony and balance (or equilibrium) exist between organizational and system goals and dimensions [6, 7].

Within the current scope, we use the definition for BITA from Ullah and Lai [8]: BITA is the degree of fit between business and IT activities such as business strategy, business infrastructure, IT strategy and IT infrastructure, etc. This definition is consistent with the Strategic Alignment Model (SAM) [3], which is a widely recognized model for describing different perspectives of alignment. However, current alignment conceptualizations and models are abstract, hard to operationalize and therefore challenging to apply in practice. Another alignment problem is the complexity of organizations [9], which impacts decisions on IS development and alignment.

Given the above, this paper proposes the use of the Ampersand method [10]—a method that applies relation algebra as a requirements language to functional specifications—as a means to achieve and assure BITA. The Ampersand approach makes requirements within the requirements engineering phase of the software development process explicit and supports stakeholders to agree upon these requirements. Consequently, Ampersand employs business rules to formulate a solid foundation for information systems (IS) design and, ultimately, the design that meets business expectations.

Hence, we define the following research questions that drive this current paper:

  1. 1.

    How can the Ampersand method support the assurance of consistent and complete alignment of business and IT? And

  2. 2.

    Can we derive a model for BITA assurance based on the Ampersand method?

This paper is structured as follow. Section Two introduced the theoretical background on the Ampersand method, the Business Motivation Model, and the Strategic Alignment Model. The evaluation and demonstration of our artifact follow these sections. We end this paper with a discussion of the results, conclusions and some limitations of our current work.

2 Theoretical Background

2.1 Ampersand: A Relation Algebra Method

Ampersand is a simple requirements specification language with relational semantics [10]. It is a relatively simple version of relation algebra. Scholars developed Ampersand for students and practitioners with a minimal mathematical background, who use it for designing business processes. The Ampersand approach employs business rules to formulate a sound basis for subsequent IS design and to define the business processes. Within this purely declarative syntax, actions are not specified but derived.

Ampersand features rules, relations, and concepts [10]. In essence, a specification in Ampersand is a set of rules and a set of relation symbol declarations with a concept-based type. Each rule is an expression (a relation term) in relation algebra that must be kept ‘true’ throughout time. Thus, each relation that is a rule represents an invariant requirement of the business. Ampersand populates the concepts in the business rules with atoms. An atom refers to an individual object in the real world. Another important aspect of the Ampersand method is the need for a language that is shared by all stakeholders [11]. Part of this method is to create a shared understanding of particular sentences that are input for the Ampersand application.

2.2 Business Motivation Model (BMM)

The SAM offers strategies for achieving BITA. The SAM implies that organizations need to develop and align the business and IT strategy, as well as the organizational infrastructure, business processes, and the IS infrastructure. However, organizations strive to achieve a particular vision. This vision can be decomposed into clear and specific goals, creating a cohesive framework of interrelated goals [12]. Refined goals support organizations to harmonize its mission(s) and vision across the different levels of the organization. Organizations typically have a business and IT strategy (and plan) to achieve these goals.

Within this particular context, we use the Business Motivation Model (BMM); a joint effort of the Object Management Group and the Business Rules Group, shows in Fig. 1. The BMM is as a scheme or structure for developing, communicating, and managing business plans in an organized manner. This model supports the process of breaking down the business vision and mission into less abstract objects and eventually connecting the vision and mission to business rules and processes [13].

Fig. 1.
figure 1

adapted from OMG [18]

BMM

Full size image

We argue that this particular model can be used together with Ampersand to assure BITA in practice. Hence, (i) the BMM contains the concepts and relations for the strategic fit of the business, and (ii) the Ampersand method helps formulate and check BITA using the business rules that are part of the BMM. Moreover, Ampersand can verify the business rules for consistency (not containing any logical contradictions) and completeness (having all necessary or appropriate elements).

The BMM consists of ‘ends’ and ‘means’, among the ends, are things the enterprise wishes to achieve (e.g., goals, and objectives). Among the means are things the enterprise employs to achieve those ends (e.g., strategies, tactics, business policies, and business rules).

SAM consists of four components, or quadrants. The business quadrants of the SAM are (1) business strategy and (2) the organizational infrastructure and processes. BITA aims to align the business quadrants of the SAM with its IT quadrants, i.e., (3) IT strategy and (4) IT infrastructure and processes. By keeping ownership of the requirements responsibility of the business and linking these requirements explicitly to business goals, we can assure the link with the business strategy. Organizations can synchronize the organizational infrastructure with the business strategy by deriving the process entirely from the requirements. Hence, alignment between information systems and the business can now is achieved through the generation of software straight from the requirements. IT representatives are always one of the stakeholders within the requirements engineering process.

The process of assessing BITA works as follows. A stakeholder within an organization has a ‘purpose.’ That purpose can be an executive-level business purpose, e.g., achieving a vision; it could also be a formal business rule from a project or anything in between. A purpose is motivated. Hence, its meaning is obtained by relating it to other atoms from different concepts within the same conceptual model.

2.3 Overall Method and Research Design

Research rigor is the driving goal for method selection [14]. The method helps in producing and presenting high-quality research. The goal of the research is to iteratively design a model that can assure the alignment between business and IT. Hence, we develop and evaluate an artifact that solves the identified organizational problem of misalignment between business and IT. In doing so, we follow the Design Science Research Methodology (DSRM) model by Peffers, Tuunanen [15]. Through the DSRM process iterations (from problem motivation to design and knowledge dissemination) a robust technology-based solution is obtained.

To ensure the quality and validity our artifact, we followed foundational guidelines for useful design science in information systems research [16]. These include, e.g., (1) the production of a viable artifact in the form of a model, (2) use of technology-based solutions for a business problem, (3) design evaluation and (4) research rigor.

3 Artifact Description

We created an artifact to demonstrate the feasibility of the designed product. The ‘vision’ concept of the BMM is part of the business strategy quadrant of the SAM. To achieve the declaration of objectives and collective goals, an organization (both public and private) employs core business activities and processes. These particular aspects are part of the organizational infrastructure and processes quadrant of the SAM. Business rules control the processes. Ampersand generates the design based on business rules, through which software can be generated [17]. The business rules are the basis for IS processes and infrastructure and also a quadrant of Henderson and Venkatraman’s SAM. Following the BMM, and its relationships we now instantiate this, as Fig. 2 shows.

Fig. 2.
figure 2

Instantiated BITA alignment assurance model

Full size image

Following the formal Ampersand requirements, this instance still needs the invariant business rules to work. Hence, we formulate six fine-grained (invariant) business rules—based on cycles, or ‘closed loop,’ that check whether we have all the relevant rules—that relate the eight concepts and their relations from the assurance. The six rules collectively determine each business rule atom contribute to the vision atom.

We defined the following invariant business rules:

  1. i.

    For each strategy that is a means to plan a mission that operationalizes the vision, that strategy must channel efforts towards goals that amplify the vision. The formal notation in relation algebra is: isPlannedByMeansOf~; operationalizes ⊢ channelsEffortsTowards1; amplifies.

  2. ii.

    Each tactic that implements a strategy that channels efforts toward a goal, must channel efforts toward objectives that quantify that goal. The formal notation in relation algebra is: implements; channelsEffortsTowards1 ⊢ channelsEffortsTowards2; quantifies.

  3. iii.

    For each business process that realizes a strategy, there is a business rule—that is the source for that strategy—that controls that business process. The formal notation in relation algebra is: controls; realizes1 ⊢ isSourceOf1.

  4. iv.

    For each business process that realizes a tactic, which implements a strategy, that business process also realizes that strategy. The formal notation is: realizes2; implements ⊢ realizes1.

  5. v.

    For each business process that realizes a tactic, that business process is controlled by a business rule that is the source for that tactic. Its formal notation is: controls; realizes2 ⊢ isSourceOf2.

  6. vi.

    For each business rule that is the source of a tactic that implements a strategy, that business rule is also the source of that strategy. Hence, the formal notation in relation algebra is: isSourceOf2; implements ⊢ isSourceOf1.

4 Evaluation of the Artifact

4.1 Project Criteria

We demonstrate and evaluate the model at the Dutch Tax and Customs Administration (DT&CA). The purpose of the demonstration is to unfold how an IT project that develops a new process and accompanying IS fits within the vision of the DT&CA. In doing so, we identified and selected projects that are managed and governed by the business unit Central Administrative Processes (CAP). To achieve our primary aim, we choose this single business unit, so that the independent project concepts are kept stable. Hence, we now can assess the contribution of projects along the lines of the project business rules, via business unit goals, toward the vision of the organization. We did seek for maximum variation by selecting projects with differentiation based on:

  1. 1.

    The delegated business owner: the responsible delegated business owner differs per project.

  2. 2.

    IT components: the projects make use of IT systems that are entirely separately managed and developed from each other.

  3. 3.

    Department: the projects are for three different departments.

  4. 4.

    Functionality: each project realizes a different kind of functionality.

4.2 Atom Formulation and Model Population

To populate our model, we need to derive atoms for vision, mission, strategy, goal, tactic, and objective from available documentation. Based on relevant project and policy documents within DT&CA and the definitions of the concepts in the model, we generate the required population for these concepts.

An essential part of the Ampersand method is the fact that business processes are designed based on requirements. We assume that each requirement translates to one business rule, as suggested by Joosten [17]. Also, we assume that user stories mention business rule atoms. Hence, atoms were deduced from these user stories thereby using RuleSpeak®Footnote 1 as a way of formulating the business rule atoms.

4.3 Stage-Based Model Validation

We collected project data through the following steps. In the first step, we collected all available user stories from three projects, i.e., (1) Collecting on declarations (COD), (2) Payment Factory (PFA), and (3) Mini-One-Stop-Shop-Member State of Identification (MOSS-MSID). COD realize a process and IS that supports the collection of motor vehicle taxes. PFA assures that 99.11% of all payment processes are automated. MOSS-MSID develop the process and ICT for the Dutch Tax and Customs Administration to be able to comply with the European laws and regulations concerning the MOSS with the Dutch Tax and Customs Administration in the role of MSID.

Scaled Agile Inc. [18] argues that ‘user stories’ are short descriptions of a small piece of desired functionality, written in the user’s language. User stories are therefore the primary artifact used to define system behavior. Hence, these stories provide just enough information for our research. In the second step, the user stories were used to extract business rules and business processes. Next, we validated these outcomes with the involved business architects and business analysts. We interviewed three subject-matter experts with in-depth knowledge of the IT projects from DT&CA. We interviewed these subject-matter experts independently using a semi-structured interview guide. The first expert is a senior business consultant with broad and extensive experience in enterprise-wide IT implementations. Also, this expert has much valuable knowledge on the particular challenges associated with IT project within DT&CA. The second expert is a business and change consultant. We selected this consultant based on his experience in shaping and managing organizational change. The third expert, a mid-level manager, was selected to determine the understandability of the model for the (senior) management. We then incrementally processed the review comments from these validation sessions into the business rules and business processes.

5 Model Demonstration

For each project, we loaded an Ampersand script (using a.txt file) into the Repository for Ampersand Projects (RAP) to complete the script. RAP is a cloud-based solution that stores Ampersand-scripts that users can specify, analyze and ultimately use to build information systemsFootnote 2. Once all functional requirements in RAP are free of errors, the consistency of these requirements is a mathematically guaranteed property. A script within the RAP environment that passes these (consistency) tests on syntax and typing is called ‘accepted.’ Full details concerning Ampersand and RAP are somewhat too technical, and beyond the scope of the current paper.

An Ampersand script contains all atoms of all concepts from the model for a project. The repository checks for consistency between atoms in the defined relations and specified business rules. After loading the script, RAP checks for rule violations, with dedicated functionality to report these violations. Table 1 presents the RAP outcomes per project. Table 2 shows the number of violations per business rule for each project.

Table 1. Overview per project
Full size table
Table 2. Number of violations per business rule per project
Full size table

In summary, Table 2 shows a total of 375 inconsistencies based on the assessment in RAP. While we see minor errors and inconsistencies, in Business Rules 1 and 2, we see many inconsistencies in Business Rule 5 for each project, specifically for PFA. Rule 5 specifies that for each business process that realizes a tactic (i.e., a course of action that is a device or that it is expedient to employ as part of a strategy.), that a business process is controlled by a business rule that is the source for that tactic. It seems that assuring this rule in practice is an unprecedented challenge. Controlling the consistency that is checked by this rule for example, is not a known process for the DT&CA. These violations should be used by consultants and analysts in practice to trigger actions. This principle follows Shewhart’s Plan-Do-Check-Act cycle [19]. Analysis of the inconsistency should point out if the process actually does realize the tactic and if the business rule really is not the source of that tactic. The business rule to business process relationship is less likely to be incorrect. A stakeholder meeting can help to clear up this inconsistency. These results demonstrate how to maintain and assure alignment.

6 Discussion, Conclusions, and Limitations

Motivated by what in theory and practice appears to be a complicated process, this research developed a model to assess the alignment between business and IT following the Ampersand method. Using the SAM as described in [3] as a reference for measuring BITA, the model assures alignment between three of four quadrants of the SAM. The method checks alignment between business strategy and business organizational infrastructure and processes, alignment between business organizational infrastructure and processes and IS infrastructure and processes. Alignment with the IT strategy quadrant is currently not in scope within the proposed alignment method.

Our evaluation and demonstration show that BITA can be assessed and assured based on signaled violations requiring action. Violations of business rules and multiplicities of relations from the conceptual model form signals for an architect or analyst that the project design is inconsistent or incomplete. Based on these ‘triggers’ identified inconsistencies can be investigated and, if needed, restored to assure alignment.

From a managerial point of view, we apply the Ampersand method in assuring BITA within the organization. It is imperative—from both a theoretical and practical perspective—that business requirement should contribute to the firm’s vision. Our proposed artifact explicitly uncovers often overlooked relationships by capturing requirements through business rule atoms and relating the business rule atoms to the vision atoms. The complimentary, holistic view of the incorporated BMM and the (in)consistency checks made by the RAP assure consistency in the use of requirements.

The current study uses only three validation cases. This amount of cases might inhibit the generalizability of our results. However, our restricting the scope enabled us to get an in-depth view of these projects and their contribution toward alignment. Second, many organizations do not deploy and implement projects following the BMM vision. BMM provides a generalized scheme or structure for the development, the process of communicating and managing business plans systematically. We, therefore, have the conviction that our artifact can be used situationally as a useful artifact and checklist to identify the alignment improvement areas systematically.