# Toward a Methodology to Control Interoperability
## Improvement Projects Execution

Abderrahim Taoudi, Bouchaib Bounabat, Badr Elmir

► To cite this version:

Abderrahim Taoudi, Bouchaib Bounabat, Badr Elmir. Toward a Methodology to Control Interoperability Improvement Projects Execution. 5th International Working Conference on Enterprise Interoperability (IWEI), Mar 2013, Enschede, Netherlands. pp.186-197, 10.1007/978-3-642-36796-0_16 hal-01474210

HAL Id: hal-01474210

https://inria.hal.science/hal-01474210

Submitted on 22 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Toward a methodology to control interoperability improvement projects execution

Abderrahim Taoudi¹, Bouchaib Bounabat¹, Badr Elmir¹

¹ Al-Qualsadi Research & Development Team, Ecole Nationale Supérieure d'Informatique et d'Analyses des Systèmes (ENSIAS), Mohamed V - Souissi University, Avenue Mohammed Ben Abdallah Regragui, Madinat Al Irfane, BP 713, Agdal Rabat, Morocco.
abderrahim.taoudi@um5s.net.ma, bounabat@ensias.ma, b.elmir@daag.finances.gov.ma

**Abstract.** In front of the increasing complexity of information systems, improving enterprise interoperability has become a crucial element for better management. To address this issue, several research projects have been launched during the last decade and have resulted in a set of frameworks which help organizing and performing enterprise interoperability projects efficiently. In addition to these frameworks, many metrics have been also developed to measure the interoperability degree between systems. However, these frameworks and metrics are not sufficient to better control execution of these projects. Indeed, they don't take into account resource management and unanticipated events or situations that can be encountered during execution. Moreover, there is a real lack in methodologies to deal with this situation. The aim of this paper is to introduce a new approach to control interoperability improvement projects execution by using control theory, project planning theory and a specific quantitative interoperability metric Ratlop.

**Keywords:** Ratlop; Control theory; Enterprise Interoperability; Project planning theory; Interoperability improvement; Automated Business Processes.

## 1 Introduction

According to IEEE definition [1], Interoperability can be defined as the ability for two (or more) systems or components to exchange information and to use the information that has been exchanged. To allow companies to be more competitive, they should share information and competencies internally between departments and employees, and externally with partners. A successful implementation of interoperability helps also the companies to optimize their business processes, reduce their costs, and maximize service quality. In the enterprise interoperability area, many research projects have been launched in the last decades i.e. ATHENA [2], INTEROP [3]. Today, there is a number of mature frameworks that were developed and validated and are available to use i.e. Chen et al. [4], ATHENA [2], LISI [5], IDEAS [6], EIF [7]. In relation to enterprise interoperability measurement, many approaches and measures are available. Ford et al. [8] listed already a number of them. Other new measures also exist like Chen et al [9] and Ratlop [10].
Managing and controlling the execution of interoperability improvement projects raise many challenges. Given the current and targeted interoperability degrees as well as the available resources (i.e. Budget Allocation, Human Resources), the first challenge consists in finding the optimal plan for an efficient management of these projects. The second challenge is the ability to handle unexpected events that can be encountered during project execution, so that the managers can know exactly how many additional resources has to be allocated to correct the deviation from the project optimal plan. The available frameworks and metrics are not currently sufficient to handle the aforementioned challenges.

The aim of this paper is to propose a new approach to control the execution of interoperability improvement projects. The proposed approach will be based on mature and proven tools: the framework of chen et al [4] (currently under CEN/ISO standardization process) as the interoperability framework, Ratlop[10] as the interoperability quantitative metric, Project Planning theory to define the optimal plan and Control theory to control projects execution.

## 2 Overview of Ratlop

Several dimensions of interoperability have been defined in [1], [11] and [12]:

* Interoperability barriers: Conceptual, technological and Organizational.

* Interoperability concerns: Business, Process, Service and Data.

* Interoperability approaches: Integrated, Unified and Federated.

* Interoperability engineering: Requirements, Design and Implementation.

* Interoperability scopes of application: Within the same organization and Cross independent organization.

* Interoperability transactional aspects of cooperation: Synchronous collaboration and Asynchronous collaboration.

In terms of measurability, three kinds of interoperability measurement have been defined in [9]:

* Interoperability potentiality: it's used to measure the potential of a system to accommodate dynamically to overcome possible barriers when interacting with a partner.

* Interoperability compatibility: it's used to measure the ability of two systems to interact with each other.

* Interoperability performance: it's used to measure the operational performance of interoperability.

Ratlop is a new quantitative ratio metric to measure interoperability between automated business processes that was developed in [10]. With this ratio, an organisation can evaluate, at any time and in a quantitative way, the degree of interoperability of its automated business processes.

Ratlop takes into account three kinds of interoperability measurement as so as:
1. to quantify the first kind of interoperability, Interoperability potentiality, by using the five levels of IMML (Interoperation Maturity Model Level) [10] calculated as below:

$$PI = 0.2 * IMML, \text{ where IMML} = 1,2,3,4 \text{ or } 5 \quad (1)$$

2. to quantify the second kind of interoperability, Interoperability compatibility, by using a modified matrix of Chen et al [10], see Table 1.

<table><caption>**Table 1.** Interoperability compatibility</caption><thead><tr><th rowspan="2"></th><th colspan="2">Conceptual</th><th colspan="2">Organizational</th><th colspan="2">Technology</th></tr><tr><th>syntactic</th><th>semantic</th><th>Authorities<br>resposabilities</th><th>organisation</th><th>platform</th><th>communication</th></tr></thead><tbody><tr><th>Business</th><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td></tr><tr><th>Process</th><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td></tr><tr><th>Service</th><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td></tr><tr><th>Data</th><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td><td>0/1</td></tr></tbody></table>

By noting $dc_{ij}$ the elements of this matrix, this potential is calculated as below:

$$DC = 1-((\sum dc_{ij})/24), \text{ where } dc_{ij} = 0 \text{ or } 1 \quad (2)$$

$dc_{ij}$ is given the value 0 if the criteria in an area marked satisfaction; otherwise, if a lot of incompatibilities are met, the value 1 is assigned to $dc_{ij}$.

3. to quantify the third kind of interoperability, Interoperability performance, by using these three elements:

- DS: the overall availability rate of application servers.

- QoS: the service quality of different networks used for interacting component communication.

- TS: the end users satisfaction level about interoperation.

This potential is:

$$PO = \sqrt[3]{(DS * QoS * TS)} \quad (3)$$

Using these three previous indicators, RatIop is calculated as below:

$$RatIop = \frac{(PI+DC+PO)}{3} \quad (4)$$

Using this ratio, [13] introduces a tool, Interoperability Monitoring Tool (IMT), which has three modules:

- Module 1: To assess interoperability at a specific period.

- Module 2: To propose a scenario to reach a planned degree of interoperability.

- Module 3: To give the prerequisites of going from a maturity level to the next one.
# 3 Defining the optimal plan of the interoperability improvement projects

Project planning has different meanings in project management. In this paper, Project Planning is the act of building the task by task schedule which we will call the “Project Plan”. The optimal plan is the project plan that minimizes one or more optimization criteria: Cost, Resources and Time. The high level objective of the interoperability improvement projects is to improve interoperability by passing from an initial Ratlop $R_i$, which is the actual state of interoperability, to a targeted Ratlop $R_t$. To define the optimal plan of these projects, we propose to follow these steps:

1. Definition of the project objectives

2. Definition of the optimal plan using project planning theory.

## 3.1 Project objectives definition

The high level objective of the interoperability improvement project defined above must be decomposed to clear, concise and measurable objectives which will be used to plan the project properly. In this vein, the Periodic Interoperability Monitoring Tool (IMT) [13] can be used to define a clear scenario to reach the desired Ratlop Rt. the proposed scenario will define:

* The target Maturity Level.

* The prerequisites to reach this target Maturity Level.

* The incompatibilities to remove.

* The target operational performance ratios: Availability rate of application servers, The QoS of different networks and end users satisfaction level.

## 3.2 Optimal plan definition

Using the objectives as defined above, there are many planning methods and tools to define the optimal plan taking into account resources, costs and time. The paper [14] lists many deterministic and non deterministic mathematical models used to define optimal plans. Most of these models are already automated. Below some examples of these models:

* The standard Project Management model, PMBOK [15].

* Critical Path Method, CPM, and PERT.

* Non-resource-constrained NPV maximization.

* The Resource-Constrained Project Scheduling Problem, RCPSP.

* The Multi-mode Resource-Constrained Project Scheduling Problem, MRCPSP.

The project planning theory will help us define the optimal plan to satisfy the project objectives listed in the section 3.1.
# 4 Controlling execution of interoperability improvement projects

Without careful monitoring and control, many projects fail to achieve the expected results. The aim of this phase is to measure actual execution, compare it with the optimal plan, analyze it and correct the deviations. To achieve this goal, we will use a proven and mature mathematical tool: the feedback control theory.

## 4.1 feedback control theory

Feedback control theory is widely used in many domains i.e. manufacturing, electronics and physics. It's used also in computer science i.e. apache [16], web servers [17], lotus notes [18], internet [19] and networks [20]. A feedback control system, also known as closed loop control system, is a control mechanism that maintains a desired system output close to a reference using information from measurements of outputs. The feedback control diagram adopted by this paper is illustrated in Figure 1.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Feedback control diagram</figcaption></figure>

The plant is the system to be controlled. In our case, it's the interoperability improvement project. It has a controlled input (denoted by *w(t)*), and a measured output (denoted by *y(t)*). The controller takes as input the control error (denoted by *e(t)*), which is the difference between the observed value and the reference value), and it adjusts the input of the plant system to minimize this error. Because of the discrete nature of the system, we will adopt a discrete time approach with uniform interval sizes (Day, Week, two Weeks, or Month).

## 4.2 Ratlop reference Definition

The reference is the Ratlop of the system. Its curve will be derived from the optimal plan. We will take into account the finished tasks to calculate the projected Ratlop at
a time t. The objective of the control system is to minimize the deviations between the desired Ratlop based on the optimal plan and the measured Ratlop.

## 4.3 Modeling the plant system

The plant system is the interoperability improvement project. The input of the plant system, at a time t, is the effort consumption at this time to release the project. It can be the resources of the project or budget allocation. The output of the plant system, at a time t, is the Ratlop at this time. Below is the definition of the characteristics of the plant system illustrated in Figure 2:

$w(t)$ = the effort consumption at time t to release the project (resources of the project, budget allocation).

$y(t)$ = measured Ratlop of the system at time t

$r(t)$ = the desired Ratlop of the system at time t based on the optimal plan.

We will model the plant system as a black-box. We will focus on the behavior of the system not on the internal system construction details which are considered complex. To do so, we will use a statistical approach. The model adopted is the statistical model ARMA. To keep things simple, we will adopt ARMA Model of first order.

$$y(t) = a*y(t-1) + b*w(t) \quad (5)$$

$a$ and $b$ are constants which will be estimated statistically. These constants can be estimated by varying inputs ($w(t)$), and calculating the resulting Ratlop ($y(t)$). For each value of the effort $w$ (resources, budget allocation), an automated project planning software can be used to calculate the optimal plan and derive the values for the Ratlop ($y(t)$). Using these experiments, we can estimate the constants $a$ and $b$ statistically. The use of an ARMA model with greater order will give a more precise approximation of the plant system.

## 4.4 Modeling the controller

According to [21], there are four properties of feedback control systems to verify:

* Stability: a system is said to be stable if for any bounded input the output is also bounded.

* Accuracy: a system is accurate if the measured output converges to the reference input.

* Settling time: a system has short settling time if it converges quickly to its steady state value.

* Overshooting: a system that achieves its objectives without overshoot, that is without exceeding an upper limit.

There are three basic controller models:

* Proportional Controller: $w(t) = K*e(t)$

* Integral Controller: $w(t) = w(t-1) + K*e(t)$

* Differential Controller: $w(t) = K*(e(t)-e(t-1))$
The constant K is called the gain. To achieve the four properties of our studied feedback control system, the model that we will adopt is the Proportional-Integral model (PI Model) :

$$w(t) = w(t-1) + (K_p + K_i)e(t) - K_p e(t-1) \quad (6)$$

The transfer function of this PI controller is:

$$K_p + (K_i * z/(z-1)) \quad (7)$$

Thus, we can define the following objectives for our design:

* The system is stable.

* The steady state error is minimized

* The settling time does not exceed a constant value Ks.

* Maximum overshoot does not exceed a constant value Mp.

Using these objectives, [21] discusses in detail the procedure to calculate the appropriate Kp and Ki of the model. With the plant and controller modelled, the control system of interoperability improvement projects is totally defined.

## 5 Case study

To illustrate the approach, we will use a real world example which is the e-government example used in [13]. This case consists of an online payment for health care services in a public hospital. It was used in [13] to illustrate Ratlop assessment and the usage of the IMT Tool. This system is described in Figure 2.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Online payment business process</figcaption></figure>
The main objective of this case study is to illustrate the details of steps and calculations used by the approach presented in this paper.

## 5.1 Initial Ratlop assessment

During the implementation phase, three incompatibilities were detected:

* Exchange with mutual servants: Infrastructures are not compatible. It's a Business/Technology platform and communication incompatibility.

* Exchange with National social security fund: Periods for data up-dating not-synchronized. It's a Data/Organizational incompatibility.

* Exchange with private insurance: Process description models can't exchange information. It's a Process/Conceptual syntactic and semantic incompatibility.

Using the framework defined in [10] and section 2 of this paper, the initial interoperability compatibility matrix for the incompatibilities described above is listed in Table 2:

<table><caption>**Table 2.** Initial Interoperability compatibility</caption><thead><tr><th rowspan="2"></th><th colspan="2">Conceptual</th><th>Organizational</th><th colspan="2">Technology</th></tr><tr><th>syntactic</th><th>semantic</th><th>Authorities<br>responsibilities</th><th>organisation</th><th>platform</th><th>communicat<br>ion</th></tr></thead><tbody><tr><th>Business</th><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td></tr><tr><th>Process</th><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><th>Service</th><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><th>Data</th><td>0</td><td>0</td><td>0</td><td>1</td><td>0</td><td>0</td></tr></tbody></table>

Using the framework defined in [10] and section 2 of this paper, the initial interoperability assessment is described in Table 3:

<table><caption>**Table 3.** Initial Ratlop value</caption><thead><tr><th>Metric</th><th>Description</th><th>Value</th></tr></thead><tbody><tr><td>Maturity Level</td><td>IMML</td><td>0,4</td></tr><tr><td>Interoperability compatibility</td><td>DC</td><td>0,79</td></tr><tr><td>Overall application servers availability</td><td>DS</td><td>0,9</td></tr><tr><td>Network quality of service</td><td>QoS</td><td>1</td></tr><tr><td>End user satisfaction</td><td>TS</td><td>0,8</td></tr><tr><td><strong>Ratlop metric</strong></td><td><strong>Ratlop</strong></td><td><strong>0,69</strong></td></tr></tbody></table>
## 5.2 Project objectives definition

The aim of the project is to achieve 80% degree of interoperability instead of the current interoperability degree of 69%. So, the targeted RatIop is 0,8. Using the IMT Tool [13], the proposed scenario to reach this targeted RatIop is:

* Remove the tree incompatibilities of the system.

* Improve the Overall application servers' availability to be 1.

* Improve the end user satisfaction level to be 1.

## 5.3 Optimal Plan Definition

Using these objectives, the project tasks are defined in Table 4. The duration unit is the week:

<table><caption>Table 4. Tasks description</caption><thead><tr><td>Tasks</td><td>Duration (in weeks)</td><td>Resources need</td></tr></thead><tbody><tr><td>Task1: removing exchange with mutual servants incompatibilities</td><td>3</td><td>5</td></tr><tr><td>Task2: removing exchange with National social security fund incompatibilities</td><td>5</td><td>6</td></tr><tr><td>Task3: removing exchange with private insurance incompatibilities</td><td>5</td><td>6</td></tr><tr><td>Task4: Improving the Overall application servers' availability</td><td>2</td><td>2</td></tr><tr><td>Task5: Improving the end user satisfaction level</td><td>3</td><td>5</td></tr></tbody></table>
All these tasks are independent. A task cannot begin if the needed resources are not affected to it. The total resources for the project are 6. Using project theory, the optimal plan is described in figure 3.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Optimal plan</figcaption></figure>

## 5.4 Ratlop reference Definition

Using this optimal plan, the Ratlop reference is described in figure 4:

<table><caption>Fig. 4. Ratlop Reference</caption><thead><tr><th>Time</th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th><th>13</th><th>14</th><th>15</th><th>16</th><th>17</th><th>18</th><th>19</th></tr></thead><tbody><tr><td>Ratlop</td><td>0,69</td><td>0,69</td><td>0,69</td><td>0,72</td><td>0,72</td><td>0,72</td><td>0,72</td><td>0,74</td><td>0,74</td><td>0,74</td><td>0,74</td><td>0,74</td><td>0,76</td><td>0,76</td><td>0,77</td><td>0,77</td><td>0,77</td><td>0,80</td><td></td></tr></tbody></table>

## 5.5 Modeling the plant system

Figure 5 illustrate the evolution or Ratlop depending on available resources.

<table><caption>Fig. 5. Ratlop over time and resources</caption><thead><tr><th>Ressources</th><th>Time</th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th><th>11</th><th>12</th><th>13</th><th>14</th><th>15</th><th>16</th><th>17</th><th>18</th><th>19</th></tr></thead><tbody><tr><td>5 Ratlop*100</td><td>69</td><td>69</td><td>69</td><td>72</td><td>72</td><td>72</td><td>72</td><td>72</td><td>74</td><td>74</td><td>74</td><td>74</td><td>74</td><td>74</td><td>76</td><td>76</td><td>77</td><td>77</td><td>77</td><td>80</td></tr><tr><td>6 Ratlop*100</td><td>69</td><td>69</td><td>69</td><td>72</td><td>72</td><td>72</td><td>72</td><td>72</td><td>74</td><td>74</td><td>74</td><td>74</td><td>74</td><td>74</td><td>76</td><td>76</td><td>77</td><td>77</td><td>77</td><td>80</td></tr><tr><td>7 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>73</td><td>73</td><td>73</td><td>73</td><td>73</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>77</td><td>77</td><td>77</td><td>80</td><td>80</td><td>80</td></tr><tr><td>8 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>73</td><td>73</td><td>73</td><td>73</td><td>73</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>77</td><td>77</td><td>77</td><td>80</td><td>80</td><td>80</td></tr><tr><td>9 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>73</td><td>73</td><td>73</td><td>73</td><td>73</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>77</td><td>77</td><td>77</td><td>80</td><td>80</td><td>80</td></tr><tr><td>10 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>73</td><td>73</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>77</td><td>77</td><td>77</td><td>77</td><td>77</td><td>77</td><td>80</td><td>80</td><td>80</td><td>80</td></tr><tr><td>11 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>73</td><td>73</td><td>76</td><td>76</td><td>76</td><td>77</td><td>77</td><td>77</td><td>77</td><td>77</td><td>77</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td></tr><tr><td>12 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td></tr><tr><td>13 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td></tr><tr><td>14 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td></tr><tr><td>15 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td></tr><tr><td>16 Ratlop*100</td><td>69</td><td>69</td><td>71</td><td>76</td><td>76</td><td>76</td><td>76</td><td>76</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td><td>80</td></tr></tbody></table>

Using the least square regression method, the plant system parameters estimation is:

$$y(t) = y(t-1) + 0.1 * w(t) \quad (8)$$
## 5.6 Modeling the controller

The objectives of our design are:

* The system is stable

* The steady state error is minimized

* The settling time does not exceed a constant value 10

* Maximum overshoot does not exceed a constant value 20%.

Using these objectives, [21] discusses in detail the procedure to calculate the appropriate $Kp$ and $Ki$ of the model. In our case: $Kp=2.75$ and $Ki=1.65$.

So, our controller is modelled as:

$$w(t) = w(t-1) + 4.4 * e(t) - 2.75 * e(t-1) \quad (9)$$

We can see that the value “4.4” is approximately the mean value of task resources. If the Ratlop is less than the reference, the controller will suggest adding this quantity of resources to begin a pending task. This will accelerate the advancement of the project.

The proposed approach will be more efficient if these conditions are met:

* Projects are medium to large (more than 50 tasks).

* Choosing the unit of time the largest possible.

* In the plant model, choosing an ARMA model with greater order.

## 6 Conclusion and Future work

This paper has proposed a complete approach, which helps controlling the execution of interoperability improvement projects, based on proved mathematical models (feedback control theory and statistics) in addition to the framework of chen et al and the quantitative metric Ratlop. This methodology can be easily generalized to use another framework or metric because it does not depends heavily on them.

The interoperability improvement project has been modelled as a black box system without detailing deeply into the relationship between input (i.e. work effort) and output (Ratlop). In future work, our objective is to model the system in more details.

On the other hand, the applicability of other branches of control theory, like optimal control, will be studied.

## 7 References

1. IEEE. (1990). IEEE standard computer dictionary: a compilation of IEEE standard computer glossaries.

2. ATHENA (2003), Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications, FP6-2002-IST-1, Integrated Project.

3. INTEROP (2003), Interoperability Research for Networked Enterprises Applications and Software, network of excellence.

4. Chen, D., Daclin, N. (2006). Framework for enterprise interoperability. In IFAC TC5.3 workshop E12N, Bordeaux, France.
5. C4ISR (1998), Architecture Working Group (AWG), Levels of Information Systems Interoperability (LISI).

6. IDEAS (2003), IDEAS Project Deliverables (WP1-WP7), Public reports, Retrieved from www.ideas-roadmap.net.

7. EIF (2004), European Interoperability Framework, White Paper, Brussels, http://www.comptia.org.

8. Ford, T. C., Colomb, J., Grahamr, S. R., Jacques, D. R. (2007, June). A survey on interoperability measurement. In Proceedings of 12th International Command and Control Research and Technology Symposium, Newport, RI.

9. Chen, D., Vallespir, B., Daclin, N. (2008). An approach for enterprise interoperability measurement. In Proceeding of MoDISE-EUS. France.

10. Elmir B., Bounabat, B. (2011). A Novel Approach for Periodic Assessment of Business Process Interoperability. IJCSI International Journal of Computer Science Issues, 8(4), ISSN (Online): 1694-0814, www.IJCSI.org.

11. Guédria, W., Naudet, Y. and Chen, D. (2008). Interoperability maturity models - survey and comparison. Lecture Notes in Computer Science, Springer Berlin / Heidelberg. Vol. 5872/2009, pp. 216-225.

12. Michelson, B. (2006). Event-Driven Architecture Overview. Technical Report. Patricia Seybold Group. Boston, USA.

13. Elmir, B., Alrajeh N.A., Bounabat, B. (2011). Interoperability monitoring for e-government service delivery based on enterprise architecture. In International Conference on Information Management and Evaluation (ICIME), Toronto, Canada.

14. WILLIAMS, T.M. (2003). The contribution of mathematical modelling to the practice of project management. IMA Journal of Management Mathematics 14, 3–30.

15. Project Management Institute (2000). A Guide to the Project Management Body of Knowledge (PMBOK). Project Management Institute, Upper Darby, PA, US.

16. Gandhi, N. Tilbury, D. M., Diao, Y., Hellerstein, J., Parekh, S. (2002). Mimo control of an apache web server: Modeling and controller design. In Proceedings of the American Control Conference.

17. Lu, C., Abdelzaher, T., Stankovic, J., Son, S. (2001). A Feedback Control Approach for Guaranteeing Relative Delays in Web Servers. In IEEE Real-Time Technology and Applications Symposium, Taipei, Taiwan.

18. Gandhi, N., Parekh, S., Hellerstein, J., Tilbury, D. M. (2001). Feedback Control of a Lotus Notes Server: Modeling and Control Design. In American Control Conference, Arlington, VA, USA.

19. Mascolo, S. (1999). Classical Control Theory for Congestion Avoidance in High-speed Internet. In Proceedings of the 38th Conference on Decision & Control, Phoenix, Arizona, US.

20. Chiu, D., Jain, R. (1989). Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks. Computer Networks and ISDN Systems, 17(1).

21. Hellerstein, J. L., Diao, Y., Parekh, S., Tilbury, D. M. (2004). Feedback Control of Computing Systems. ISBN 0-471-26637-X, John Wiley & Sons.