Abderrahim Taoudi
email: abderrahim.taoudi@um5s.net.ma

Bouchaib Bounabat
email: bounabat@ensias.ma

Badr Elmir
email: b.elmir@daag.finances.gov.ma

Toward a Methodology to Control Interoperability Improvement Projects Execution

Keywords: RatIop, Control theory, Enterprise Interoperability, Project planning theory, Interoperability improvement, Automated Business Processes

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

According to IEEE definition [START_REF]IEEE standard computer dictionary: a compilation of IEEE standard computer glossaries[END_REF], 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 [START_REF] Athena | Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications[END_REF], INTEROP [START_REF] Interop | Interoperability Research for Networked Enterprises Applications and Software, network of excellence[END_REF]. Today, there is a number of mature frameworks that were developed and validated and are available to use i.e. Chen et al. [START_REF] Chen | Framework for enterprise interoperability[END_REF], ATHENA [START_REF] Athena | Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications[END_REF], LISI [START_REF]Architecture Working Group (AWG), Levels of Information Systems Interoperability (LISI)[END_REF], IDEAS [START_REF]IDEAS Project Deliverables (WP1-WP7)[END_REF], EIF [START_REF]European Interoperability Framework[END_REF]. In relation to enterprise interoperability measurement, many approaches and measures are available. Ford et al. [START_REF] Ford | A survey on interoperability measurement[END_REF] listed already a number of them. Other new measures also exist like Chen et al [START_REF] Chen | An approach for enterprise interoperability measurement[END_REF] and RatIop [START_REF] Elmir | A Novel Approach for Periodic Assessment of Business Process Interoperability[END_REF].

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 [START_REF] Chen | Framework for enterprise interoperability[END_REF] (currently under CEN/ISO standardization process) as the interoperability framework, RatIop [START_REF] Elmir | A Novel Approach for Periodic Assessment of Business Process Interoperability[END_REF] as the interoperability quantitative metric, Project Planning theory to define the optimal plan and Control theory to control projects execution.

Overview of RatIop

Several dimensions of interoperability have been defined in [START_REF]IEEE standard computer dictionary: a compilation of IEEE standard computer glossaries[END_REF], [START_REF] Guédria | Interoperability maturity models -survey and comparison[END_REF] and [START_REF] Michelson | Event-Driven Architecture Overview[END_REF]:

• 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 [START_REF] Chen | An approach for enterprise interoperability measurement[END_REF]:

• 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.

RatIop is a new quantitative ratio metric to measure interoperability between automated business processes that was developed in [START_REF] Elmir | A Novel Approach for Periodic Assessment of Business Process Interoperability[END_REF]. With this ratio, an organisation can evaluate, at any time and in a quantitative way, the degree of interoperability of its automated business processes. RatIop 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) [START_REF] Elmir | A Novel Approach for Periodic Assessment of Business Process Interoperability[END_REF] calculated as bellow: PI = 0.2 * IMML, where IMML = 1,2,3,4 or 5 [START_REF]IEEE standard computer dictionary: a compilation of IEEE standard computer glossaries[END_REF] 2. to quantify the second kind of interoperability, Interoperability compatibility, by using a modified matrix of Chen et al [START_REF] Elmir | A Novel Approach for Periodic Assessment of Business Process Interoperability[END_REF], see Table 1.

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 = DS * Qos * TS (3)
Using these three previous indicators, RatIop is calculated as bellow:

RatIop = (4)
Using this ratio, [START_REF] Elmir | Interoperability monitoring for e-government service delivery based on enterprise architecture[END_REF] 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.

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 RatIop R i , which is the actual state of interoperability, to a targeted RatIop 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.

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) [START_REF] Elmir | Interoperability monitoring for e-government service delivery based on enterprise architecture[END_REF] can be used to define a clear scenario to reach the desired RatIop 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.

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 [START_REF] Williams | The contribution of mathematical modelling to the practice of project management[END_REF] lists many deterministic and non deterministic mathematical models used to define optimal plans. Most of these models are already automated. Bellow some examples of these models:

• The standard Project Management model, PMBOK [START_REF]A Guide to the Project Management Body of Knowledge (PMBOK)[END_REF].

• 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.

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.

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 [START_REF] Gandhi | Mimo control of an apache web server: Modeling and controller design[END_REF], web servers [START_REF] Lu | A Feedback Control Approach for Guaranteeing Relative Delays in Web Servers[END_REF], lotus notes [START_REF] Gandhi | Feedback Control of a Lotus Notes Server: Modeling and Control Design[END_REF], internet [START_REF] Mascolo | Classical Control Theory for Congestion Avoidance in High-speed Internet[END_REF] and networks [START_REF] Chiu | Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks[END_REF]. 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.

Fig. 1. Feedback control diagram

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 adjust 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).

RatIop reference Definition

The reference is the RatIop of the system. Its curve will be derived from the optimal plan. We will take into account the finished tasks to calculate the projected RatIop at Plant Controller + -

y(t) w(t) r(t) e(t) = r(t) -y(t)

a time t. The objective of the control system is to minimize the deviations between the desired RatIop based on the optimal plan and the measured RatIop.

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 RatIop at this time. Bellow 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 RatIop of the system at time t r(t) = the desired RatIop 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) (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 RatIop (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 RatIop (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.

Modeling the controller

According to [START_REF] Hellerstein | Feedback Control of Computing Systems[END_REF], 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))

Toward a methodology to control interoperability improvement projects execution

The constant K is called the gain. feedback control system, the model that we will adopt is the Proportional model (PI Model) :

w(t) = w(t
The transfer function of this PI controller 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 appropriate Kp and Ki of the model. control system of interoperability improvement projects

Case study

To illustrate the approach, we will use government example used care services in a public hospital. and the usage of the IMT Tool.

Toward a methodology to control interoperability improvement projects execution

is called the gain. To achieve the four properties of our studied feedback control system, the model that we will adopt is the Proportional w(t) = w(t-1) + (Kp + Ki)*e(t) -Kp*e(t-1)

The transfer function of this PI controller is:

Kp +( Ki*z/(z-1))
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.

ot does not exceed a constant value Mp.

Using these objectives, [START_REF] Hellerstein | Feedback Control of Computing Systems[END_REF] discusses in detail the procedure to calculate the appropriate Kp and Ki of the model. With the plant and controller modelled control system of interoperability improvement projects is totally defined.

To illustrate the approach, we will use a real world example which is the used in [START_REF] Elmir | Interoperability monitoring for e-government service delivery based on enterprise architecture[END_REF]. This case consists of an online payment for health care services in a public hospital. It was used in [START_REF] Elmir | Interoperability monitoring for e-government service delivery based on enterprise architecture[END_REF] to illustrate RatIop assessment and the usage of the IMT Tool. This system is described in Figure 2.

Fig. 2. Online payment business process

Toward a methodology to control interoperability improvement projects execution 7 operties of our studied feedback control system, the model that we will adopt is the Proportional-Integral (6) [START_REF]European Interoperability Framework[END_REF] discusses in detail the procedure to calculate the modelled, the a real world example which is the e-. This case consists of an online payment for health illustrate RatIop assessment

The main objective of this case study is to illustrate the details of steps and calculations used by the approach presented in this paper.

Initial RatIop assessment

During the implementation phase, three incompatibilities were detected: Using the framework defined in [START_REF] Elmir | A Novel Approach for Periodic Assessment of Business Process Interoperability[END_REF] and section 2 of this paper, the initial interoperability compatibility matrix for the incompatibilities described above is listed in Table 2: Using the framework defined in [START_REF] Elmir | A Novel Approach for Periodic Assessment of Business Process Interoperability[END_REF] and section 2 of this paper, the initial interoperability assessment is described in Table 3:

Project objectives definition

The aim of the project is to acheive 80% degree of interoperability instead of the current interoperability degree of 69%. So, the targeted RatIop is 0,8. Using the IMT Tool [START_REF] Elmir | Interoperability monitoring for e-government service delivery based on enterprise architecture[END_REF], 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.

Optimal Plan Definition

Using these objectives, the project tasks are defined in Table 4. The duration unit is the week: Task5: Improving the end user satisfaction level 3 5

Abderrahim Taoudi 1, Bouchaib Bounabat 1, All these tasks are independent. affected to it. The total resources for the project are 6. optimal plan is described in figure 3.

RatIop reference Definition

Using this optimal plan, the RatIop reference is described in

Modeling the plant system

Figure 5 illustrate the evolution or RatIop depending on Using the least square regression method, the plant system parameters estimation is:

Abderrahim Taoudi 1, Bouchaib Bounabat 1, Badr Elmir 1

All these tasks are independent. A task cannot begin if the needed resources are not The total resources for the project are 6. Using project theory, t optimal plan is described in figure 3.

Fig. 3. Optimal plan

RatIop reference Definition

Using this optimal plan, the RatIop reference is described in figure 4: A task cannot begin if the needed resources are not Using project theory, the the least square regression method, the plant system parameters estimation is:

Modeling the controller

The objectives of our design are:

• The system is stable

We can see that the value "4.4" is approximately the mean value of task resources. If the RatIop 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.

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 RatIop. 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 (RatIop). 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.

Fig. 4 .Figure 5

 45 Fig. 4. RatIop Reference

Fig. 5 .

 5 Fig. 5. RatIop over time and resources

Table 1 .

 1 Interoperability compatibility

		Conceptual		Organizational	Technology
		syntactic	sema	Authorities	organisation	platform	communic
			ntic	resposabilities			ation
	Business	0/1	0/1	0/1	0/1	0/1	0/1
	Process	0/1	0/1	0/1	0/1	0/1	0/1
	Service	0/1	0/1	0/1	0/1	0/1	0/1
	Data	0/1	0/1	0/1	0/1	0/1	0/1
	By noting dc ij the elements of this matrix, this potential is calculated as bellow:
		DC = 1-((∑dc ij )/24), where dc ij = 0 or 1

•

  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 notsynchronized. 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.

Table 2 .

 2 Initial Interoperability compatibility

		Conceptual	Organizational		Technology
		syntactic	semantic	Authorities	organisation platform communicat
				responsibilities			ion
	Business	0	0	0	0	1	1
	Process	1	1	0	0	0	0
	Service	0	0	0	0	0	0
	Data	0	0	0	1	0	0

Table 3 .

 3 Initial RatIop value

	Metric	Description	Value
	Maturity Level	IMML	0,4
	Interoperability	DC	0,79
	compatibility
	Overall application	DS	0,9
	servers availability
	Network quality of	QoS	1
	service
	End user satisfaction	TS	0,8
	RatIop metric	RatIop	0,69

Table 4 .

 4 Tasks description

	Tasks	Duration (in	Resources
		weeks)	need
	Task1: removing exchange	3	5
	with mutual servants
	incompatibilities
	Task2: removing exchange	5	6
	with National social
	security fund
	incompatibilities
	Task3: removing exchange	5	6
	with private insurance
	incompatibilities
	Task4: Improving the	2	2
	Overall application servers'
	availability

  • 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,[START_REF] Hellerstein | Feedback Control of Computing Systems[END_REF] 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)


Manfred Reichert
email: manfred.reichert@uni-ulm.de

Collaboration and Interoperability Support for

Keywords: networked enterprises, collaboration, interoperability, agility, business process change, business process compliance

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Brief Biography

Manfred Reichert is professor at the University of Ulm, Germany and co-director of the Institute of Databases and Information Systems.

His major research interests are next generation process management technology (e.g., adaptive processes, process variability, data-driven and object-centric processes, mobile processes), service-oriented computing (e.g., service interoperability, service evolution), and advanced applications for flexible information systems (e.g., e-health and automotive engineering).

Together with Peter Dadam he pioneered the work on the ADEPT process management technology and he is co-founder of the AristaFlow GmbH. Manfred has been participating in numerous research projects in the BPM area and contributed more than 200 scientific papers on BPM-related topics. His book entitled "Enabling Flexibility in Process-Aware Information Systems" was published by Springer in September 2012. Manfred has been PC Co-Chair of the BPM'08, CoopIS'11, and EDOC'13 conferences and General Chair of the BPM'09 conference.


Arnon Rosenthal

Len Seligman
email: seligman@mitre.org

M David

Adriane Chapman
email: achapman@mitre.org

Fit for Purpose: Toward an Engineering Basis for Data Exchange Standards

Keywords: Science basis for enterprise interoperability, experience reports on interoperability solutions, reference ontologies and mapping mechanisms, model-to-model transformations

Data standards are a powerful, real-world tool for enterprise interoperability, yet there exists no rigorous methodology for selecting among alternative standards approaches. This paper is a first step toward creating a detailed engineering basis for choosing among standards approaches. We define a specific sub-problem within a community's data sharing challenge, and focus on it in depth. We describe the major choices (kinds of standards) applied to that task, examining tradeoffs. We present characteristics of a data sharing community that one should consider in selecting a standards approach-such as relative power, motivation level, and technical sophistication of different participants-and illustrate with real-world examples. We then show that one can state simple decision rules (based on engineering experience) that system engineers without decades of data experience can apply. We also comment on the methodology used, extracting lessons (e.g., "negative rules are simpler") that can be used in similar analyses on other issues.

Introduction

Many of the biggest practical successes in data integration have been due to effective use of data standards [9]. In one survey, a substantial majority of participants in data standards development indicated that high quality data standards lead to improved interoperability [4]. The reason for this is straightforward: the right standard for a given community reduces the amount of data heterogeneity that must be bridged and therefore saves time and effort when new data exchanges must be built. Unfortunately, there are also many cases of failures, where standards failed to provide positive return on investment [9].

Despite the importance of good data standards, the research community to date has offered practitioners little help in selecting a standards strategy that will work for their particular data sharing community. This is perhaps not surprising, since researchers naturally focus on well-bounded problems suited to deep computational analysis (e.g., schema matching [8, 2, 12], mapping generation [3, 7]). This research has spawned some powerful and useful commercial and open source integration tools. Yet researchers are mostly mute on the important strategic questions facing data integration professionals that must pick a standardization approach appropriate to their data sharing community. Addressing these strategic questions is a necessary precondition to establishing a scientific and engineering basis for enterprise interoperability.

This paper identifies a key strategic question that must be addressed by a science or engineering process of enterprise interoperability-how to select a data exchange standardization approach that is fit for its intended purpose-and makes progress addressing it. Our contributions are:

 We describe characteristics of a data sharing community that one should consider in selecting a data standards approach and illustrate with real-world examples;  We delineate the broad categories of data standards and present the relative strengths and weaknesses of each;  We present an initial set of decision rules that help a data integration expert pick an appropriate type of standard for a particular data sharing community; and  We describe important topics for future research on strategic help for data integration professionals.

Instead of presenting rigorous results on a narrow question, this paper presents a novel, strategic perspective on a familiar problem (data integration) on which novel perspectives are rare. The state of the practice is "Do a tradeoff analysis and apply engineering judgment, based on your knowledge of the various technologies". We hope that this paper will inspire other researchers to address problems of strategic importance that can truly be the basis of an engineering discipline of enterprise interoperability.

Scope

For this paper, we assume that a community is interested in creating many exchanges, covering similar data, such as might be described by a message standard. For example, among a region's medical offices, hospitals, labs, pharmacies, insurance companies, and relevant government agencies, there are many reasons different sets of partners would want to exchange basic medical information about patients. The goal of a data standard in such a community is to minimize the amount of development effort required to build and maintain all the required data exchanges. This paper examines several ways that data standards are expressed and used, discusses the pragmatic tradeoffs, and provides some easy to use decision rules to guide a selection for a particular data exchange problem.

Terminology in this area is diverse and conflicting. In this paper, an exchange concerns all work necessary to take data between data producer and consumer organizations. A (full) transform is the executable function that maps data from a producer's export interface to a consumer import interface. To permit direct comparisons of al-ternate approaches on a well-defined task, we seek specifically to minimize the effort to develop and maintain the transforms used by a set of exchanges.

A message-based transform is composed of two sub-transforms, from the producer's native interface to create a structure conforming to the message standard, and one onward to the consumer interface. The message standard is often described as an XML schema, supplemented by requirements captured in English or as code sets. Data typically flows point to point, being transformed en route, usually without a central server. The end points of any transform are called its source and target.

To write a transform, one needs to understand what differences between source and target need to be spanned. value format (the coded value "54131-8" refers to Gender under LOINC; dates have many representations, such as "dd-mm-yyyy" or "yyyymmdd"), and structure (e.g., HL7 C32 message, as a tree). To make descriptions more concrete, we will assume system interfaces and the message standards use XML; the work still applies when alternatives to XML are used. A typical description is part formal (i.e., interpretable by tools; XML schemas are formal) and partly English. An alternative to full description is to identify correspondencesareas where the source conforms to the target interface and the transform need do nothing. Formal descriptions reduce ambiguity, and may drive automated tools, such as when multiple partners' data schemata are mapped to a common reference ontology.

Paper Roadmap

Section 2 describes characteristics of a data sharing community that affect the choice of an appropriate data standards strategy. Section 3 describes the major styles of data standards, along with examples. Following a discussion of pragmatics (Section 4), Section 5 presents decision rules for selecting among the major standardization strategies described. These rules consider factors described in all the previous sections. Section 6 concludes with topics for future research.

Characteristics of Data Sharing Communities

This section describes key characteristics of a data sharing community that affect the choice of an appropriate data standards strategy, illustrated with real-world examples. (The list of characteristics is not comprehensive, but emphasizes factors that have generally received less attention in prior research. [START_REF] Bernstein | Industrial-Strength Schema Matching[END_REF] First, is this a community of peers with roughly equal power or is there is a dominant player (a so-called "800 pound gorilla")? The Indiana Health Information Ex-change [START_REF] Doan | Learning to Match the Schemas of Databases: A Multistrategy Approach[END_REF] is an example of a community of peers, in which hospitals, rehabilitation centers, long term care facilities, laboratories, imaging centers, clinics, community health centers and other healthcare organizations exchange health information. In contrast, the Centers for Medicare and Medicaid Services (CMS) have a dominant position in the U.S. healthcare marketplace, covering almost one third of the US population [START_REF] Fagin | Data Exchange: Semantics and Query Answering[END_REF] ; providers that wish to receive payment from this major player have strong incentives to support CMS' data submission requirements.

Second, even when there is a dominant player, communities differ in the extent to which the dominant organization uses its power dictatorially or benevolently. Using the former approach, financial regulators could simply threaten penalties or legal action against non-compliant companies. Benevolent financial regulators might also offer tools that ease compliance as well as benefits to data submitters (e.g., by selecting a standard and providing tools to minimize submitters' costs, or by allowing participating financial institutions to see industry-wide data and compare it to their own practices).

A third issue is the motivation level of participants. Information consumers are usually highly motivated, since they are the ones that derive value by using the exchanged data. Whether data producers are similarly motivated depends upon their perception of benefits vs. costs and risks. Producers can be motivated by legal mandates (e.g., taxpayers that fail to provide the government required information can face penalties or even jail), financial incentives (e.g., the U.S. government is offering payments to healthcare providers that demonstrate "meaningful use" of electronic health records technology), or a perception of benefit (e.g., U.S. airlines and other stakeholders voluntarily provide safety information to the Aviation Safety Information Analysis and Sharing4 collaboration because of a shared desire to improve aviation safety). As another example, drug companies are highly motivated to comply with Food and Drug Administration data submission requirements, since they need FDA approval to be able to sell a new drug in the U.S. market. In contrast, for an application that analyzes a company's competitors' web-accessible price lists, the data producers (other companies) have no motivation to help.

Fourth, participants often vary greatly in terms of both technical sophistication and financial resources. In sharing emergency response information, U.S. state and local authorities generally have far fewer resources and less technical sophistication than U.S. federal government agencies. In contrast, in the financial regulatory environment, data producers (i.e., financial institutions) have ample resources and sophisticated IT capabilities. Healthcare information exchange varies greatly; some providers (large health maintenance organizations or hospital systems) are amply resourced, while others (individual doctors' offices) have little or no IT budget or capabilities. In such cases, it is often valuable for a government entity (such as the U.S. Office of the National Coordinator for Health IT), an industry consortium, or an open source com-munity to offer tools and/or services that lower the barriers to data sharing for underresourced players.

These issues are all important in considering the most appropriate data standards strategy. Much prior research fails to realistically consider participants' incentives [10]; this has also led to some catastrophic failures in real-world data integration efforts [9].

Standards Options

This section presents several flavors of data standards and usage. For each, we ask:  Are standard messages generated, as an intermediate result? If so, how tightly does the standard constrain them? How much of that standard is expressed formally?  Do the formal descriptions of data producer, consumer, and (if used) message standard suffice for developing transform code? Are all these interfaces described using the same formalism? Is that formalism standard or proprietary?  Who needs to do what work to create a transformation? How many topics must a community resolve in order to create their descriptive standard?

Our biggest contribution lies in the nature of the analysisa well-defined task within data exchange, and description of the alternative models. We expect the set of decision rules to be extended and refined by later researchers. While there are many discussions of strengths and weaknesses, we know of no systematic comparison and usable set of decision rules. [14] begins studying the area scientifically; we seek to create an engineering solution, usable by MITRE's system engineers (who are not all data experts).

Our assessments of the strengths and weaknesses of each standardization approach are based on over 50+ years' direct experience among the co-authors, consulting on U.S. government data integration efforts, plus many discussions with other data integration experts at MITRE.

"Nailed Down" Exchange Schemas that Specify a Single Physical Data Structure

Approach 1: Create a message-based transform, using a detailed, straightforward message standard that specifies a fixed meaning and format for each element. An XML schema often describes the structure, simple constraints on content, plus part of the syntax. Remaining message-standard details are described in English, in a proprietary tool, or as standard code sets (e.g., "countryOfOrigin uses FIPS Country Codes"). Transform developers must be aware of these details to ensure that the delivered content meets the needs of the consumer. A natural division of labor is that each producer/consumer creates one sub-transform between their own interface and the standard; these are composed automatically to create producer-to-consumer transforms. For example, if a community agrees to exchange patient information via a greenCDA [START_REF] Helmer | Enabling collaborative research using the Biomedical Informatics Research Network (BIRN)[END_REF] XML message, each participating data producer and consumer will have to develop the sub-transform from its electronic health record format to the standard. [START_REF] Markus | Industry-wide information systems standardization as collective action: the case of the U.S. residential mortgage industry[END_REF] Documentation for producer and consumer interfaces is typically left to each organization.

Most exchanges today take this approach. For example, the National Information Exchange Model (NIEM) [START_REF] Miller | The Clio Project: Managing Heterogeneity[END_REF] describes a process that employs reusable schema components to build message standards, which NIEM calls information exchange package descriptions (IEPD). Many IEPDs which are built fall into the category of "nailed down" exchange schemas. The web's Really Simple Syndication (RSS) is another important example.

Discussion: The popularity of approach 1 is based on real advantages. Only one sub-transform need be built for each producer or consumer. When development is manual, there are usually large savings over creating a separate data transform to each partner. It is often natural for each producer or consumer to build and host its own sub-transforms. Otherwise (e.g., for secondary uses), whoever benefits from the exchange can build and/or host the transforms.

There are still difficulties. Developing one sub-transform per interface is still a significant cost, and a real barrier to entry for technology-challenged organizations. Furthermore, if a community extends the standard, they face costs to create transforms that exploit the extensions. Depending on the design of the transform code, a later (extended) version of a standard may not be plug-compatible with an older version. Precision (numeric or in concept definitions) may be lost in conversion to the standard, even though the consumer could have accommodated it.

The community cost to develop a message standard can be high, depending on the complexity of the message standard and interface and the number of stakeholders with distinct points of view. Not only do they need to agree on data content, but they must also agree on a tree structure and value formatswhat concepts are on the top of hierarchical structures and whose native representation to use.

Flexible Exchange Schemas that Permit Alternate Representations

Approach 2: Participants agree on a message structure but allow alternative formats for some of the individual properties and occasionally for overall message syntax. For example, they might allow different measurement units (feet vs. meters), value syntax and international codesets (National Drug Code or RxNorm to describe medications), and allow both XML and JSON to represent the tree.

With this approach, a producer chooses the most convenient supported format for each item in the standard message, and then creates a sub-transform to it. Just as in the previous section, consumers create transforms from the message, to the consum-er's format, converting as necessary. The formalism is often XML schema, with certain elements being assigned a special meaning as descriptors of other elements.

The C32 and Clinical Document Architecture (CDA) standards are examples in this area. CDA permits the use of a number of different coding systems. For example, in a Continuity of Care (CCD) document, different codes might indicate the role of a physician, or the race of a patient. But the content of the code itself is not fixed; the standard may permit several coding systems, such as SNOMED or ICD-9 to describe medical conditions. As a different example, consider "message envelope" designs that contain a standard structure for the manifest of the but leave the contents open to customization depending on the user; an example for health information is Restful Health Exchange (RHEx). [START_REF] Rahm | A Survey of Approaches to Automatic Schema Matching[END_REF] Discussion: This approach is friendlier to data producers. By giving them alternate submission formats, it lowers the barrier for entry. This is especially important when producers have limited resources or a low motivation to contribute data. An additional advantage is that this approach can avoid gratuitous loss of data precision caused by a "least common denominator" interchange standard, in cases where the source and target may both use the same higher precision representation. No exchange standard can remedy a situation where the consumer requires information, or precision, that the producer does not possess.

The major drawback of permitting alternate representations within the standard is that to be interoperable with all producing systems, each consumer's sub-transform becomes much more complex; it must interpret descriptors of the representation choice selected and then invoke the correct format translation. Also, while XML schema can specify the message structure (Approach 1), no popular standard captures the special usage for format descriptor elements.

To see the advantage of flexible representations, a medical data exchange standard could allow producers to furnish prescribedMedication using either National Drug Code or RxNorm, given that straightforward conversions exist from NDC to RxNorm. The advantages are less clear cut when such conversions cannot be automated. For example, while ICD-9, ICD-10, and SNOMED could all be used for diagnosis, there is often no straightforward mapping among them. If a standard allowed all of those representations, then the consumer will only see diagnoses for which there is an unambiguous mapping to his chosen coding scheme.

A final consideration with this approach is the cost of obtaining the consensus necessary to develop the standard. While initially this cost may be less than approach 1, since supporting several popular formats can avoid some arguments, subsequent costs may be similar, as participants argue about whether to accept the next one alternate representation, and the next.

"Enriched" Exchange Schema (Schema plus Formal Descriptions)

Approach 3: This approach enhances approach 1, adding formal descriptions plus automated tools that compare descriptions and in some cases automatically generate sub-transforms to and from a standard message.

Here, the community must choose a formalism for capturing semantic knowledge that XML Schema does not capture (e.g., that hemogram is a kind of labTest or anesthesiologist is a kind of physician); popular formalisms for capturing such a domain model include UML, the Resource Description Framework (RDF) [START_REF] Rosenthal | From Semantic Integration to Semantics Management: Case Studies and a Way Forward[END_REF] and Web Ontology Language (OWL). [START_REF] Rosenthal | Beyond the Sandbox: How Integration Researchers Can Actually Help Integration[END_REF] Then, instead of just presenting the community with an exchange schema (as in approach 1), the elements of the exchange schema are described by correspondences to elements in the domain model. [START_REF] Das Sarma | Halevy: Bootstrapping pay-as-you-go data integration systems[END_REF] (One could, more awkwardly and less expressively, use the XML exchange schema itself as a domain model). Whenever producers or consumers describe their systems in terms of the same domain model, data exchange is eased. First, there is the possibility of doing automated mediation using sophisticated tools that automatically generate some of the sub-transforms. Crucially, the descriptive tasks can be done by a domain analyst, or in less critical settings, a power user. When automated transform generation succeeds, there is much less need for programming. Costs are reduced, and more systems can be included in exchanges. In addition, even when fully automated mediation is not possible, the additional semantic richness of the descriptions can make the programmer's job substantially easier.

Discussion: This approach has the potential to reduce the cost and time required to create sub-transforms. Compared with approach 1, it adds formal capture of the knowledge that the developer needed for generating mappings. Major vendors' tools (e.g., IBM, Microsoft) have proprietary logic-based formalisms for expressing and exploiting correspondences to generate transforms. This represents a big advance over the current state of the practice of capturing correspondences in Excel or (even worse) Powerpoint followed by manual programming (e.g., in Java) of sub-transforms. [START_REF] Shvaiko | A Survey of Schema-Based Matching Approaches[END_REF] Another advantage of this approach is support for incremental adoption. Where automated transform generation is impossible or is incomplete, one can always fall back on the techniques of approach 1 to fill in the gaps.

A drawback of this approach is that while individual correspondence capture acts are simpler, the setup is not. The community (or some members) must invest in sophisticated tools, and the skills to apply them, when transforms cannot be generated automatically. This may be a challenge for communities in which key participants are poor in either resources or technical sophistication. In compensation, if the communi-9 http://www.w3.org/RDF/ 10 http://www.w3.org/OWL/ [START_REF] Das Sarma | Halevy: Bootstrapping pay-as-you-go data integration systems[END_REF] There are two flavors of correspondence: a simple "is compatible with", and "is derivable by <formula>". From these fine grained correspondences, a tool can derive a transform between whole schemas. Correspondences can also include small sets of elements, e.g., M, D, Y  Date. [START_REF] Shvaiko | A Survey of Schema-Based Matching Approaches[END_REF] One shortcoming of current tools is they have difficulty making very large schemas and the correspondences among them intelligible [1].

ty can come up with a strategy to address these challenges (e.g., by providing free tools or putting the mediation burden primarily on better resourced partners), the approach has the potential to substantially reduce the effort required to build new data exchanges.

We considered a hybrid this approach with approach 2 (i.e., using a "semantically enriched" schema but with alternate acceptable representations), but none of the current standards provides for elements (i.e., meta-attributes) that describe the format of other elements.

Formal Descriptions Without an Intermediate Message

Approach 4 rests on having a domain model, and formally describing all producer and consumer interfaces in terms of this model, all in the same formalism. Using these descriptions, one generates transforms for all desired exchanges, going directly from producer to consumer interface. The domain model acts as intermediary for descriptions, but not for physically creating messages.

Automation is essential because for each producer, one must generate direct mappings to all of its exchange partners, not just to a standard. Formal descriptions are essential to automation. The community must again acquire tools and skills, but will need fewer programmers. Then, the community creates its standard domain model, and some entities within it acquire the tools and skill to use them.

There are major risks with this approach. If the community is not new, organizations who have already built their sub-transforms will have little short term reason to create the needed formal descriptions. The tools are bleeding edge and not industrial strength; the techniques are unfamiliar to existing developers. And the larger number of transforms makes manual coding a less effective backup plan. Thus, its niche may be limited to new efforts, plus situations where translation to a fixed message format is not practical.

The Biomedical Informatics Research Network (BIRN) has begun to use this approach for real information exchanges [5]. Interestingly, BIRN mediates not just data transformation, but also queries. In addition, many models exist to describe portions of the health domain, including the Federal Health Information Models (FHIMS [START_REF] Zhao | Vertical E-Business Standards and Standards Developing Organizations: A conceptual framework[END_REF] ), and the NIEM UML Profile14 and the Health Level 7 Reference Information Model (HL7 RIM) 15 , which is used to derive other standards like the Clinical Document Architecture (CDA). While these models by themselves do not constitute a "formal description" approach, they do provide useful building blocks for such an approach.

Discussion: This approach potentially makes interoperability, and especially extensibility, an order of magnitude cheaper, compared to standards plus hand-coded transforms (approaches 1 and 2). Also, since the tools convert values directly between producer and consumer representations without an intermediary, the standard does not cause unnecessary loss of precision. Extension is particularly easy -GUIs and wiz-ards relate the new standard elements to elements in source and target, and a mediator generates updated transforms. No programmer and test organization will be involved, at least once the tools mature.

Unfortunately, present transform-generation tools are unsatisfactory. Without reliable automation, it is not feasible to generate a separate transform for each exchange. For long term planners such as CIOs and architects, it is worth pointing out that without formal descriptions of systems, it will not be possible to generate transforms automatically; as such, those descriptions will eventually be necessary if systems are to move beyond hand-coded transforms.

Pragmatics and Metrics

In selecting a data exchange standard, there are several aspects of the sharing problem that everyone needs to examine, whether or not they have additional specialized concerns (a few were touched on in Section 2):  Timeline: how much time does the community have before a capability is needed?  Ambition level and risk tolerance: Will managers accept some risk, in hope of transformative improvements, long term?  Legacy: Are there significant legacy message standards? One or multiple?  Funding and incentive structure: Are all players willing to invest? Will a central fund or major player support community needs? Will consumers fund descriptions and sub-transforms of producers? What is the time horizon for costs?  Technical skills: which technologies are developers familiar with? Do all organizations have software developers?  Number of producers and consumers: how many are there, both absolute and relative? What are their incentives (desire to exchange, who hosts, who funds)?  The rate of change of the domain: How often are extensions requested, and with what timeline? Is there likely to be merger with another community?

We do not have a formal metric approach. It is easy to estimate the number of transforms to be programmed, semantic correspondences to be represented, and decisions of each type in defining a standard. However, many other issues are dealt with qualitatively, because there is no general means of estimating them. How much faster is it to describe an interface, rather than code transforms? Stakeholders will agree to an approach more quickly if multiple formats (including theirs) are supported, but that decision may have costs in terms of transforms required. Analysis and programming effort is also notoriously hard to estimate correctly. Finally, it is usually hard to trade political versus technical costs.

Rather than require decision makers to estimate all of these difficult parameters, our decision rules use qualitative terms (e.g., "many more producers than consumers") which decision makers must interpret in their program context.

Decision rules -Exclusions

This work sought to simplify decisions for MITRE's front line engineers, few of whom are data researchers. For that reason, we tackled one narrow problem, and provide simple decision rules. The rules are based on the authors' engineering judgment, based on decades of experience supporting U.S. government interoperability efforts, observing both successes and failures.

We initially tried to formulate positive rules (i.e., "Use approach #1 under these circumstances") for selecting a standards approach but quickly ran into a problem: most rules had a long series of required conditions, making it difficult to specify modular rules. Even worse, a positive recommendation requires comparing with all alternativesso it is almost impossible to be simple. Instead, we found it much more natural to formulate negative rules. These permit data integration experts to eliminate possibilities based on what they know of their situation, and narrow down the list of options. If all alternatives are excluded, then the community must change its stated requirements or assumed resources.

Table 1 shows rules for ruling out approaches, using the following labels as abbreviations for approaches 1 -4:

 1: Fixed  2: Flexible  3: Enriched  4: Formal

Conclusions and Future Research

We have presented important characteristics of data sharing communities with realworld examples, several approaches to data exchange standards, and some simple decision rules for how to select a data exchange approach based on the community's situation. The current popular approach (a simple standard XML schema) is the best low-risk, moderate-immediate-cost approach today, unless there are special situations of avoiding information loss or favoring producers over consumers. Even at one subtransform per producer or consumer, programmers are needed, and coding, testing, and maintenance costs can be high ($millions/year, for USMTF systems working with the Air Tasking Order message).

For the long term, automated mediation offers hope of order of magnitude further improvements. Avoiding those costs will eventually require automated generation, driven by formal descriptions of participant systems' element semantics and representation. Automated generation is becoming practical today with approach 3; one can supplement the automatically generated transforms with manually coded ones wherever necessary. This work opens several avenues for future research. First, our categories and rules are just a first-step and allow ample room for refinement. Second, there is a need for empirical research to test our engineering judgments; experimentation or surveys are needed to see how systems engineers are guided by such decision rules, and whether they are satisfied with the results. Third, there is a continuing need for progress on automated mediators that support approaches 3 and (especially) 4. One important area is how to handle situations where auto-generation of a sub-transform is only partially successful. How should tools present the remaining work that needs to be done to systems engineers to maximize their effectiveness? Will the resulting code be maintainable? How should this be handled in cases where the consumer has no development resources and is willing to accept "best effort" data, as for example in recent "pay as you go" data integration research [11]? Additionally, one can apply a similar methodology to other problems involved in data sharing, such as populating the exchange message (we considered schema, not contents), access rights, or transport security. One can also dig deeper into how values or codesets are specified and converted. Finally, the general methodology-create a bounded problem important to practitioners and derive simple, modular decision rules-could be applied in other domains.

  These differences may involve meaning (what is a patient, a testDate, a homeState, or a secondaryDiagnosis), value domains (what is meant by Date, State, or Diagnosis; what values are allowed for each?),

Table 1 : Rules for Excluding Data Standardization Approaches Situation Excluded Approaches Justification and Comments

 1

	Want to minimize the need for	1: Fixed,	These approaches require programmers,
	programmers in generating trans-	2: Flexible	testers, and accreditors. They are not
	forms		agile, nor suited for in-the-field improv-
			isation.
	Transform-generator tools can-	4:Formal,	Approach 4 depends completely on
	not be effectively deployed at	3: Enriched	mediation, so must be ruled out entirely.
	all. Either:		Approach 3 is more amenable to incre-
	 Tool purchase plus skill-center		mental adoption, since less capable
	costs seem too high, and no		partners can map to the physical sche-
	organization will step up to		ma, as in Approach 1. Notes:
	support them		 Open source avoids licensing, but
	 No transform-generator prod-		sometimes has higher people costs
	uct is effective (e.g., on very		 If a vendor's tool suite is already in
	large schemas)		use, skills and metadata may be
	 Short term focus with little		available. Adding a transform-
	concern for long term support		generation capability product may be
			less expensive.
	Does the community already	4: Formal	Automated mediation involves both
	have many transform-based		ends' being documented formally; sys-
	exchanges working?		tems that have satisfactory sub-
			transforms will not invest in formal
			descriptions
	The burden on producers must	1: Fixed	Approach 2 provides flexibility for
	be minimized.		producers to use different formats.
	Producers will provide data in	2: Flexible	Approach 2 greatly increases consum-
	any case, and do not greatly		ers' costs.
	outnumber consumers
	Data resolution needs (numeric,	1: Fixed	Permits certain exchange pairs to have
	concept specificity) differ; the		finer qualitative categories (e.g. left
	community needs to:		ventricle valve failure, rather than heart
	 Avoid "lossy" exchange; or		attack) or finer granularity. Other ap-
	 Avoid overhead of high reso-		proaches avoid the least common de-
	lution formats		nominator problem of Approach 1.
	A typical message has many	4: Formal	Multicasting a standardized message to
	consumers		all consumers can save bandwidth.

[START_REF] Zhao | Vertical E-Business Standards and Standards Developing Organizations: A conceptual framework[END_REF] presents additional factors and offers a useful conceptual framework for standards communities, while[START_REF] Markus | Industry-wide information systems standardization as collective action: the case of the U.S. residential mortgage industry[END_REF] offers additional insights on the issues of motivation and technical sophistication of participants.

http://www.ihie.com/

http://cms.gov/

http://www.asias.aero/

http://wiki.hl7.org/index.php?title=GreenCDA_Project

In the event that the producer or consumer organization is using a vendor's electronic health record system, it be able to acquire the data transform code as a part of the software package or as an add-on.

http://niem.gov

http://wiki.siframework.org/RHEx

http://www.fhims.org/

https://www.niem.gov/news/Pages/uml-profile.aspx

http://www.hl7.org/implement/standards/rim.cfm

Acknowledgments. We thank Prof. Harry Zhu, Rob McCready, Mary Pulvermacher, and the anonymous referees for their helpful comments.