<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Enterprise interoperability measurement - Basic concepts</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Nicolas Daclin</string-name>
          <email>nicolas.daclin@laps.u-bordeaux1.fr</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>David Chen</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Bruno Vallespir</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>LAPS/GRAI, University Bordeaux</institution>
          <addr-line>1, ENSEIRB, UMR 5131 CNRS, 351 cours de la Libération, 33405 Talence Cedex</addr-line>
          ,
          <country country="FR">France</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Developing or improving enterprise interoperability implies that the level or degree of interoperability is evaluated and causes identified and analysed. This paper tentatively presents the basic concepts relating to the measurement of the degree of interoperability. The degree of interoperability of an enterprise can be characterized by three types of measures: interoperability potentiality, compatibility and performance. The last two measures are discussed in detail and some metrics are proposed. The proposed approach is rather straightforward using the most salient characteristics known today for each measurement. It is prospective and preliminary. Some discussion and future development are given in the conclusion.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1 Introduction</title>
      <p>Interoperability is defined as the ability for two (or more) systems or components to
exchange information and to use the information that has been exchanged [1]. To day
few methods are developed to implement an interoperability solution and to evaluate
the degree of interoperability. The measure of the degree of interoperability allows
knowing the strengths and weaknesses of a company. This measure could lead to the
improvement of interoperability, and to avoid deficiencies. Thus, developing
interoperability measurement is becoming an important challenge. Some works have already
been performed in this domain [2], [3], [4], however it is difficult to define metrics,
mainly due to the difficulty to identify the parameters to characterise the
interoperability. The concepts and principles presented in this paper tentatively tackle this
problem by adopting a barriers driven approach.</p>
    </sec>
    <sec id="sec-2">
      <title>Basic concepts and principles</title>
      <p>
        Interoperability measurement aims at defining metrics to qualify the degree of
interoperability. The implementation of metrics, in order to measure the degree of
interoperability is related to two principles: (
        <xref ref-type="bibr" rid="ref1">1</xref>
        ) the identification of the parameters relating to
interoperability, (
        <xref ref-type="bibr" rid="ref2">2</xref>
        ) the characterization of these parameters by metrics.
      </p>
      <sec id="sec-2-1">
        <title>2.1 Interoperability barriers</title>
        <p>Enterprises are not interoperable because barriers to interoperability do exist. Barriers
are incompatibilities of various kinds and at various enterprise levels. There exist
common barriers to all enterprises whatever the sector of activities and size. As a
consequence, interoperability can be seen, in a first time, as a problem of
compatibility between two systems, not only at ICT level, but all levels of enterprise. Thus
developing interoperability means to develop knowledge and implement solutions
which remove incompatibilities. Three categories of barriers are identified [5]:
conceptual (syntactic and semantic), technological (related to the computer technology)
and organisational (responsibility/authority, organisation structure).</p>
      </sec>
      <sec id="sec-2-2">
        <title>2.2 Interoperability degree</title>
        <p>
          The degree of interoperability is a measure allowing characterising the ability of
interoperation between two enterprises (or systems). Metrics would enable for the
partners to know their agility in term of interoperation. At the current stage of research,
three types of measurement are considered: (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) Interoperability potentiality
measurement, (
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) Interoperability compatibility measurement, and (
          <xref ref-type="bibr" rid="ref3">3</xref>
          ) Interoperability
performance measurement. The interoperability degree of a given enterprise or a
system can be defined by a vector characterised by the three measurements mentioned
above.
        </p>
      </sec>
      <sec id="sec-2-3">
        <title>2.3 Interoperability degree measures</title>
        <p>The potentiality measurement is concerned with the identification of a set of system
properties that have impact on the interoperability development. These measures are
performed on one enterprise/system without knowing the interoperation partner. The
objective is to evaluate the potentiality of the system to evolve dynamically to adapt
and to accommodate with respect to potential partners. For example, an open system
has a higher potential of interoperability than a closed system.</p>
        <p>The compatibility measurement has to be performed during the engineering
stage i.e. when systems are re-engineered in order to establish interoperability. This
measure is performed when the partner/system of the interoperation is known. The
measure is done with respect to the identified barriers to interoperability. The highest
degree of compatibility means that all the barriers to interoperability are removed.
The inverse situation means the poorest degree of interoperability.</p>
        <p>The performance measurement has to be performed during the operational phase
i.e. run time, to evaluate the ability of interoperation between two cooperating
enterprises. In [6], a basic interoperation cycle has been defined with three phases
(exchange information, use information exchanged). Criteria such as cost, delay and
quality can be used to measure the performance with respect to barriers and levels
during a basic interoperation cycle. Therefore, each types of measurement have to be
valued with local coefficients in order to get a global coefficient ranging from “poor
interoperability” to “good interoperability”.</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>3 Interoperability measurement techniques</title>
      <sec id="sec-3-1">
        <title>3.1 Metrics for potentiality measures</title>
        <p>Interoperability potential is related to some intrinsic properties of a system. These
properties are usually built at the design stage into the system using some design
principles for interoperability. The figure 1 shows the most important properties
giving high potentiality to a system to adapt in particularly in a federated environment.</p>
        <p>
          Open (
          <xref ref-type="bibr" rid="ref1">1</xref>
          )
        </p>
        <p>
          Properties
Decoupled (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) Decentralized (
          <xref ref-type="bibr" rid="ref1">1</xref>
          )
        </p>
        <p>
          Configurable (
          <xref ref-type="bibr" rid="ref1">1</xref>
          )
Closed (0)
        </p>
        <p>Coupled (0)</p>
        <p>Centralized (0)</p>
        <p>Not-configurable (0)</p>
      </sec>
      <sec id="sec-3-2">
        <title>3.2 Metrics for compatibility measures</title>
        <p>The compatibility measures are performed against the barriers to interoperability. The
following shows an example of compatibility measures:</p>
      </sec>
      <sec id="sec-3-3">
        <title>The conceptual compatibility:</title>
        <p>
          − syntactic compatibility: does the information to be exchanged be expressed with
the same syntax?: fully (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ), no (0)
− semantic compatibility: does the information to be exchanged have the same
semantics?: fully (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ), no (0)
        </p>
      </sec>
      <sec id="sec-3-4">
        <title>The technological compatibility:</title>
        <p>
          − Platform technology: Are the IT platform technology compatible?: fully (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ), no (0)
− Software technology: Are the software languages are compatible?: fully (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ), no (0)
        </p>
      </sec>
      <sec id="sec-3-5">
        <title>The organisational compatibility:</title>
        <p>
          − Authority/responsibility: Are authorities/responsibilities clearly defined at the two
sides?: fully (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ), no (0)
− Organisation structure: Are the organisation structures compatible (ex.
Hierarchical vs. network structures)?: yes (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ), no (0)
        </p>
      </sec>
      <sec id="sec-3-6">
        <title>3.3 Metrics for performance measures</title>
        <p>The performance measures are concerned with the exchange of information and use
information exchanged. For example, concerning the exchange of information:</p>
      </sec>
      <sec id="sec-3-7">
        <title>Cost of exchange:</title>
        <p>Ccex = (cth − cmea)
cth
With: cth: theoretic cost = the expected cost of the exchange,
cmea: measured cost = the real cost of the exchange.</p>
      </sec>
      <sec id="sec-3-8">
        <title>Time (duration) of the exchange:</title>
        <p>With: tth: theoretic time = the expected duration of the exchange,
tmea: measured time = the real duration of the exchange.</p>
      </sec>
      <sec id="sec-3-9">
        <title>Quality of the exchange:</title>
        <p>Ctex = (tth − tmea)
tth</p>
        <p>.</p>
        <p>Cqex = nsucc
ntot</p>
        <p>.</p>
        <p>Ccuse = nconf
nrec
With: nconf = number of information that are conform
nrec = number of information received
4</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Conclusion - Discussion</title>
      <p>This paper has presented basic concepts and metrics allowing evaluating the degree
of interoperability between partners. However some points still need to be clarified.
For each local coefficient, which mechanism can allow obtaining various
intermediate coefficients between high and low level, without reduce the importance of one
coefficient? As far as the Interoperability Degree is concerned, which means of
aggregation can allow combining the local coefficients in order to obtain a global
coefficient (ID)?</p>
      <p>Another point is related to the measurement of the action resulting of the
interoperation. Even if the action is outside the cycle of interoperation, does its measurement
has to be taken in consideration and what is its importance to the interoperability?
6. Daclin, N., Chen, D., Vallespir, B.: Design principles and pattern for decisional
interoperability, in proceedings of APMS (2005).</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. IEEE:
          <article-title>IEEE standard computer dictionary: a compilation of IEEE standard computer glossaries (</article-title>
          <year>1990</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Whitt</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>The good, the bad and the ugly of interoperability metrics, Northhrop GrummanMission Systems presentation (</article-title>
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Hamilton</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rosen</surname>
            ,
            <given-names>J.D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Summers</surname>
            ,
            <given-names>P.A.</given-names>
          </string-name>
          :
          <article-title>Developing Interoperability Metrics, in joint command and control interoperability: cutting the gordian knot</article-title>
          ,
          <source>Chapter</source>
          <volume>6</volume>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Kasunic</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Anderson</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,:
          <article-title>Measuring systems interoperability: challenges and opportunities, Software engineering measurement and analysis initiative (</article-title>
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Chen</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Daclin</surname>
          </string-name>
          , N.:
          <article-title>Framework for enterprise interoperability</article-title>
          ,
          <source>IFAC EI2N</source>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>