Keywords

1 Introduction

Current business environments are highly dependent on Information Technology (IT) thus making Business-IT alignment a major concern among IT managers and researchers [1]. This alignment must be properly governed to improve the reliability and predictability of the performance of IT services in order to understand the current and potential business impact [2]. The aforementioned issue poses critical questions that are currently not easily answered by organizations: Is the organization able to operate properly with its current IT services?, Which IT services are critical to the organization?, What is the risk level of its IT services?, What would be the impact on the organization if an IT service suffers an affectation?. Therefore, modeling and understanding the impact of the dependencies between business and IT services lead to quantifying the delivery of business value.

In order to improve IT governance, multiple strategies [3, 4] have emerged to quantify the impact of IT on business value by analyzing organizational impact variables or by modeling the events that could lead to a service failure. Other strategies [5–7] have incorporated Business-driven IT Management (BDIM) to optimize IT management processes. These strategies aim to guide IT so that it is driven by the needs and expectations of the business. Nonetheless, most of these approaches do not define, simply and explicitly, the processes and the information that must be considered to interrelate the existing business and IT elements, nor a method for prioritization and decision making in regard to the selection of IT services. Moreover, the quantification of business impacts does not consider the analysis of critical models such as oversizing costs, service quality attributes, penalties on service agreements, and risks.

A method that comprises a metamodel and two processes is proposed in order to address the above problems. The metamodel characterizes and relates specific models that allow the specification of value metadata associated with the IT-business dependencies. A criticality model is used to evaluate the relevance of the business architecture elements and of the IT services architecture elements. Models for risks, quality attributes, and agreements are used to quantify the dependencies related to IT services. The quantification of dependencies with value metadata allows showing how an affectation in an IT service impacts the business in terms of financial issues arising from the materialization of risks, service agreements, or the loss of income due to non-provision of business services. The defined processes guide the modeling of IT-business dependencies and value metadata, as well as the quantification of their impact.

The paper is structured as follows. Section 2 summarizes an experiment performed to identify the need for the IT-business quantification approach that was created. Section 3 gives a brief overview of the general approach and terminology used by the author. It also shows the proposed metamodel and how IT-business dependencies are quantified. Section 4 shows the results of one of the four case studies for which the proposed method was used to quantify IT-business dependencies. Section 5 introduces multiple approaches for quantifying IT-business dependencies in order to position the research presented in this work. Lastly, conclusions and future work are presented in Sect. 6.

2 Open Issues for Quantifying IT-Business Dependencies

An experiment of identification and validation of the models and practices described by the BDIM [5] was performed to evaluate two aspects: (1) the complexity to establish dependencies between the IT solutions and business performance of an organization, and (2) the business impact of IT solutions for the optimal selection of a service portfolio. The Audiovisual Production IT Area from a Latin American University was used as a case study. This area was selected because its processes support most of the enterprise’s core processes and also due to the availability of its IT service measures.

First, a survey was created to evaluate the importance of the ten IT services provided by this area (cf. BDIM practice [5]). A process leader of this IT area performed the assessment with regard to nine specific criteria: quality, cost, revenue generation capacity, reliance on staff, level of affectation by incidents, installed capacity, dependence on external factors, interaction with the customer, and time to perform specific tests. Each of the evaluation criteria was assigned a weight of 1 (low) to 10 (high) in order to determine the importance of the IT service. Second, the cost and loss models [6] associated with the prioritized IT services were analyzed. The cost model was defined by the interrelations among the components of each service. The loss model considered the income lost due to the unavailability of human resources caused by excessive requests in relation to the available capacity.

After applying BDIM to the case study, it was possible to establish which services were the most representative services regarding their contribution to the business impact (incomes and losses). Two open issues were found in this experiment as well as in related work (cf. Sect. 5).

Lack of Impact Analysis Models for Quantifying Dependencies. It was identified that the dependence between IT and business processes is highlighted from three points of view: the cost to the business, the losses caused by non-compliance to agreements, and the net revenue after minimizing losses and costs. Nevertheless, the following impact analysis models remain unconsidered: (a) impact upon the materialization of IT service risks, (b) oversizing costs, and (c) incidence of service quality attributes. It is then necessary to model and quantify these critical elements on IT-business dependencies so as to complement the business impact analysis when there is a change in an IT service. Moreover, alignment approaches do not define measures that relate IT behavior with the effects it has on different architectures: business motivation, business processes, and IT services. Therefore, the need arises to define specific analysis variables to be added on business-business dependencies, IT-IT dependencies, and IT-business dependencies.

Lack of Specific Processes and Procedures. Although it was possible to identify the dependencies between IT elements and business elements, the way to find these dependencies does not lead to a methodical and orderly approach but to an ad-hoc approach. It then becomes necessary to identify the elements that must be defined in the establishment of these dependencies. Specifically, how to follow the path from a business goal to an IT service and vice versa, as well as how to identify their level of importance along the way. Furthermore, a method for prioritization and decision making in regard to the selection of IT services under a criticality perspective (e.g., contribution to IT and business elements) was not identified.

Based on the information presented above, a method for quantifying the impact of the dependencies between business elements and IT services was developed. The main features of this method are presented in the following section.

3 IT-Business Impact Quantification Method

The proposed method defines a metamodel as well as two different processes to model and quantify IT-business dependencies (Fig. 1 illustrates the general approach).

Fig. 1.
figure 1

Processes and impact analysis models to quantify IT-business dependencies

Full size image

First, the metamodel represents impact analysis models on critical dependencies within the business architecture, within the IT services architecture, and between business and IT architectures. An architecture is defined as “the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment” [8]. A business architecture involves the elements of a Business Motivation Architecture (BMA) (e.g., goals, metrics, strategies) and of a Business Process Architecture (BPA) (e.g., value chain activities, process specifications, tasks). An IT services architecture covers elements such as IT services, software components, data structures, etc. The elements and dependencies to be modeled in the BMA (first activity), BPA (second activity), and IT services architecture (fourth activity) are inspired by the alignment architecture defined by Aier et al. [9].

Second, the configuration process allows an architect to identify and model the IT-business dependencies and their related value metadata (TOP-DOWN approach). The proposed method defines value metadata as the analysis data (i.e., cost, income, metric, risk, agreement, criticallity, quality attribute) added to particular architecture elements and to the dependencies defined among inter-architecture elements. Impact analysis metadata can be propagated and analyzed through the traceability of intra-architecture dependencies. Third, the quantification process allows IT-business managers to define the actual or expected values on Service Critical Factors (SCF) (i.e., performance, availability, capacity, reliability) for each IT service. The latter process uses an algorithm to navigate the IT-business dependencies in order to quantify the impact (i.e., losses) that IT services have on the business and which architecture elements are affected due to an IT service affectation (BOTTOM-UP approach). These three artifacts are detailed in the following subsections.

3.1 Proposed Metamodel

Figure 2 illustrates a simplified view of the metamodel that was created to model and quantify IT-business dependencies. This metamodel was described by using the Eclipse Modeling Framework (EMF) meta model (Ecore) due to its facilities for modeling and for generating code based on a structured data model. An instance of the metamodel (a model specification) was created to represent all IT-business dependencies for the case study presented in Sect. 4.1.

Fig. 2.
figure 2

Metamodel to configure and quantify IT-business dependencies

Full size image

Impact analysis models such as criticality, risks, service agreements, and service critical factors are one of the main contributions. The three criticality entities enable many to many dependencies among IT and business elements. Costs, revenues, metrics, and losses impact analysis models are adopted from literature review [5, 6]. The need to select critical services driven by the business elements (goals, processes) is adopted from literature review [10]. The value metadata of each of the proposed impact analysis models is described within the activities of the following processes.

3.2 Configuration Process: Creation of IT-Business Dependencies

The procedures of the activities involved in the configuration process are described below (cf. Process 1 in Fig. 1).

Identify the BMA. The first activity is to model the business elements supporting the value proposition of the organization by using inputs such as the strategic business plan, the business motivation model, and the balance score cards. The business motivation architecture includes elements such as competitive factors (e.g., quality, access), their relationships with the business goals, the strategies defined to accomplish those goals, and the metrics to evaluate their performance (cf. BusinessGoal, Strategy, Metric entities in the metamodel). Value metadata is assigned to these elements to allow the quantification of dependencies: a relevance percentage is assigned to each competitive factor, the expected income is assigned to business objectives, and target performance objectives are assigned to the strategies. For example, a 5 % increase on sales represents a percentage on the revenues for the business. The output of this activity corresponds to the monetized strategic map of the organization.

Identify Criticality Dependencies in the BPA. The second activity is to model the BPA at different decomposition levels: Level0- Value Chain activities, Level1- Macro-processes, Level2-Process Groups, Level3- Business Processes, and Level4- Activities (sub-processes and tasks) (cf. ProcessElement in the metamodel). This BPA is built incrementally by adding value metadata: criticality metadata up to Level 2 elements and incomes metadata for Level 3 elements (cf. CriticalityStrategyProcess and Income entities in the metamodel). Criticality metadata is established by modeling dependencies between BPA elements and Strategy elements (including their associated Objective elements), and by assigning a criticality measure to these dependencies. This measure must be provided by a business expert based on the impact on business strategies (i.e., 1-None (N), 2-Minor (M), 4-Moderate (O), 6-Serious (S), 10-Vital (V)) if that particular process element is not performed (cf. criticality on project management [11]). Nonetheless, this criticality measure could be associated with other concrete elements: amount of incomes, losses volume, number of affected users, business processes it supports, impacted business units, supported clients, impact on business indicators, and volume of transactions, among others.

Figure 3 illustrates how this criticality measure must be evaluated iteratively up to Level 2 of the BPA, but just for process elements that are classified by the model within a critical prioritization area. A process element is located within a prioritization area after calculating the criticality average between all its related strategy dependencies. The metamodel instance uses the following prioritization areas: Critical for averages higher than six, Important for averages between four and six, and Low for averages lower than four. Each organization can adjust these prioritization areas by considering its own availability of resources (cf. criticality margins [12]), and by evaluating not just the impact of the process element on motivation elements but also the execution frequency of processes (cf. risks assessment [13]). The output of this activity is the set of prioritized business processes for which the impact of the related IT services must be analyzed.

Identify Criticality Dependencies in the IT Services Architecture. The third activity is to model the IT services supporting the prioritized business processes and activities. This architecture must be specified at different decomposition levels (cf. ITElement in the metamodel): Level 1 \(-\) IT services (e.g., enrollment management), Level 2 \(-\) IT systems (e.g., authentication system), and Level 3 \(-\) IT components (e.g., balancing cluster). Costs metadata associated with different concepts (e.g., infrastructure, licensing, configuration) is assigned to Level 3 IT elements (cf. Cost in the metamodel). Criticality metadata is assigned to the dependencies between Level 1 IT elements and Level 3 process elements (cf. CriticalityProcessIT in the metamodel). This metadata allows identifying the potential points of failure on IT services that can impact the critical process elements. Criticality metadata is also assigned between Level 2 and Level 1 IT elements (cf. CriticalityITIT in the metamodel) by using the same scale and prioritization areas used for process elements. It is worth noting that the criticality-related entities are the main points of dependency and analysis between the different architectures (motivation, processes, IT). The output of this activity comprises the critical and monetized IT elements to be analyzed in terms of quality attributes, risks, and service agreements.

Fig. 3.
figure 3

Iterative prioritization of process elements based on dependencies criticality

Full size image

Associate SCF to IT Elements. The fourth activity is to model SCF metadata associated with the prioritized Level2 IT elements. A SCF represents a quality attribute (i.e., capacity, availability, performance, reliability) in terms of three characteristics: minimum value, maximum value, and actual value (cf. ServiceCriticalFactor in the metamodel). Capacity refers to the percentage of transactions that can be processed by the IT element. Availability refers to the percentage of time that an IT element is working. Performance refers to the average response time of all operations using an IT element. Integrity refers to the probability of wrong transactions or a system failure. The actual value of a SCF is valuated by IT managers according to the behaviour of IT elements. These SCF were inspired when performing the experiment described in Sect. 2.

Relate Agreements. The fifth activity is to model the agreements metadata (service agreements, service levels, and penalties) associated with each SCF. A service agreement specifies the signing stakeholder (a customer, a business unit, a provider), the agreement type (i.e., service-level (SLA), operational-level (OLA), underpinning contract (UC)), the service provider, and the service attendance time (cf. Agreement in the metamodel). Each agreement can be associated with multiple service levels which are specified by IT managers through a level type (e.g., premium, standard), and with the lower and upper expected values to which the IT unit is committed (cf. ServiceLevel in the metamodel). A penalty must be associated with each service level by specifying the minimum and maximum percentage values that can be computed over services cost (cf. Penalty in the metamodel). When a service level is affected, the model takes the maximum computed penalty value as incomes (positive impact) for provider agreements, and as costs (negative impact) for client and inter-units agreements.

Identify IT Risks. The last activity is to model dependencies between business risks and IT elements through their SCF. This corresponds to the risk identification stage considered in risk management methods. The proposed method also incorporates the assessment stage by assigning the following value metadata to these dependencies: risk factor, its type (i.e., operational, strategic, legal, reputational), the detection speed, the recovery speed, and the assessment value. The latter is specified in terms of impact (measured from 1-Very low to 5-Catastrophic), frequency of occurrence (measured from 1-Exceptional to 5-Frequent), and the cost if it is materialized. These values are provided by multiple business and IT experts.

3.3 Quantification Process: IT Services Behavior and Impact Results

This section presents the process that was defined to quantify the impact of IT services once the dependencies between the business and IT were identified, modeled, and rated. This configuration information is represented in a database that is generated from the ecore metamodel presented in Sect. 3.1. Most of the procedures associated with the three activities of the quantification process (cf. Process 2 in Fig. 1) were automated by implementing (a) an algorithm that calculates the value and the failure probability of IT Services, and (b) a web application in which the business and IT users quantitatively consult the business impact according to the actual or simulated performance of IT Services.

Calculate the Failure Probability of IT Services. A level 2 IT service must be selected within the web application in order to start the impact analysis. If the actual value of a SCF exceeds the predefined limits, the algorithm computes the failure probability as 1: the service is failing. If the actual value of the SCF is within the limits, historic SCF values (cf. SCFByTime in the metamodel) are used to perform an adjustment on the normal distribution to compute the mean value (\(\mu \)) and the variance value (\(\sigma ^{2}\)). Then, the quantification algorithm computes the failure probability (Fp) as the area under the curve within the normal distribution (the historic SCF behaviour) given by the difference between the probability of being in the range of the SCF limit value (l) defined at the service agreement and the probability of being in the range of the SCF actual value (a). The superior range of the integral (l or a) defines the limit for the independent variable (t), i.e., 

$$\begin{aligned} Fp = \int _{-\infty }^{l} \frac{1}{\sigma \sqrt{2\Pi }} e^{-\frac{1}{2}}\left( \frac{t-\mu }{\sigma } \right) ^{2} dt - \int _{-\infty }^{a} \frac{1}{\sigma \sqrt{2\Pi }} e^{-\frac{1}{2}}\left( \frac{t-\mu }{\sigma } \right) ^{2} dt . \end{aligned}$$
(1)

Quantify the Value of IT Services. The quantification algorithm computes the monetary value of an IT service (ITSval) with the following formula:

$$\begin{aligned} ITSval = I + A + R + S . \end{aligned}$$
(2)

  • I represents the incomes expected from the IT services operation. These incomes are computed by summing the incomes metadata retrieved when querying the level3-processes associated with the selected IT service.

  • A represents the maximum affectation on the incomes due to IT service degradation. An impact factor is computed for each process associated with the selected level2-service. This impact factor is the average of the monetary values of the strategies related to each process. For each prioritized level3-process associated to the selected IT service, a corresponding loss factor is computed by multiplying the weight of the services on the process, the failure probability, and the degradation factor for each SCF. A degradation factor (Df) is obtained as the relation between the SCF value estimated by the user (p) and the SCF actual value (a). For SCF such as integrity and performance, there can be a degradation on agreements if their values are closer to 1: \(Df = (p - a) / a\). Values further away from 1 can denote a degradation for SCF such as availability and capacity: \(Df = (a - p) / a\). The multiplication of the number of loss factors (n) with the costs metadata of the service components (k) is subtracted from the sum of all the loss factors obtained per process (m) in order to obtain the incomes affectation: \(A = m - (n*k)\).

  • R represents the costs of IT risks materialization. All SCF associated with the selected level2-service are queried so as to navigate to the risks related to them (cf. RiskvsFactor in the metamodel). The impact attribute of each IT risk and the impact magnitude of the SCF are multiplied to identify and prioritize the critical risks (over a predefined value). The cost metadata associated with all the prioritized risks is summed.

  • S represents the costs of incomes for agreement violations. All agreements related to the SCF of the selected level2-service are queried in order to obtain their service levels. There is degradation when actual values on SCF differ from the target values defined on service levels. The maximum penalty value associated to the service levels is multiplied by the maximum affectation value on the incomes (A).

A and R represent negative magnitudes, whereas S can have a positive magnitude for UC agreements as well as a negative magnitude for SLA and OLA.

Build Results Dashboard The actual operation level for each identified SCF is established (e.g., availability of 99,99 %) by the expert technical staff through the web application. This value is compared with the SCF levels that had been previously configured (e.g., availability of 99,9 %) in order to compute the failure probability and degradation factor. Once the previous operation scenario has been established, a simulation scenario (“What If”) must be presented by indicating the expected level for each SCF (e.g., availability of 95 %). This value may correspond to a simulated or a real scenario depending on whether it is based on a forecast or if it responds to the measurement of the actual behavior of the IT service. Once these values are provided, the web application shows the income losses due to the degradation or absence of an IT service, losses due to risks materialization, and losses due to agreements violations. The web application also shows the impacted business goals, the affected metrics, the affected business processes, the risks that must be taken into account, and breached service level agreements. The use of the web application is illustrated in Sect. 4.2.

4 Impact Quantification Results: A Case Study

A Latin American University was used as a case study to evaluate the design of the proposed method by quantifying its critical IT-business dependencies. The data was collected in situ through the combination of interviews with the stakeholders involved in the Information Services Area, and the examination of institutional documentation (e.g., integral development plan, value chains, etc.). The execution of the configuration process took approximately five months of which four months were required to gather, relate, and document the architecture and dependencies information. An additional month was required to instantiate the proposed metamodel in order to create the quantification model (an XMI specification). This quantification model contains approximately 13500 elements among business architecture elements, IT architecture elements, dependencies, and value metadata. The historic data of the SCF values was provided weekly during one year (2013–2014) by an IT Manager of the mentioned area.

4.1 Executing the Configuration Process (TOP-DOWN)

Business Motivation Architecture. Table 1 summarizes the strategic map that was identified and monetized. Each of the differentiating factors has an associated relevance for achieving the related strategic business goals. Associated metrics and their corresponding strategies were also defined.

Table 1. Strategic map identified and monetized
Full size table

Criticality Dependencies in the BPA. The criticality of the dependencies between the strategies above and the level1-business processes was established. The critical prioritization area was elaborated from this rating and the two processes that are closer to the criticality threshold were selected: Selection and Admission, and Teaching and Learning. Additional iterations of the criticality evaluation were performed to identify level2 critical elements (i.e., Admission, Course registration) and level3 critical processes (i.e., Undergraduate admission, Development of courses). Activities (BPA level 4) associated with the selected processes were determined: 19 activities were identified for the admissions process and 6 activities for the course registration process.

Criticality Dependencies in the IT Services Architecture. Each of the BPA activities was associated with the corresponding level 1 IT services. The organization does not have an official IT services catalog, so the mapping was done through a manager from the Information Services Area. The criticallity of level 1 IT services is evaluated in relation to the selected processes and to the level 2 IT services that support them. Three level1-services with the highest score within the critical prioritization area were selected: Database service, Authentication service and Banner System service; the latter being transversal to both processes. The costs of these selected services are given by the sum of all costs associated with their IT components.

IT Service Critical Factors. The IT business unit defined the actual and desired levels for each SCF on the selected IT services. A desired value between 0.75 and 0.91, and a actual value of 0.9 were defined for the Capacity SCF. A desired value between 0.7 and 0.99999, and a actual value of 0.7864 were defined for the Availability SCF. A desired value between 0.1 and 0.01, and a actual value of 0.0771 were defined for the Integrity SCF. A desired value between 0.3 and 0.01, and a actual value of 0.093 were defined for the Performance SCF.

Agreements and Service Levels for IT Services. No IT service level agreements are established between IT and the business units, however, these agreements were defined for critical IT services as an expected behaviour to be delivered. For example, a standard service level was defined on the availability SCF for the Banner IT service. If the measure for the % of availability of service components is between 88–90% the amount payed next month will be reduced by 30 %, between 85–88% the amount will be reduced by 50 %, and below 85 % the amount will be reduced by 100 %. The complete analysis involved the definition of 3 agreements with 3 service levels each.

IT Risks. Three risks were assessed on the capacity SCF for the Banner IT service. An application failure was assessed as low for impact and frequency, and therefore the cost of risk materialization was estimated as low (125 USD). A database failure was assessed with a high impact but with a low frequency, so the cost of risk materialization was estimated as medium (112.500 USD). The worst situation was estimated for a hardware failure (20.000 USD) which was assessed as high for impact and frequency. The entire analysis involved the identification and evaluation of 30 risks for 4 SCFs.

4.2 Execution of the Impact Quantification Process (BOTTOM-UP)

In the above configuration process, dependencies and metadata between business and IT elements were established. Figure 4 illustrates the impact analysis results presented by the web application when comparing a simulated scenario (“What If”) with the actual behaviour for the Banner IT service. The actual value of each critical IT service and the failure probability for each SCF associated with them are computed automatically by the algorithm implemented in the web application (cf. Sect. 3.3). The simulated SCF values on capacity, availability, performance and integrity were presented as estimates by the mentioned IT area. The business impact results correspond to the capacity simulation scenario.

Fig. 4.
figure 4

Impact quantification results from the web application

Full size image

The Capacity simulation scenario considers a peak in the number of transactions received concurrently so that the value supported by the SLA is exceeded. Since the installed capacity cannot meet all the transactions, around 90 % of the received transactions will be lost. The quantitative results show the maximum income losses due to Capacity SCF degradation (28.000.000 COP aprox. 14.000 USD), losses due to risks materialization (15.860.000 COP aprox. 7.930 USD), and losses due to agreements violations (5.600.000 COP aprox. 2.800 USD). Additional qualitative results showed the affected architecture elements: 4 business goals (e.g., Attract and maintain quality students), 19 business processes (e.g., Undergraduate admissions), 5 strategies (e.g., Increase the number of student entries), 7 metrics (e.g., Undergraduate positions filled), and 5 risks.

The Availability simulation scenario showed a lower income affection (18.430 USD) than the capacity scenario. The Integrity simulation scenario presented the most significant deviation (90.180 USD) from the expected income, which may be expected considering the affectation that wrong transactions may have on the system. The Performance simulation scenario showed a similar income affectation (23.680 USD) than the capacity scenario. Availability and Integrity are the most important SCF because their failure implies that the whole system stops working. On the other hand, Capacity or Performance are not as critical considering that the system may continue to operate despite service degradation.

Decision-Making Support. The actual or simulated failure probability allows IT-business analysts to support the decision making process regarding IT investments. This is achieved specifically through an explicit comparison of the losses generated by the failure against the opportunity of making an investment to mitigate it. The quantification results show the cost of business elements that are not adequately satisfied by IT services. Thus, IT-business decision makers can define continuity strategies and assign the required resources to keep business expectations aligned with IT operation. The method can be used to prioritize IT investments by assessing the criticality of their related IT services or components in relation to business elements (goals, strategies, metrics, processes).

5 Related Work

The alignment between business and IT can be analyzed from two perspectives: assessing the level of alignment, or quantifying the impact of its dependencies. In particular, dependencies quantification approaches assess the impact of IT on business elements. Gustafsson et al. [3] quantifies the impact of IT on business value (e.g., flexibility, efficiency) through organizational impact variables (e.g., functional structure, skills). Winker et al. [4] propose a model for defining and analyzing the dependencies (task-subtask, producer-consumer and simultaneity constraints) between the services and the compositions that may arise among them. This information can be used to simulate events that could lead to a service failure with measurable attributes (e.g., time, location, resources), which could be used for adjusting SLA. These approaches do not quantify the impact of risks, service agreements, and criticality on IT services. The proposed method specializes the simulation of events on IT services by capturing the performance of their related SFC (e.g., availability). The above measurable attributes and impact variables can be incorporated in the proposed method as additional impact analysis metadata.

BDIM uses different models and techniques to map and to quantitatively evaluate dependencies between IT solutions and business performance [5]. These techniques enable the design and constant optimization of IT processes (e.g., incident management, capacity management) based on business needs [6, 7]. The authors in [6] use BDIM to select SLA parameters (availability, maximum average response time) to design a servers farm to deploy the services. This approach analyzes SLA losses with regards to the costs and losses due to under or over capacity estimation of IT infrastructure. The proposed method complements this impact analysis on availability agreements with additional quality attributes (performance, reliability, capacity) and risks specified on IT services. Thus, a causal relationship between IT services performance and business elements can be established in quantitative terms (losses) as well as qualitative terms (traceability of processes, goals, strategies, and metrics). Bartolini et al. [7] prioritizes incidents by assigning urgency and impact parameters according to the level of importance of the solution with regard to the business objectives and the resulting costs when the business does not solve the incident immediately. The proposed method could be extended to link specific elements of IT processes with the performance of IT services to quantify business impact.

Risk management can be incorporated to analyze IT services [14]. Tohidi [15] includes risk management to support the evaluation of information systems within each stage of the development process. Bojanc et al. [16] analyze IT risks on information safety by identifying assets, threats, and vulnerabilities to further define quantitative risk metrics. These proposals identify IT risks in detail, however, they are missing support to quantify the business impact associated to the materialization of risks on IT operation. This can be done in the proposed method by associating risks to IT-business dependencies.

6 Conclusions and Future Work

The growing need for business and IT interoperability is forcing organizations to improve the management of their processes and IT services. This paper presents specific processes and models used to incorporate quantitative metadata on the existing IT-business dependencies. Quantitative analysis capabilities are achieved by modeling the criticality between business and IT elements, and the impact analysis models (risks, service agreements, and service critical factors) for IT services. In particular, the incorporation of risk analysis capabilities is an important supplement to better quantify IT-business dependencies.

However, there are a number of subtleties and limitations related to practical implications that arise when adopting the quantification method. First, the quantification of dependencies, criticality, and risk of each IT and business element cannot be done independently. Ongoing research is targeted to correlate and quantify these impact variables for IT and business elements that do not have an explicit dependency among them. Second, modeling and relating value metadata to IT-business dependencies can demand a considerable amount of effort from domain architects. Further research is required to define document configuration templates to automatically generate the metamodel instance or the web application database. A different approach is to extend an enterprise architecture tool with the impact analysis capabilities defined in the metamodel. Although the latter limitation is transparent for IT-business managers, who are the intended audience for executing the quantification process, it is also necessary to integrate the assets configuration tool with monitoring tools in order to capture the IT services performance continuously. Third, the method currently assumes business processes as the linking bridge between business and IT, however, it is necessary to incorporate the notion of business function to relate supporting IT services. Finally, the impact analysis capabilities of the method can be enriched by incorporating additional SCF (e.g., maintainability).

The proposed method has been used in four case studies to quantify IT-business dependencies for three companies. Through the analysis of these implementations, it was found that the method can be used at different levels of detail to simplify the dependencies configuration. For example, the architect of one of these companies decided which were the critical business processes without establishing criticality dependencies for the complete BPA. However, once these business processes were selected, all the remaining activities were completely adopted to associate value metadata to IT-business dependencies. The proposed method should be applied iteratively and incrementally to cover the analysis of the different business and IT elements for the entire organization.