SPICE: A Generic Model for Interoperability Assessment?

Abstract

Measuring interoperability implies establishing measures of merit to evaluate the degree of interoperability between systems. This is the purpose of so-called maturity models, describing the stages through which systems should evolve to reach higher completeness in the realization of a given objective. This paper reviews the main maturity models for interoperability, comparing the di erent aspects of these models to ISO/IEC 15504 model (also known as SPICE), which de nes a framework for processes assessment. We highlight the existing links, showing that ISO/IEC 15504 can be used as a generic model from which existing interoperability maturity models could be derived.

Keywords

• Capability
• maturity
• interoperability
• assessment
• model

1 Introduction

Nowadays, IT as well as human systems evolve in a worldwide heterogeneous environment and work in network. For enterprises, operating in such environment requires exibility and co-operations between other enterprises, sharing their core competencies in order to exploit the market opportunities. Exchanges are needed for both operational control, and to a larger extend for the decision making process during the establishment of cooperation, including opportunity exploration, co-operation planning and implementation. Therefore, the ease of communication between the people involved and the quality of inter-operation between the supporting information and communication systems play a key role in such co-operations. A major issue in global collaboration and co-operation of enterprises is the management of the interoperability problems.

In this work, Interoperability is considered from a systemic perspective where it is rst viewed as a problem to solve: An interoperability problem appears when two or more incompatible systems are put in relation [ 3 ]. Then, it is seen as a goal to reach, where Interoperable systems operate together in a coherent manner, removing or avoiding the apparition of related problems. Last, if we consider a process view of interoperability, we may de ne it as the process allowing an enterprise interoperating with its partners (existing or future ones), by solving existing problems and/or previnting potential ones.

According to [ 13, 4 ], there are three kinds of interoperability problems: Conceptual, Technological and Organizational. Conceptual problems are mainly concerned with the syntactic and semantic incompatibilities of information to be exchanged or to be used during an interoperation. Technological problems refer to the use of computer or ICT (Information and Communication Technologies) to communicate and exchange information (i.e. architecture & platforms, infrastructure). These problems concern the standards to use, store, exchange, processes or computerized information. Organizational problems relate to the de nition of responsibilities and authorities so that interoperability can take place under good and well-established conditions. In order to quickly overcome these interoperability problems and thus support enterprises to better interoperate with their partners, clients, providers, etc.; Enterprise Interoperability (EI) requires being assessed and continuously improved. Interoperability can be measured in two ways: a priori where the measure relates to the potentiality of a system to be interoperable with a possible future partner whose identity is not known at the moment of evaluation, a posteriori where the measure relates to the compatibility measure between two (or more) known systems willing to interoperate.

One of the assessment methods consists in using maturity models. A maturity model is a framework that describes for a speci c area of interest a number of levels of sophistication at which activities in this area can be carried out [ 8 ]. Many maturity models have been proposed in the litterature such as : LISI (Levels of Information System Interoperability) [ 9 ], OIM (Organizational Interoperability Model) [ 11 ], LCIM (Levels of Conceptual Interoperability Model) [ 10 ], MMEI (Maturity Model for Enterprise Interoperability) [ 14 ], etc. Unfortunately, each one of these maturity models proposes to assess interoperability from a di erent perspective, with a di erent approach and metrics.

Very little e ort has been made in designing a generic model assessing interoperability that an enterprise may instantiate to its context and use to its speci c needs. In light of these, the main research question addressed by this paper is: What are the di erences between maturity models that are dedicated to interoperability and a maturity model such as ISO/IEC 15504 standard, also known as SPICE (Software Process Improvement and Capability dEtermination) [ 5 ], if we consider interoperation between partners and/or preparing interoperability as processes. One of the implications of the previous research question touches upon the possibility to have a generic model assessing interoperability. To deal with this research question, we rst review the main existing interoperability maturity models in order to compare their di erent levels with SPICE standard, considered here as a reference model. With this comparison, we aim at showing that SPICE can be used to form a generic model that can be instantiated in di erent contexts of interoperations.

The reminder is structured as follows. In section 2, we present the reference model (SPICE). In section 3, we survey the main maturity models for each type of interoperability [ 13, 4 ]: The LISI (Levels of Information System Interoperability) model [ 9 ] for the technical interoperability, the LCIM (Levels of Conceptual Interoperability Model) model [ 10 ] for the Semantic Interoperability, the OIM (Organizational Interoperability Model) model [ 11 ] for organizational interoperability, we nally present the MMEI (Maturity Model for Enterprise interoperability) [ 14 ], that considers the three aspects of interoperability in an enterprise context. With the description of these maturity models, we highlight the links between each model and the reference model. In section 4, we classify the reviewed models followed by a brief discussion. Finally we conclude in section 5, by highlighting future work.

2 Reference Model

SPICE (Software Process Improvement and Capability dEtermination) [ 5 ] is an international standard for software process assessment, developed by the Joint Technical Subcommittee between ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission).

De nition

In [ 5 ], a process is de ned as a set of activities correlated or interactive that transforms inputs into outputs.

SPICE de nes six levels of capability, from Level 0 to Level 5, as shown in table 1. The capability of processes is measured according to nine attributes: Process Performance, Performance Management, Work Product Management, Process De nition, Process Deployment, Process Measurement, Process Control, Process Innovation, Process Optimization. For each process attribute, one or more generic practices are de ned, which are further elaborated into practice indicators to aid assessment performance. Each process attribute is assessed on a four-point (N-P-L-F) rating scale: { N- Not achieved (0 - 15%) { P- Partially achieved (> 15% - 50%) { L- Largely achieved (> 50% - 85%) { F- Fully achieved (> 85% - 100%).

As an application of SPICE requirements, the CMMI model (Capability Maturity Model Integration) [ 6 ] was proposed. The CMMI is a maturity model that can be used to guide process improvement across a project, a division, or an entire organization. Though CMMI is well known, it is an instance of SPICE, which we will not discuss here. For more details, see [ 6 ].

3 Maturity Models for Interoperability

In this section, we study the existing maturity models for interoperability and discuss their correspondances with SPICE.

3.1 LISI : Levels of Information System Interoperability

The LISI maturity model [ 9 ] identi es the stages through which systems should logically progress or "mature" in order to improve their capabilities to interoperate. Five levels are identi ed by terms that describe both the level of interoperability and the environment in which it occurs, as shown in table 2. Within each

Data and applications are fully shared and distributed. Data has a common interpretation regardless of format.

Information is exchanged between independent applications using shared domain-based data models.

Logical data models are shared across systems.

Simple electronic exchange of data.

Manual data integration from multiple systems. level, LISI identi es additional factors that in uence the ability of systems to interoperate. These factors comprise four attributes: Procedures, Applications, Infrastructure, and Data (PAID). PAID provides a method for de ning the set of characteristics required for exchanging information and services at each level. It de nes a process that leads to interoperability pro les and other products. LISI focuses on technical interoperability and the complexity of interoperations between systems.

As it can be noticed, the LISI model meets the SPICE requirements and can be instanciated from the SPICE model in the speci c context of technical interoperability of systems. Indeed, the purpose of a system using LISI, is to have the highest level of technical interoperability. So, the process to consider here is the technical interoperability. Each de ned level in the LISI model can be matched with a level of the SPICE standard, as follows: { Isolated interoperability level can be associated to SPICE Incomplete process level. On the one hand, the SPICE incomplete process level is the result of assessing a process that failed to attain the purpose of the process. On the other hand, the LISI Isolated level is concerned with isolated systems in a manual environment with no electronic links between them : The purpose of the technical interoperability as a process is not achieved. { Connected interoperability level can be associated to SPICE Performed process level. On the one hand, the SPICE Performed process level is the result of assessing a process that achieved its purpose but in a non rigorously planned and tracked way. On the other hand, the LISI Connected interoperability level is concerned with connected systems in a peer-to-peer environment with some form of simple electronic exchange of data and a little capacity to fuse information. So the technical interoperability as process is achieved but in a non rigorously planned or tracked. In that context, SPICE Performed process level can clearly be matched with the Connected interoperability level. { Functional interoperability level can be associated to SPICE Managed process level. Indeed, the SPICE Managed process level is the result of assessing a process with an acceptable quality within de ned timescale. On the other hand, the LISI Functional interoperability level is concerned with functional systems in a distributed environment which required a timely processing of the information from the involved system distributed entities. In that context the SPICE Managed process level can be matched with the Functional interoperability level. { Domain based interoperability level can be associated to SPICE Established process. In fact, the SPICE Established process level is the result of assessing a process that is performed and managed using a de ned process based upon good software engineering principles. On the other hand, the LISI Domain based interoperability level is concerned with integrated systems in an integrated environment which requires common business rules and processes as well as database to database interactions. In that context the LISI Domain based interoperability level can be matched with the SPICE Established level. { Enterprise-based interoperability level can be associated to SPICE Predictable process level. In fact SPICE Predictable process level is the result of assessing a process that is performed consistently in practice within de ned control limits to achieve its goals. On the other hand, the LISI Enterprise-based interoperability level is concerned with interoperable systems in a universal environment, in this context, data and application are fully shared and distributed, so the technical interoperability as a process is predictable in a SPICE meaning.

3.2 LCIM : Levels of Conceptual Interoperability Model

In [ 10 ] the Levels of Conceptual Interoperability (LCIM) Model was proposed to address levels of conceptual interoperability that go beyond technical models like LISI.

The model is intended to be a bridge between conceptual design and technical design. The focus lies in the data to be interchanged and the interface documentation that is available. The layers of the LCIM model are shown in table 3. With the same assumption that interoperability is a process, the LCIM model Semantic connections are made apparent via a documented conceptual model underlying components.

Use of data is de ned using software engineering methods like UML.

Common reference model with the meaning of data unambiguously described.

Shared protocols between systems with data accessible via interfaces.

Black boxes components with no interoperability or shared data. would eventualy meet the de ned requirements in SPICE standard in a conceptual interoperability context. Indeed, with LCIM, the purpose is to have the highest level of semantic interoperability.

Each LCIM maturity level can have its corresponding level in SPICE: { Isolated systems level corresponds Incomplete process level. Indeed, the result of the interoperability assesssment at this LCIM level is the non interoperability or shared data. With the SPICE incomplete process level, the result would be the failure to attain the purpose of the process. In that context, LCIM Isolated systems level matches with SPICE Incomplete process level. Documented Data matches with Performed Process. Indeed, the result of assessing the semantic interoperability between systems, at the LCIM level, is the existence of shared protocols between systems with accessible data (via interfaces) but with no common reference model. With the SPICE level, a process which achieved its purpose but in a non common, planned way. In this context, we see clearly the correspondance between the two levels. { Aligned Static Data can be related to Managed Process. At the LCIM level, the result of the interoperability assessment is a common reference model, a managed data but with di erent interpretations in systems. On the other hand, at the SPICE level 2, we have as assessment result a managed process with acceptable quality. In this context these two levels can be matched. Aligned Dynamic Data corresponds to Established Process in SPICE. Indeed, the interoperability assessment at this level is the de ned use of data using uni ed models. On the other hand the SPICE Established process level requires a performed, managed, de ned process. Hence, the two levels of the two models can be matched. { Harmonized Data level matches with Predictible Process level in SPICE. Indeed, the interoperability assessment at this level is a common conceptual model and a semantic consistency. On the other hand, we nd SPICE predictible process level which requires the achievement of the process goal within de ned control. In this contect, Harmonized Data level can be related to SPICE level 4.

It is relevant to notify that the optimisation and maintenance aspects are not taken into account in this model, as in SPICE (level 5).

3.3 OIM : Organizational Interoperability Model

The Organizational Interoperability Maturity Model [ 11 ] de nes the levels of organisational maturity that describe the ability of organisations to interoperate. Five levels are identi ed, as depicted in table 4. The OIM model meets also the de ned requirements in SPICE standard in an organizational interoperability context. Indeed, with the OIM model, the process to evaluate would be the organizational interoperability. Each maturity level of the OIM model can have its corresponding SPICE level: { Independent level can be associated to SPICE Incomplete process level. Indeed, at this level, organizations are independent and work without any interaction. The organizational interoperability as process is incomplete. In this context the OIM Independent level matches with SPICE Incomplete process level. { Ad hoc level matches with SPICE Performed process level. Indeed, at this level the interoperability is done in an ad hoc manner and specif arragements are unplanned, so with the organizational interoperability process can be achieved but in a non rigorously planned way. In this context we can clearly notice that Ad hoc level can be matched with SPICE Performed process level. { Collaborative level can be related to SPICE Managed process level. In order to reach this level, the organization should have a recognized framework to support interoperability in an acceptable way. At this level organizations are still distinct. In that context the SPICE Managed process level, which requires the process achievement in an acceptable quality, matches with the ( OIM Collaborative)level. { Integrated level matches with SPICE Established process level. Indeed, organizations reach this interoperability level when they have shared goals and

Uni ed The organisation is interoperating on a continuing basis. Command structure and knowledge basis are shared.

Integrated Shared value systems and goals, a common understanding to interoperate however there are still residual attachments to a home organisation.

Collaborative Recognised interoperability frameworks are in place.

Shared goals are recognised. Roles and responsibilities are allocated but the organisations are still distinct.

Ad hoc Some guidelines to describe how interoperability will occur but essentially the speci c arrangements are still unplanned. Organisations remain entirely distinct.

Independent Organisations work without any interaction. Arrangements are unplanned and unanticipated. No formal frameworks in place. Organisations are able to communicate for example via telephone, fax and personal contact in meetings. a common understanding to interoperate. At this level the interoperability framework should be be in place and practiced even the residual attatchements to a home organization. These requirements to reach the OIM Integrated level correspond with those de ned at the SPICE Established process, where a performed and managed process using a de ned framework is required. { Uni ed level matches with SPICE Predictable process level. This level, which is a goal for many organizations, requires organization to be interoperating on continuing basis. From the SPICE perspective, the requirement to be at predictible level, a process has to be de ned, performed and consistently in practise. 3.4 MMEI : Maturity Model for Enterprise interoperability The Maturity Model for Enterprise Interoperability (MMEI) [ 14 ] is a maturity model de ned within an a priori context of interoperability. It allows companies to evaluate their potentiality to interoperate, in order to know the probability that they have to support e cient interoperation and to detect precisely the weaknesses that are sources of interoperability problems.

MMEI de nes ve levels of Enterprise interoperability. For each one of these maturity levels, previous maturity models and the way they de ne their levels have been considered and adapted to match an a priori assessment context. MMEI levels are rst speci ed and a detailed description for each level is given. Table 5 gives an overview of the MMEI levels. Each MMEI maturity level is described by an mn matrix M = [Pi;j ]m n , where m is the number of interoperability aspects (i.e. conceptual (semantic and syntactic), technical, organizational) and n is the number of the enterprise concerns (i.e. business, process, service and data). These two dimensions constitute the problem space of enterprise interoperability. Pi;j is the description of the criteria that an EI concern should meet to avoid interoperability barriers and acquire the target maturity level, see [ 14 ] for more details. Considering conceptual, organizational and techical interoperabilities as independent processes, interoperability as assessed by MMEI can be considered as a process composed by three sub-processes: conceptual, technical and organizational. Moreover, MMEI is de ned in an a priori context (see section 1); hence the process here is concerned with preparing interoperability and not interoperating with an existing partner, as is the case for the other maturity models. Given that, each MMEI maturity level can also have its corresponding level in SPICE as follows: { At MMEI level 0, the enterprise is concerned by ad-hoc interoperability capabilities or no will to interoperate. This level can be matched with Level 0 or Level 1 of SPICE. Indeed if the enterprise has the ability to interoperate in an ad-hoc manner with another partner, then, the Interoperability process is achieved even though this is not rigorously planned and tracked. However, if the enterprise has no will to interoperate, then we assume that there is a general failure to attain the purpose of the process and MMEI Unprepared level is then matched with to Incomplete process in SPICE. { At MMEI level 1, there is a capability of properly modelling and describing systems to prepare interoperability. This corresponds to the Managed process level in SPICE where the process delivers work products of acceptable quality (here models). { At MMEI level 2 the enterprise is able to make changes to align to common formats or standards. This can be matched with level 3 in SPICE where the process is performed and managed using a de ned process. Indeed, we assume that a enterprise has to have a de ned process in order to be able to align to standards and make changes without problems to prepare itself to future interoperations. { At MMEI level 3, the enterprise is able to perform needed mappings with multiple heterogeneous partners. This corresponds to Predictable process in SPICE, where the process is performed within de ned control limits to achieve its goals. { At level 4, the enterprise has the ability of negotiating and dynamically accommodating with any heterogeneous partner. Hence the process is optimized and the enterprise is able to interoperate on the y to meet its current and future business needs, which corresponds to the level 5 in SPICE.

4 Discussion

The SPICE standard and the other maturity models presented above, aim at helping an organization, enterprise or a system to improve the way it does business or co-operates with other partners.

Each available improvement approach focuses on a speci c part of the business. While the ISO/IEC 15504 provide a generic framework and an assessment model for proccesses, other maturity models establish measures to evaluate the interoperability degree in di erent context : the LISI model deals with only the technical level of interoperability, the LCIM model addresses the Semantic aspect, the OIM model covers the organizational aspect. Since we postulate that interoperability is a process among others in an organization, we have seen along the paper how each maturity level of the studied models can be matched with the capability levels of SPICE. This leads us to the conclusion that SPICE can be used as a generic model for interoperability assessment. This can be thereafter, instanciated in the speci c domain and cover all kinds of interoperability. In table 6, we give the correspondance of each maturity model to the domain it covers, taking as reference the descriptions provided in previous sections and the classi cation done on interoperability in [ 4 ] and [ 13 ].

5 Conclusion

In this paper, we have reviewed some maturity models assessing interoperability capability with a di erent view. LISI (Levels of Information System Interoperability) has been studied for technical interoperatbility assessment, LCIM (Levels of Conceptual Interoperability Model) for semantic interoperability, OIM (Organizational Interoperability Model) for Organizational interoperability and MMEI (Maturity Model for Enterprise Interoperability) for Enterprise Interoperability.

Assuming that interoperability can be considered as a process that need a particular attention within an enterprise, we have compared these maturity models towards the ISO/IEC 15504 (SPICE) reference model. This comparison has shown the need for harmonisation to have a generic standard of maturity. As perspective, SPICE will form the backbone of our future investigation. We will thereafter refer to some of the presented maturity models; in particular, the Maturity Model for Enterprise Interoperability (MMEI), in order to establish a general framework for system interoperability [ 15 ], allowing enterprises to assess interoperability from a priori as well a posteriori context.

References

1. Thomas C. Ford , John M. Colombi , Scott R. Graham and David R. Jacques . A Survey on Interoperability Measurement, 12th ICCRTS .

2. IEEE Standards Information Network . IEEE 100, The Authoritative Dictionary of IEEE Standards Terms , Seventh Edition . New York, NY: IEEE, 2000 .

3. Naudet Y. , Latour T. , and Chen D. A systemic approach to interoperability formalization . IFAC WC 2008 , invited session on Semantic-Based Solutions for Enterprise Integration and Networking, Seoul, Korea, July 6- 11 , 2008 .

4. COMPTIA. European Interoperabilitu Framework, white paper , ICT Industry Recommandations; Brussels , 2004

5. International Organization for Standardization and International Electrotechnical Commission, ISO/IEC 15504 Software Process Improvement and Capability DEtermination Model (SPICE) , 2001 .

6. Method Integrated Team , Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1 .1: Method De nition Document Members of the Assessment, 2001 .

7. Guedria , W. Decision-support for diagnosis of system's interoperability. I-ESA'08 Doctoral Symposium , 4th International Conference Interoperability for Enterprise Software and Applications , Berlin, Germany, March 2008 .

8. Alonso , J. , De Soria , I M. , Orue-Echevarria , L. , and Vergara , M. : Enterprise collaboration maturity model (ECMM): preliminary de nition and future challenges , Enterprise Interoperability IV , Springer, 2010 .

9. C4ISR Interoperability Working Group, Levels of information systems interoperability (lisi) , Tech. report, US Department of Defense , Washington, DC, 1998 .

10. Tolk , A. , and Muguira , J.A. The levels of conceptual interoperability model , 2003 Fall Simulation Interoperability Workshop (Orlando, Florida, U.S.A.), Sept. 2003 .

11. Clark , T. , and Jones R. , Organisational interoperability maturity model for c2 , in Proc. of the 1999 Command and Control Research and Technology Symposium (U.S. Naval War College , Newport, RI , Whashington D.C.), 1999 .

12. ATHENA. Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications , FP6 -2002 -IST1 , Integrated Project Proposal, April 2003 .

13. Chen , D. , Enterprise Interoperability Framework. EMOI-INTEROP 2006

14. Guedria , W. , Naudet , Y. , and Chen , D. Maturity model for enterprise interoperability , In Enterprise Information Systems (EIS) , Taylor & Francis , 2013 .

15. Von Bertalan y, L. : General System Theory: Foundations, Development , Applications, Georges Braziller, Inc., 1968 , New York, USA.