Jannik Laval
email: jannik.laval@univ-lyon2.fr

Dr Chantal Cherifi
email: chantal.bonnercherifi@univ-lyon2.fr

Vincent Cheutet
email: vincent.cheutet@insa-lyon.fr

Towards the measurement of Enterprise Information Systems agility to support EIS improving projects

Keywords: Agility, enterprise information system, metrics, improvement project

Enterprise information systems (EIS) are directly implied in the global performance of an organisation. Nevertheless, their potential rigidity in comparison with the required fast evolution of the supported organisation remains an important open research question. The proposed research work aims to define and evaluate the agility of an EIS, in order to assist both software engineers and business managers in EIS improvement projects. In particular, a framework is proposed to structure the different existing metrics on agility according to the improvements needs and the intrinsic characteristics of an information system.

Introduction

In a context where the evolution capacity of an organisation is a key factor for its success story, the control of its Enterprise Information System (EIS) dynamics is of prior interest. A large literature has proven the impact of the EIS on the global performance of a company [START_REF] Liu | The impact of IT capabilities on firm performance: The mediating roles of absorptive capacity and supply chain agility[END_REF][START_REF] Garcia-Alcaraz | The impact of information and communication technologies (ICT) on agility, operating, and economical performance of supply chain[END_REF], and several studies showed positive correlations between business-EIS alignment and organizational performance since years [START_REF] Papp | Business-IT alignment: productivity paradox payoff?[END_REF][START_REF] Trinh-Phuong | Enterprise systems and organizational agility: A review of the literature and conceptual framework[END_REF][START_REF] Wiengarten | Exploring the important role of organisational factors in IT business value: Taking a contingency perspective on the resource-based view[END_REF].

Nevertheless, the acceleration of the organisation changes implies a modification of how EIS evolution and control have to be tackled. Classically, once the alignment is built, the environment of the organisation evolves and changes, requiring an adjustment of the alignment and its evolution over time. The evolution of the alignment along time is a complex question [START_REF] Vessey | The dynamics of sustainable IS alignment: The case for IS adaptivity[END_REF]) that is ranked recurrently as one of the major preoccupations of managers. Indeed, this evolution has to be managed not only from an IT point of view but also from strategical and organisational perspectives.

In this research work, our target are the existing EIS in the considered organisations with the objective of improving the performance of those EIS. Hence, we consider the problem with an EIS re-engineering point of view, rather than with a software development perspective, with needs coming from business and not from technology. As a consequence, the control of the EIS dynamics may be not so mature and has to be improved.

More precisely, we adopt a Lean vision for improvement projects, following a methodology in four main steps (figure 1 placing the first three steps):

1. Diagnostic based on performance measurements at the current situation, 2. Vision definition on expected performance level agreement, 3. Path definition between the current situation and the vision one, 4. Path control to ensure the consistency between the realised actions and the initial path.

With this perspective, EIS agility is often considered as the major key characteristics in the uncertain and ever-changing business environment that is the current reality for companies [START_REF] Rasouli | A process aware information system to support agility in relief operations[END_REF][START_REF] Tarafdar | Agile supply chain strategy and supply chain performance: complementary roles of supply chain practices and information systems capability for agility[END_REF]. [START_REF] Galliers | Strategizing for agility: Confronting information systems inflexibility in dynamic environments[END_REF] claims that the dynamic nature of the environment implies to deal with agile information systems. He highlights the need for information system strategizing in order to reach alignment. Even if the definition of agility is ambivalent in scientific literature and industry, agility can be Figure 1 Improvement project global methodology defined as: "the continual readiness of an entity to rapidly or inherently, pro-actively or reactively, embrace change, through high quality, simplistic, economical components and relationships with its environment" [START_REF] Conboy | Toward a conceptual framework of agile methods: A study of agility in different disciplines[END_REF]. Information System (IS) agility generally deals with the Information Technology (IT) problems that is to say agile IS development or IT for sensing, diagnosing and responding in real time to changes without focusing on enterprise organisation [START_REF] Baskerville | Post-agility: What follows a decade of agility?[END_REF][START_REF] Lowry | Creating agile organizations through IT: The influence of internal IT service perceptions on IT service quality and IT agility[END_REF].

In this research work, we make the hypothesis that EIS agility can not be considered only as a characteristics of its evolution process but also as a core and intrinsic characteristics of the system. We hence increase the range of performance indicators that define and evaluate the behaviour of an EIS.

The research question under these conditions is: how to measure agility as key performance indicator for an existing enterprise information system, with an improvement project perspective ? This measure is required in the the global methodology at the first step to clearly and factually evaluate the initial situation and at the second step to define a shareable and reachable state. Metrics and measures are the key elements to achieve these objectives [START_REF] Slayton | Measuring risk: Computer security metrics, automation, and learning[END_REF].

In order to answer this question, we propose a framework that defines a set of potential metrics that can be used in order to evaluate the agility performance of an existing EIS. In fact, due to the diversity of EIS, of organisations and usage, a unique set of metrics cannot be defined to answer this research gap. As a consequence, the framework is designed to be modular. Indeed, according to the business needs, the EIS maturity and overall context, one can select a consistent subset of the framework to evaluate the performance and propose a vision.

The paper is structured as follow. Section 2 focuses on information system change management. In Section 3, the definition of agility is tackled. The proposed agility metrics framework is presented in Section 4. Finally, Section 5 is dedicated to discussions and perspectives.

2 Information system change management

EIS definition

From a system point of view, any organisation is defined by three layers namely operating, decision and information [START_REF] Le Moigne | La modélisation des systèmes complexes[END_REF]. Consequently, more than a simple software tool, an information system also integrates the organisation layers. [START_REF] Shackelford | Computing curricula 2005: The overview report[END_REF] sketches out the conceptual territory occupied by each of the five computing disciplines: Computer Engineering, Computer Science, Software Engineering, Information Technology and Information Systems, as illustrated by Figure 2. In particular, they claim that "Information systems specialists focus on integrating information technology solutions and business processes, to meet the information needs of businesses and other enterprises, enabling them to achieve their objectives in an effective, efficient way".

Figure 2 Positioning of the information system discipline in all dimensions of computer domain [START_REF] Shackelford | Computing curricula 2005: The overview report[END_REF] Among all existing information systems, six particular types of EIS exist and are considered in our research work [START_REF] Romero | Enterprise information systems state of the art: past, present and future trends[END_REF]: Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Manufacturing Execution Systems (MES), Customer Relationship Management (CRM), Product Lifecycle Management (PLM) and Business Intelligence (BI).

Information system framework analysis

Some information system agility framework analysis found in the literature propose a practical approach to accompany entreprises in measuring and achieving agility. [START_REF] Imache | An enterprise information system agility assessment model[END_REF] consider different dimensions of the information system in order to differentiate the levels of analysis. The agility levels go through Business Processes, Organizational elements of the enterprise, Information, Resources that include people, Information Technology, Infrastructure, and finally Environment which deals with external factors of the enterprise. The goal is to evaluate the agility of an information system through a maturity grid. The result of the evaluation is the basis of recommendations to improve the agility of the information system.

In [START_REF] Benaben | Supporting interoperability of collaborative networks through engineering of a service-based Mediation Information System (MISE 2.0)[END_REF], a mediation information system is proposed to provide a service-based platform, dedicated to initiating and supporting the interoperability of collaborative situations among potential partners. The third level of the approach tackles the system agility, i.e. the management of evolutions and changes required for the system, with a focus on the automated exploitation of incoming data to update situational models and the detection of an adaptation necessity and the characterisation of this necessity for adaptation. [START_REF] Rdiouat | Measuring and improving information systems agility through the balanced scorecard approach[END_REF] propose to evaluate the information system agility through business contribution, user orientation, operation excellence and innovation, and competitiveness, in a framework leveraging the balanced-scorecard approach. The agility is measured according to agility key success factors using agility evaluation criteria.

These propositions expose a clear understanding on how to measure agility for the dimensions under consideration. We claim that to go a step further, lowest technical levels i.e. Services and Software need to be explored as well, in order to enrich the panel.

IS alignment approaches

Most of the literature that tackles the problem of evolution of an EIS according to business needs, are dealing with the information system alignment problem. The design of the information system must be in accordance with the strategy and the supported business processes [START_REF] Goepp | Special issue: Enterprise engineering and alignment[END_REF].

According to [START_REF] Tarafdar | IT-business alignment: A two-level analysis[END_REF], there are three levels of alignment: strategic, tactical and project. Alignment at strategic level ensures that information technology plans are in accordance with business plans. It also ensures that the organisation plans to implement an information system supporting its strategic goals. The strategic alignment literature generally deals with this level. Alignment at the operational level is required for ensuring that the information system is successfully implemented, maintained and used, and in turn delivers the targeted business benefits. The project level is defined as the degree to which an information system project's deliverables match the organisation's information technology strategy and the project's objectives [START_REF] Chan | IT alignment: what have we learned[END_REF].

Three kinds of approaches are found in the literature regarding information system (re-)engineering: alignment building, alignment evaluation and alignment maintaining.

Alignment building approaches deal with the working out of alignment during information system design, that is to say agile information system design that are intrinsically aligned. Approaches like [START_REF] Solaimani | A framework for the alignment of business model and business processes: A generic model for trans-sector innovation[END_REF][START_REF] Fritscher | A visual approach to business it alignment between business model and enterprise architecture[END_REF] formalize the models to be used to work out alignment, but they do not provide means to make evolve the alignment built.

Alignment measuring approaches like [START_REF] Ahuja | Strategic alignment maturity model (SAMM) in a cascading balanced scorecard (BSC) environment: Utilization and challenges[END_REF] enable to measure the fit between the information system and the supported business processes through evaluation of the related model elements. If the proposed metrics enable to assess the origin and kind of un-alignment, they do not cover all alignment levels, being mostly focused on tactical alignment.

Alignment maintaining approaches deal either with co-evolution model [START_REF] Vessey | The dynamics of sustainable IS alignment: The case for IS adaptivity[END_REF]. Most of these approaches only consider a "sticky" alignment because alignment is systematically rebuilt.

For all these reasons, the evolution of the alignment along time is a complex question that is ranked recurrently as one of the major preoccupations of managers, and few research works are facing successfully this issue.

As a conclusion, even if EIS are of prior importance for the global performance of an organisation, their intrinsic complex nature, being at the interfaces of many scientific fields (computer science, organisation, etc.), explains that controlling their evolution in a very uncertain environment remains an open question.

To overcome this difficulty, we propose to focus on agility performance of an EIS in order to provide a framework for helping decision maker in the improvement choices. The first step is to define what EIS agility can be and how it can be measured.

Agility definition and measurement

Agility follows a progressive and pragmatic philosophy. According to the Chambers Dictionary, the word agile is derived from the Latin "agere" that means "to act" or "whose movements are flexible and fast". The etymology of "Agile" term defines quick and slight movement.

Agility can then be addressed regarding different business competence areas, such as business agility, enterprise agility, agile organization, agile workforce, information technology agility, agile manufacturing, agile supply chains, agile software development, etc. Notably, the concept of agility is currently not exactly or uniformly defined in all those fields. Although the general objective should be the same, i.e. sustainable profitable business, the different disciplines address it from different points of view and at different levels. The disciplines also partially overlap.

To measure and assess agility, we use metrics already defined in the literature. The terms metric and performance indicator are widely used in very different areas like mathematics, management, trade links, etc.

In this research work, a metric is characterised by a semantics, related to the physical or virtual phenomena to measure, a zero value and a value scale [START_REF] Böhme | On metrics and measurements[END_REF]. A performance indicator is based on a metric or a set of metrics focusing on a critical aspect of the global organisation performance.

Nevertheless, very few research works in the literature focus on information system agility and its measure. Since an enterprise information system is at the interface of computer science and production organisation, we focus on these two fields.

Agile manufacturing

In the context of production management, [START_REF] Kidd | Agile Manufacturing. Forging New Frontiers[END_REF] first defines agility as a timely and proactive adaptation of business elements to unexpected changes that cannot be anticipated. According to [START_REF] Gunasekaran | Agile manufacturing: Enablers and an implementation framework[END_REF], Agile Manufacturing (AM) is the ability of surviving and prospering in a competitive environment of continuous and unpredictable change by reacting quickly and effectively to changing markets, driven by customer-defined products and services.

Since then, a number of literature reviews with different focuses have been realised on agile manufacturing [START_REF] Sangari | Developing a practical evaluation framework for identifying critical factors to achieve supply chain agility[END_REF][START_REF] Shaw | Supply chain agility: the influence of industry culture on asset capabilities within capital intensive industries[END_REF][START_REF] Chan | The effects of strategic and manufacturing flexibilities and supply chain agility on firm performance in the fashion industry[END_REF][START_REF] Fayezi | Understanding and Development of Supply Chain Agility and Flexibility: A Structured Literature Review[END_REF]. One can cite [START_REF] Charles | A Model to Define and Assess the Agility of Supply Chains: Building on Humanitarian Experience[END_REF], in which agility is defined as the ability of a system to be flexible, in a reactive and efficient manner. There are three main aspects to this vision: the system must be able to change its structure (flexibility) according to a relevant analysis of the situation and its requirements (efficiency) and this should be done in a hurry (reactiveness).

The most formal definition of agility, used in military logistics, allows us to better understand the different facets of agility in a synergistic combination of the following dimensions [START_REF] Alberts | Power to the edge: Command[END_REF]:

1. Robustness: the skill to maintain the efficiency through all the tasks, situations and conditions.

2. Resilience: the skill to improve or adjust itself against disruptive events from the environment.

3. Reactivity: the skill to react temporally to an environment change.

4. Flexibility: the skill to use a various set of means for success and the capacity to switch from one to other.

5. Innovation: the skill to generate novelty and the skill to make the "old" by using new means.

6. Adaptation: the skill to change business processes and the organisation.

In this context, some authors have proposed metrics to characterise different facets of agility [START_REF] Shaarabh | A review on measurement of agility[END_REF][START_REF] Routroy | Measurement of manufacturing agility: a case study[END_REF][START_REF] Sangari | Developing a practical evaluation framework for identifying critical factors to achieve supply chain agility[END_REF][START_REF] Lee | A Classification Scheme for Smart Manufacturing Systems' Performance Metrics[END_REF]. Due to the complexity of the concept, they all propose a set of metrics that are related to physical performances of the manufacturing system or the supply chain. Some of them can be automatically calculated from data coming from ERP, CRM, etc. but do not tackle the performance of the information system support to the physical one.

Despite the differences between all these definitions, we can conclude that they all agreed on the fact that agility is an intrinsic property of the system, based on flexibility and adaptation to the unpredictability of the environment.

Agility in software engineering

When it comes to software engineering, agility is an umbrella term for a set of methods and practices on software development processes, based on the values and principles expressed in the Agile Manifesto 1 . Solutions evolve using an empirical approach through collaboration between self-organizing and cross-functional teams utilizing the appropriate practices according to the context.

Agile approaches in software engineering are created to anticipate unpredictable events that can occur during all the project phases, concerning cost, time, quality and customer needs. These four criteria are addressed in agile approaches.

Among the existing agile methods and according to the 9th Annual state of agile survey (VersionOne, 2015), Scrum [START_REF] Schwaber | Agile project management with Scrum[END_REF] takes over. It is used by 56% of the companies, while other methods are behind with little use. Scrum is a development team management methodology. It provides a set of practices based on sprints to regularize teamwork in software development, in order to continue to meet the objectives in line with customer requirements.

Scrum is an incremental and iterative approach. The main objective is that when the project evolves, the customer needs can change. It is particularly true in software engineering due to the strong evolution of technologies. In practice, it requires a strong involvement of the customer in the project. Regularly, every two to four weeks, the customer is invited to validate the status of the work, and each functionality validated is delivered.

This approach has multiple advantages:

• it avoids the tunnel effect, by having the validation of the customer at real time.

• it allows the customer to change the requirements as soon as possible, and reorder the importance of functionalities.

• it allows to reduce the risk of time increase, by updating the planning regularly.

In this context, a software metric is a compilation of measurements from the technical or functional properties of the software [START_REF] Mordal-Manet | Software quality metrics aggregation in industry[END_REF].

In the field of software development, the use of standardization is the most popular method for ensuring the agility of the information system. It allows portability of applications, by giving the ability to move between different platforms in a hybrid frame without the need for a full or partial re-engineering. To implement this approach, it is necessary to set adaptability metrics, especially with the arrival of cloud architecture [START_REF] Armbrust | A view of cloud computing[END_REF] which facilitates the sharing of platform changes. But the concern remains in the interpretation of these standards by the run-time engine.

It is possible to classify the software metrics in three categories: application maintenance, application quality and respect for development process. [START_REF] Sherehiy | A review of enterprise agility: Concepts, frameworks, and attributes[END_REF] claim that several different approaches dedicated to agility measurement can be found in the literature, from integrated agility index to AHP methodology.

Some authors propose metrics related to the software part of the project. Beck (2000) concentrate on coding metrics and a set of unit testing, while profiling is addressed in [START_REF] Summers | System and method for profiling code on symmetric multiprocessor architectures[END_REF]. [START_REF] Kupiainen | Using metrics in Agile and Lean Software Development -A systematic literature review of industrial studies[END_REF] propose a literature review on metrics in agile software development in order to identify the most influential ones and what are the effects of using metrics during software development. [START_REF] Lenhard | Portability of Process-Aware and Service-Oriented Software: Evidence and Metrics[END_REF] propose a methodology which validates and practically evaluates a framework for measuring portability by measuring adaptability . The limit of that kind of approaches is that it merely treats problems related just to the software layer. However, for a higher vision of information systems, it does not offer the possibility to extend it.

Definition: Agility in information system

Table 1 gives some definitions of agility that are partly applied on information systems. These definitions either focus on business processes agility or on information system development agility. A limitation is their theoretical and abstract aspect, preventing them to be efficiently deployed as a support in improvement projects. These proposed definitions of agility are not complete but rather complementary. Indeed, the information system is composed of software layers and high level layers related to the business entity.

Based on these definitions, we can identify two visions of information system agility as shown in Figure 3. The first vision is the agility based on the intrinsic capability of the information system to respond to the business. It is the ability of the information system to respond to the need of the business even if there are changes in the environment.

The second vision is the capability of the information system to evolve in order to integrate new needs and new technologies to stay competitive. This agility depends on the involvement of the project team. We name it the agility in the process of improvement.

Including the two visions, we propose the following definition for information system agility: "An Information System is agile from the moment it appropriates a set of processes and strategies that involves incrementally the user, in order to acquire the ability to adapt flexibly to the business changes and continue to achieve goals, by Author Definition [START_REF] Dove | Fundamental principles for agile systems engineering[END_REF] "Agile systems are concerned with response ability -for both reactive and proactive response needs and opportunities -when these are unpredictable, uncertain, and likely to change." [START_REF] Rouse | Agile information systems for agile decision making[END_REF] "Agile information systems should provide sufficient flexibility to respond to business disruptions, opportunities, threats, or unforeseen events" Conboy ( 2009)

"Continual desire for a method of the Information System Department (ISD) to quickly create or intrinsically change, pro-actively or re-actively embrace change and learn the change while contributing to the value perceived by the customer (economy, quality and simplicity) through its collective components and relationships with the environment." [START_REF] Maurer | Measuring information systems agility: Construct definition and scale development[END_REF] "IS agility as the ability of IT artefacts, of information stored within those artefacts, and of the underlying processes that support and maintain the artefacts and information to quickly adapt to changing business needs." IS agility has three main dimensions (technical infrastructure agility, IS process agility and human characteristics), each one of them being broken down into 3-4 first-order dimensions. [START_REF] Evelson | Trends 2011 and beyond: Business intelligence. agility will shape business intelligence for the next decade[END_REF] "Approach that combines processes, methodologies, organizational structure, tools and technologies that enables strategic decision-makers to be tactical and operational for more flexibility and more responsive to the rapid pace of change in the business and regulatory requirements" 2016) "agility cycle" (Sense -Diagnose -Select -Execute) as a means to illustrate that agility is not a one-off effort, rather, it is continuous readiness for change. We also introduce the concept of "synchronicity" to highlight the time dimension of agility. decreasing response time, despite the pressure and the turbulent in the unpredictable environment."

According to this definition, we can define how to measure information system agility taking into account all the system dimensions.

Metrics on the process of information system improvement

Several research works have propose framework to globally evaluate a performance of an EIS as support of improvement discussion. One can cite for instance [START_REF] Cho | Metrics and measurement of trustworthy systems[END_REF] in which agility measurement is one metrics used by to evaluate the trustworthiness of a

Information System

Information System development and improvement

Agility intrinsic to information system

Agility in the process of information system improvement 2016) propose a set of measure to evaluate the information system success inside an organisation. [START_REF] Knabke | Understanding Information System Agility -The Example of Business Intelligence[END_REF] analyse agility for Business Intelligence systems. Anyway these frameworks only consider the global system and it will be very difficult to define an EIS improvement path with these high-level metrics only.

Tseng and Lin (2011) present a conceptual model of an agile enterprise representing the relationship between agility drivers, capabilities and providers. Based on this model, an agility development method for dealing with the interface and alignment between these three pillars is proposed. It is implemented with the Quality Function Deployment relationship matrix and fuzzy logic in order to cope with the uncertainty and the complexity of imprecise or vague definition of agile attributes and matrix relationships. In [START_REF] Couto | Can IS/IT governance contribute for business agility?[END_REF], a conceptual model to analyze the interdependence between the governance of the information system and enterprise agility is proposed. The model is based on the identification of critical success factors enabling agility and on the identification of the information system governance practices that contribute to reach those factors.

Another approach is the combination between management methods and development methodologies as in [START_REF] Erickson | Agile modeling, agile software development, and extreme programming: The state of research[END_REF], where the authors deal with metrics related to Extreme Programming in terms of agile modelling [START_REF] Ambler | Agile modeling: effective practices for extreme programming and the unified process[END_REF]. The model leverages a set of existing metrics in different contexts in order to bring the information system in its entirety from the software layer to the high-level layer to a level of agility.

To conclude, a notion of agility that combines intrinsic and extrinsic qualities of an information system can be proposed, with a multi-layered definition.

The literature provides a set of metrics of agility assessment but they are not sufficient. The idea is to use them according to each context to propose a model based on the existing metrics but by projecting them on a new structure adapted to the environment. The analysis of existing references shows that there are few links between the metrics of software and business process in current approaches. Moreover we can deduce from the literature that not one metric will be sufficient to measure all the dimensions of IS agility and we so need a framework to structure the selected and developed metrics.

Agility metrics framework

We introduce an analysis model to give a concrete vision of agility reached by an information system. In the literature, we can mention the approach developed by [START_REF] Imache | An enterprise information system agility assessment model[END_REF] that is line with ours. The authors consider different dimensions of the information system in order to differentiate levels of analysis. The agility levels go through Business Processes, Organizational elements of the enterprise, Information stored and manipulated, Resources that include people, Information technology, Infrastructure, and finally Environment which deals with external factors of the enterprise.

The proposed model treats and describes special metrics dedicated to evaluate agility in the information system. It is inspired by the definition of agility cited in Section 2. To find answers regarding the agility of information systems, we propose a model that goes around on those aspects. Consequently, we choose a square plan which allows to visualize the objectives of the metrics. The projection on the plan allows external analysis to observe the relationship with the environment, but also internally observing correlation between these metrics.

This is an analysis model comprising metrics for evaluating agility according to 2dimensional. The choice of two dimensions come to facilitate the judgement through the metric, because a relationship between two strangers is more relevant than several dimensions at once. system is able to adapt to the environment changes. Hence, these metrics lead us to discover the steps that must be implemented for the continuity of productivity. It shows how to reduce response time and keeping an eye on customer expectations in order to avoid the "tunnel effect".

The first dimension of the framework is related to the levels of analysis. The idea is to differentiate the software part from the business part, in order to locate the exact source of agility problems. The second dimension deals with metrics depending on the situation we want to achieve.

Thus, evaluating the agility of an information system will be through the cross between the two dimensions, depending on the situation we want to evaluate.

Levels definition

We propose a 4-scales for the levels (figure 4):

• Software (SW): The software level is controlled by a set of development rules. This level represents the evaluation of the software development process and software source code quality. The source code quality can be measured based on ISO 25010 (ISO 25010, 2011) that provides a model to measure the quality of the software.

• Services (SV): For this level, a service is considered as a functionality in the work-flow of the information system. An agile system should be developed with service oriented architecture (SOA) that contains a set of services that can be used independently. But it is not real in all information system. So, this level represents the evaluation of the functionality of an information system to answer to the need of users.

• Business Process (BP): This level represents all possible trade flows and business work-flows. This level represents the association of all services needed to complete a business task, and how it can be changed depending on the environment.

• Information System (IS): This level includes the entire set of business management tools for information system. It represents the whole system and its capability to change a part of it without breaking other parts.

Information system

Business process

Service

Software

Figure 4 The four levels to measure the agility of an information system

Dimensions of agility

From our definition of information system agility, we propose to decompose the framework into five dimensions. These dimensions are listed in the first line of Table 2: • Appropriation Process: It represents the flexibility desired in the system to monitor changes in the environment. This translates its inner ability to adapt appropriate behaviour in new situations without seeing the need to introduce outside interventions.

• Adaptation to Changes: It presents all the operations to be set up by the company using its resources to adapt to external changes.

• Response Time reduction: For being agile, the system has to successfully reduce the response time. Hence, it must decrease the customer wait time to access services.

• Objectives achievement continuation: The strong feature of agility is the ability to continuously achieve the objectives despite environmental perturbations.

• Customer involvement: The agile method is a user-centred approach and the customer involvement should be taken into account throughout the product lifecycle.

Metrics classification methodology

A proposition of metrics insertion in the framework is presented in Table 2. For each level and each dimension, we defined a category of metrics. In this section we will detailed theses categories and give some examples of metrics to help to implement the model.

Metric

Appropriation process

Adaptation to changes

Software Level

Appropriation process

• Use flexibility: It is the capability for a developer to identify and use the API (Application Programming interface) of the software source code. It means that the API methods are (i) easily accessible, (ii) well documented and (iii) useful. (i) Easily accessible means that the developer can find the APIs and differentiate them from the methods of the software-core. Depending on the language used, it can be identified by a tag, or by a type of methods. A public method is accessible by external programs. The accessibility is facilitated if a standardization of the structure is applied. (ii) Well documented is that the documentation of the API is enough to understand it and to use it. A simple metrics to measure the documentation of the API is to measure the number of lines of comments for the API. (iii) Useful is the ability to provide a benefit using this API. A possible measure of the usefulness is to analyse the number of caller of an API method. A lots of callers means that the API is useful. A refinement can be to differentiate the caller inside the software core (they use the method as a core method) and outside where they use the API as an interface as we expect to measure.

• Parametrization flexibility: It is the ability for a software to be parametrized. In Object Oriented Systems, we named it extendibility. It is the possibility of a class to be a specification of a more general class. We expect that a method can evolve independently of of the type of data sent by the caller. Metrics here are the number of generic function or the number of virtual method.

Adapting to change

• Integration: it assures that the software application is enough stable to be proposed to the final user. It implies that the integration process is well known and well controlled.

It can be measured by multiple ways: the integration frequency, the number of manual operation to integrate a change, the existence of a rollback process in case of problem during the integration, the number of integration tests (ISO 15745, 2003).

• Portability: This is the ability of a software to be installed and used on multiple environments, or hybrid environments. It can be measured by the number of operation to make the system portable. Depending on the language used to develop the source code, the library used to access external resources, and the structure of the relation between the source code and the library. For example, using languages based on virtual machine, such as Java or Smalltalk, is more platform independent than a C-like source code that is compiled for a specific type of processor. Moreover, the library used by the software application is a constraint to portability, even in case of VM-based languages. The list of the depended library is essential to determine the portability [START_REF] Sherehiy | A review of enterprise agility: Concepts, frameworks, and attributes[END_REF].

• Modularization: It is the capability to integrate new changes in a part of the software without high impact in the rest of the source code. It can be measured by multiple metrics, for example by computing the cohesion and coupling between software artefacts or computing the presence of god classes [START_REF] Sherehiy | A review of enterprise agility: Concepts, frameworks, and attributes[END_REF].

Response Time Reduction

• Refactoring: It is the capability to make the code cleaner and less complex. It improves the extensibility, and makes it reusable by other parts of the source code. In software development, making a refactoring means that a part of source code will be changed without changing its behaviour, it improves the non-functional aspects of the source code. It is done using multiple refactoring technics [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF].

• Code optimization: It is the practice of reducing the occupied space by data or the program itself. The code space can be reduced using different design patterns, and detecting dead code. The practice of extreme Programming (XP) allows developers team to improve this criterion [START_REF] Beck | Test-driven development: by example[END_REF] • Code profiling: the goal of code profiling is to measure, analyse and reduce the execution time of a function or a method. It is calculated based on source code execution time [START_REF] Summers | System and method for profiling code on symmetric multiprocessor architectures[END_REF].

Continue to Achieve the Objectives

• Unit Test: It is the tests that validates each method or function. It can be measured by the ratio of passed tests on non-passed tests [START_REF] Beck | Test-driven development: by example[END_REF].

• Coverage Test: it is the ratio of source code covered by tests. It measures the quality of testing. It is measured by analysing the source code tested when running all tests [START_REF] Beck | Test-driven development: by example[END_REF].

• Scalability: it is the capability to handle a growing amount of work. It can be measured by testing the system in extreme situation. It defines the limit of a system. For example, the scalability can be defined for a number of users connected to the application.

Customer Involvement

• Meeting frequency: it is the frequency of meetings between the client and the project team, e.g. the software engineers. The goal of these meetings is the definition of new features or any changes of existing features of the software. It can be measured by the frequency of meetings dedicated to the definition of functionality between users and project team [START_REF] Schwaber | Agile project management with Scrum[END_REF].

• Validation of functionalities: It is the number of functionalities that have been validated by the user. It mean that the user ask for the feature and a test has been written by the project team. It can be measured by two metrics: one that measures the number of functionalities validated by the users before the implementation. It measure the need of the functionality, one that measures the test of the functionality, that validates the use of the functionality [START_REF] Schwaber | Agile project management with Scrum[END_REF].

• Usage of functionalities: A functionality can be requested by users and not be really used. There are multiple reasons: it can be because the need has changed, the HMI is not easy to use, the need was not expressed clearly, and so on. This indicator can be measured by tracking the number of call of a function during a defined period.

Service Level

Appropriation process

• Use Flexibility: it reflects the possibility of the use of the same services on different contexts. It can be measured by calculating the number of contexts of a service.

• Parametrisation flexibility: It expresses the variability of parameters of a service. For a same service, it measures the capability to achieve several scenarios for various uses.

The measure can be a variability rate based on the ratio of configurable parameters on the fixed parameters.

Adapting to change

• Extensibility: It is the possibility of adding new parameters on a service. It can be computed by measuring the number of new settings that can be added.

• Loose coupling: The correlation between services should be minimal. If a service depends on another one, it implies that the service can become unstable if the other undergoes disturbances such as modification, unavailability. This indicator can be measured by computing the number of depended services [START_REF] Channabasavaiah | Migrating to a service-oriented architecture[END_REF].

• Re-composition: It is the possibility of creating a new service composing multiple existing services. It can be computed by measuring the number of services using the focused service.

Response Time Reduction

• Service performance: It defines the access time to the service for users. The access time is evaluated by computing the execution of a request from the sending of the request to the receipt of the response [START_REF] Menascé | Response-time analysis of composite web services[END_REF].

• Profiling Service: It is the capability of analysing the execution time of a service. It means that developers team is able to control and to decrease the response time to ensure to be in phase with the business. It is measured by knowing if there is a profiling system for the service. The answer is yes or no [START_REF] Menascé | Response-time analysis of composite web services[END_REF].

Continue to Achieve the Objectives

• Functional testing: It is the number of functionalities that have been requested by the user and that has a test to ensure the validity of the behaviour regarding the business.

It can be measured by the ratio of passed functional tests on non-passed tests.

• Scalability: it is the capability to handle a growing amount of work. As at software level, it can be measured by testing the system in extreme situation. It defines the limit of a service. For example, the scalability can be defined for a number of users connected to the service.

Customer Involvement

• Meeting frequency: it is the frequency of meetings between the client and the project team, e.g. the software engineers. The goal of these meetings is the definition of new services or any changes of existing services of the application. It can be measured by the frequency of meetings dedicated to the definition of services [START_REF] Schwaber | Agile project management with Scrum[END_REF]).

• Transparency: The team must build a relationship of trust between the customer and the project team. The project team should show the project progress and provide frequently the finished services. The customer has to fix and respect the specifications already provided. It can be measured by the number of notifications sent by the client or the project team to the other part [START_REF] Schwaber | Agile project management with Scrum[END_REF].

Business process level

Appropriation Process

• Re-setup: Re-setup is the action of re-tuning some parameters of a business process.

The goal is to make a Business Process suitable for various applications in order to achieve several scenarios. The more a business process has the ability to be re-setup, the more it can be qualified as agile. We can evaluate this indicator by the ratio of the number of configurable parameters to the total number of parameters [START_REF] Ambler | Agile modeling: effective practices for extreme programming and the unified process[END_REF][START_REF] Raschke | Process-based view of agility: The value contribution of IT and the effects on process outcomes[END_REF].

• Process traceability: Traceability is the ability to trace the activities of the life of a business process. The goal is to utilize the knowledge captured and stored within traces.

From these traces, one may be able to generate workflows and to improve the process of chaining. Traced Experience Based Reasoning [START_REF] Mille | Trace-based reasoning modeling interaction traces for reasoning on experience[END_REF]) is a possible way for gauging the level of traceability [START_REF] Beck | Extreme programming explained: embrace change[END_REF][START_REF] Arteta | A measure of agility as the complexity of the enterprise system[END_REF].

Adapting to Change

• Gain evaluation: Regarding changes that may occur, one may be able to evaluate the gain and to keep it at the highest level. To do so, the assessment of the business drivers must be performed at the beginning of the project. The evaluation of the gain can be computed in two ways. The first one is the computation of the cost difference between incurred and planned resources. The second one is the quotation of the suppliers in terms of cost, delay and quality [START_REF] Ambler | Agile modeling: effective practices for extreme programming and the unified process[END_REF].

• Maintainability: Maintainability is the ability for components or applications to be maintained consistently and cost-effectively. This indicator is computed by various ratios, ratios between maintenance costs and the general performances of the process, ratios for maintenance policy and assets management, and ratios that express the availability of the process during maintenance operations [START_REF] Beck | Extreme programming explained: embrace change[END_REF].

• Reduce time to market: The Reduce time to market indicator is related to a product creation approach that proposes to reduce the risks and the impacts of failures by rapid iterations. It can be evaluated by various aspects of the DevObs paradigm like automation of the provision of the resource, continuous deployment [START_REF] Erickson | Agile modeling, agile software development, and extreme programming: The state of research[END_REF].

Response Time Reduction

• System performance: The performance of a system is linked to the workflow execution time. By calculating the time that consumes a workflow, one can get a measure of the system performance [START_REF] Cohen | New product development: The performance and time-to-market tradeoff[END_REF].

• Frequency: Frequency is related to the processing of the clients requests. It expresses the dynamics of the system. The evaluation can be performed by the calculation of the number of output files [START_REF] Couto | Can IS/IT governance contribute for business agility?[END_REF].

Continue to Achieve the Objectives

• Evaluation of Goals (TO-BE): The evaluation of the goals is related to an actual representation of the existing business processes (AS-IS), and the review of those existing processes regarding the planed objectives (TO-BE). In order to express the differences between AS-IS and TO-BE, one can evaluate the gap between them.

• Positive Operating: In order to keep or to reach positive operating, operating assessments must be organized within a company. A differential of the performance can be made to evaluate this indicator.

• Quality control: Quality control is the process allowing to review the quality of business processes. The results of the control enable a company to determine the level of a process efficiency, and to adapt its strategy. Measures of quality are the evolution of default rates and of associated costs, prevention costs, time for the treatment of the problems.

Customer Involvement

• Continuous Delivery: Continuous delivery relates to the ability during production or exploitation, to build, test, and release software faster and frequently. This indicator can be evaluated by the rate of iterations, the number of versions.

• Customer Support: Customer support consists in providing assistance to customers in case of trouble after product delivery. It can be evaluated by claim rate and reactivity rate [START_REF] Tseng | Enhancing enterprise agility by deploying agile drivers, capabilities and providers[END_REF][START_REF] Hepp | Semantic business process management:a vision towards using semantic web services for business process management[END_REF].

Information system level

When it comes to the information system level, a strong interaction between the user perception of the intrinsic capabilities, and his/her real ability to interact with the system exists. Moreover, this level is directly linked to the global business model of the organisation. As a consequence, some metrics are more conceptual, less easily implementable, and require measures outside of the system with consistent complementary tools [START_REF] Galliers | Strategizing for agility: Confronting information systems inflexibility in dynamic environments[END_REF][START_REF] Tseng | Enhancing enterprise agility by deploying agile drivers, capabilities and providers[END_REF][START_REF] Couto | Can IS/IT governance contribute for business agility?[END_REF][START_REF] Heikkilä | Business model metrics: an open repository[END_REF].

Appropriation process

• IS traceability: IS traceability is the capability of the system to track the origin of each piece of information and its evolution in the process. The goal is to ensure information consistency to all the customers. It can be evaluated, for example, by measuring the number of empty metadata, the number of information owner, by considering the various components of an Enterprise Resource Planning (ERP) system.

• Knowledge capitalization: Knowledge capitalization is the capability of an information system to easily store and retrieve knowledge and best practices. An associated measure can be the number or the rate of added, read, used or changed of such identified objects inside the information system.

• Anticipation: Anticipation describes the level of autonomy of the system and its ability to be reactive and to make decision. The system must be able to leverage tools related to data-mining and big data such as Extract-transform-load (ETL), OnLine Analytical Processing (OLAP). The aim is to improve the decision making process.

• Risk management: Risk management is the capability of the controlling system to identify potential dysfunctions, prevent them or define correction processes with consistent identification controls.

Adapting to change

• Capacity of Evolution: Capacity of Evolution is the capability of the system to successfully be modified according specifications requested by users. An example of measure is the number of successful change order on the total number of change requests.

• Added value prioritization: The prioritization of value-added solutions is the capability of the system to choose the modifications really needed by the user. It also reflects the rigidity of the system by counting the number of its non-usable tools or functionalities.

Response time reduction

• IS response time : The response time of an information system corresponds to the time that is necessary to satisfy a customer need. Let's mention the request/answer time.

The speed of improvement metrics [START_REF] Cohen | New product development: The performance and time-to-market tradeoff[END_REF] or the Time-to-recovery from the SCOR model [START_REF] Jung | Mapping Strategic Goals and Operational Performance Metrics for Smart Manufacturing Systems[END_REF] are good examples.

• Services availability: The availability of already existing services or new offered services is related to the delay for accessing them. It is a measure of the rate of people affected by the services proposed by an information system.

Continue to Achieve the Objectives

• Bug rates: Bugs have an impact on the ability of the system to continue to achieve its objectives. Measuring the number of bugs on the total number of users provides information about this ability.

• Customer satisfaction: Customers can express their feeling about the ability of the system to achieve its objectives. Customer feedback are directly retrieved for example by surveys or satisfaction questionnaires.

Customer Involvement

• IS training: System training sessions are of prime importance for the adoption of an information system by organisations. The number of proposed sessions, the number of followed sessions are possible measures to evaluate the ability of the system to be adopted.

• Customer feedback: Customer communication with the support team reflects its involvement. The quality and efficiency of this communication can be measured by the number of exchanged emails, the issue tracking system log.

• Acceptance of change: Both the customer and the provider are implied in the process of change acceptance. Acceptance of change depends on multiple factors: the type of change, the initiator of the change, the support for change and the delay of change.

Use of the framework

In this framework, we define the two dimensions that structure all metrics that can be applied to evaluate the agility of an EIS.

Nevertheless, according to the specific context of improvement project, none all of them are required in order to both define the initial situation and the vision. For instance, a SME, specialised in mechanical part production and which wants to change or update its ERP to improve its production efficiency, will focus on the business and information systems levels, since it may not have internal competencies in order to modify the software.

On the contrary, a software developer will need to implement on each level, each dimension one or multiple metrics. Based on the defined metrics, one can identify the lacks of his/her system and so improve it.

We provide the Table 2 as an example of the use of the framework. It is important to consider that each system and each context is different. Each situation has its own goal. These goals have to be transform in metrics and in threshold values. These metrics and threshold are used in the framework.

Conclusion and Perspectives

Enterprise Information Systems have a strong impact on the global performance of an organisation and the difficulties to make them evolve at the same pace than the organisation strategy are important sources of wastes. To tackle this research gap, we propose to integrate agility as a key characteristic of an EIS, in order to measure, control and improve this performance indicator.

In our approach, we do not adopt a bottom-up approach, which is classical in computer science (i.e. from the source code to the process), but a top-down approach. In fact, the requirements are derived from the strategy and the business processes. The EIS has to evolve to be aligned with their evolution in an uncertain context.

For this end, we first propose an holistic definition of the agility concept applied to EIS, combining both intrinsic and extrinsic capabilities of the system and its dynamics. This definition mixes the two main domains that interact in an EIS, i.e. computer science and agile manufacturing.

On the basis of this definition, we propose a complete framework that structures all the possible metrics dedicated to the agility measurement, according to the four levels of an EIS (from software to information systems) and the five facets of the agility definition. By construction, according to the organisation maturity and the context of evolution, each level can be tackled independently and the different metrics can or not be combined between levels.

Today, the framework is not exhaustive in the sense that all existing or necessary metrics have not been included inside. A first ongoing research work is to face up this challenge. In parallel, an implementation of the framework has begun and is currently partially tested. Nevertheless, a complete implementation and validation will be realised in future works.

  ..] Agile has been described as the response of a company to the most competitive and uncertain environment. The uncertainty [...] manifests itself in three forms: Supply uncertainty [...] uncertain demand [...] and operational uncertainty" Benaben et al. (2014) " agility = (detection + adaptation) × (reactiveness + ef f iciency) " Yang et al. (

Figure 3

 3 Figure 3 Two visions of metrics for Information System Agility

Table 1

 1 Some definitions for agility in the literature.

Table 2

 2 Proposition of metrics insertion in the framework for IS agility measurement.

	Response	Objectives	Customer in-
	time reduc-	achievement	volvement
	tion	continuation


Christophe Dumora
email: christophe.dumora@u-bordeaux.fr

David Auber

Jérémie Bigot

Vincent Couallier

Cyril Leclerc

DATA ORIENTED ALGORITHM FOR REAL-TIME ESTIMATION OF FLOW RATES AND FLOW DIRECTIONS IN A WATER DISTRIBUTION NETWORK

Keywords: Graph theory, maximum flow problem, data driven, sensors, Internet of Things, water distribution network

The aim of this paper is to present how data collected from a water distribution network (WDN) can be used to reconstruct flow rate and flow direction all over the network to enhance knowledge and detection of unforeseen events. The methodological approach consists in modeling the WDN and all available sensor data related to the management of such a network in the form of a flow network graph , with a set of nodes, a set of edges whose elements are ordered pairs of distinct nodes, a source node, a sink node and a capacity function on edges. Our objective is to reconstruct a real valued function on all the edges from partial observations on a small number of nodes . This reconstruction method consists in a data-driven Ford-Fulkerson maximum-flow problem in a multisource, multi-sink context using a constrained bidirectional breadth-first search based on Edmonds-Karp method. The innovative approach is its application in the context of smart cities to operate from sensor data, structural data from geographical information system (GIS) and consumption estimates.

INTRODUCTION

As reported by the World Health Organization, the urbanization rate (UR) in 2014 accounted 54% of the global population, up from 34% in 1960, and continues to grow. This UR is expected to be slightly above 60% in 2030 (United Nations, 2007). The planet today counts 3.3 billion city dweller, which is four and a half times more than in 1950. By 2030, the urban population is expected to reach 5 billion; there would be as many city dwellers in the world as inhabitants on Earth in 1987 [START_REF] Veron | Population & Sociétés -La moitié de la population mondiale vit en ville [Population & Societies -Half of the world's population lives in cities[END_REF]. In this context, the concept of smart city has recently been introduced to emphasize the importance of information and communication technologies (ICT). As cities become more attractive and welcoming, it is necessary to be able to understand and master the complex interactions between technological and service delivery systems [START_REF] Caragliu | Smart Cities in Europe[END_REF]. The analysis of data collected from sensors and their connectivity offer the possibility to tackle these novel issues. Distributing water that complies with sanitary requirements while providing an irreproachable taste is one of the fundamental services offered by a city to his citizens.

A smart water distribution network (WDN) must ensure the supply of safe drinking water from its extraction to different raw water sources, to the taps of consumers, while controlling the impact on both hydraulic and energetic resources. This task is based on the good management of hydraulic parameters (such as flow rate or operating pressure), on the control of water quality through treatment by purification (such as chlorination), but also by controlling water demand. For these reasons, WDN are instrumented with sensors. Positioning sensors on the production plants, on specific point of the WDN, or closer to the consumer make it possible to monitor and to control key parameters related to water quality (e.g. chlorine, pH, temperature) or the water demand (e.g. consumption). However, just as cities are expanding, WDN are also growing. WDN are increasingly meshed to ensure better security of supply. This looped pipe configuration greatly complicates the hydraulic and increase the risk of stagnation which represent a critic situation that must be avoid prevent water pollution (Obrodovic et al., 1998;Manual of Water Supply Practices, 2005).

The information provided by the sensors therefore leaves shadow areas in which it is difficult to control all the phenomenon taking place on a small spatial and temporal mesh.

One of the main challenges for the control and management of WDN is to be able to estimate the key parameters at any point in the network to remove these shadows areas.

The contribution lies in the methodological approach that consists in modeling a WDN and all available sensor data related to the management of such a network in the form of a network graph . The graph structure use a set nodes , edges and properties to represent and store data. This design allows simple and fast retrieval of complex hierarchical structures that are habitually difficult to model when data are heterogeneous. Our objective is to reconstruct a vector of numerical characteristics on all edges from partial observations on a small number of nodes . This reconstruction method consists in a data-driven maximum-flow algorithm in a multi-source, multi-sinks context. We experimented the method to infer sensors data throughout the Bordeaux Metropolis's WDN in France. With more than 3000 km of pipes this network delivers an average of 170 000 m 3 of water per day for more than 700 000 consumers. The paper is organized as follows. First, we describe challenges related to the management of WDN in the context of smart cities. Second, we present the data generated by the operation of a WDN required to build a flow network. We then describe a constrained Ford-Fulkerson method to estimate flow direction and flow rate inside a WDN. We conclude by a discussion about the future work that will be done to enhance the methodology and results.

SMART WATER CHALLENGES

Most of the time the small number of sensors do not allow to obtain sufficient information at every point of the network. Hydraulic models are therefore used to provide complete information on the hydraulic operation of the network (travel times, flow rates, etc.). Nevertheless, these models, although accurate, become more and more complex to solve. They require the use of average consumption profiles and typical configurations (peak days, winter, summer, etc.). This makes them become less adapted to determine, in real time, the state of the network. Estimating the hydraulic condition of the WDN on every point and time meets many challenges. The United Nations Organization estimated that, by 2025, two-thirds of the world's population could live in water stress conditions. The increasing world's population, climate changes, growth in agricultural production and access to drinking water play a significant role in the increased demand. Furthermore, even if in the last few years, the consumer tendency declines, the water demand continues to increase. Future water shortages will require increased efficiency in the treatment and transmission of water. For example, real time flow direction knowledge, would allow us to visualize the water origins at any specific point and time in a WDN. In this way, we could precisely know the path traveled by the water and track all events or interventions that could have an impact on its quality. This information obtained in real time, could play a key role in improving the management of the WDN, including:

 water shortage risk identification  water extraction optimization  pollution impact estimation  real time water quality monitoring  enhanced leaks identification  risk areas prediction (such as red water)  anomaly detection  etc. Thus, the WDN environment must be considered as a whole to get a smarter water management but also more resilience in continuity and quality supply. The interactions between ICTS (Information and Communication Technologies) and WDN structural data need to be further considered jointly. The way we chose to consider this interconnectivity and interdependence associated to the WDN is as a graph network.

GRAPH STRUCTURE

Many data initially disconnected from each other can be regrouped and linked together on the WDN. As shown on Figure 1 these data are initially regrouped by theme. This can range from water quality data (e.g. punctual or automatic measure of quality parameters, quality consumer complaint), to field intervention data (e.g. renewal, leak repair, valve actuation), through hydraulics information (e.g. volume delivered to the network, hydraulic simulations, consumed volumes). This set of heterogeneous data, because of their formats, uses and locations, can nevertheless be interconnected to each other at all levels thanks to the graph network. It is important to consider all these data, their interconnectedness and their interdependences to be able to understand the phenomenon that can disrupt the functioning of the network. We propose a more general data structure which is the network graph model. This structure well studied in the field of graph theory, is adapted to intensive calculation and data visualization.

In this part we will focus on two types of information attached to the nodes and edges of the graph, to build a flow network on which we want to apply a flow reconstruction method. 3.1) the structural data which represent the skeleton of the WDN and provide the nodes, edges objects, 3.2) the sensors data which concern the monitoring of all measures related to the flow. We present in section 3.3 how we build a flow network according to the data collected to perform the maximum flow problem.

Structural Data

They represent each of the structural objects of the WDN (e.g. water production plant, pipes, connectors, valves, sensors). All these objects are geo-referenced and described by characteristics such as pipe length, pipes diameter, state of valves etc. These data represent the skeleton of the network. Beyond representing the set of structural data, they have the central role of providing a structure on which all data related to the WDN can be linked.

We now consider the WDN as a graph network , where is the set of nodes and the set of edges. Each node represents a structural object of the WDN. Each edge depicts physical link between the nodes in our case edges represent pipes. If the nodes and are linked by a pipe we create and edge , of length and internal diameter . The structural properties of pipes allow us to determine a theoretical maximum possible flow for each pipe depending on their diameters and a maximum flow speed fixed. We define as the capacity of the pipe representing the maximum possible flow in for the edge .

(1)

With the surface and the maximum flow speed of the pipe .

Sensors

In order to monitor the key parameters related to the management of the WDN, sensors are installed at different strategic points. These sensors provide local information about water that cross through the network on small time step. In the context of building a flow network the sensors in which we will focused are counting devices providing flow direction and flow rate. These flows information are not fixed. They can vary a lot inside the same pipe. Flow direction is not necessary obvious to determine and can reverse depending on the period and the total volume consumed.

These sensors are crucial to obtain real information of the flow rates and flow directions. They measure the amount of water passing through a specific point of the network in , with a time-frequency around 1 measure per 15 minutes. We consider in this paper two types of sensors nodes:

 Type a: Those providing inflow or outflow information. Divided into two categories, sources nodes and sinks nodes , depending if it measures inflow or outflow. The sources nodes are mainly located on reservoirs or at the water production plants outputs. They measure the amount of water delivered on the network. The sinks ones can be located on interconnections with other townships networks to provide water in case of shortage or on water tanks when they are filled by water production plant, but especially at consumers level, thanks to Automatic Meter Reading (AMR), counting on an infra-day period the quantities of water consumed. Inflow and outflow information are crucial to be able to reconstruct flow inside a network. It provides quantity and position information of water entering or leaving the network. But not all water meters are equipped with AMR. We need to estimate the unknown consumption of the non-AMR to be able to apply the maximum flow problem. These non-AMR consumptions could be estimated in many ways, from smoothing an equal proportion of the missing outflow at all the unknown sinks, to an individual consumption estimate (Ghul & Brémond, 2000). In this paper we used a methodology presented in [START_REF] Claudio | Water consumption estimation of an hydraulic district from a sample of users equipped with automatic meter reading[END_REF] which was the one currently used by Suez who deals with the case study contract. This methodology consists in an annual consumption level group division of the population based on a Horvitz-Thompson estimator. The non-AMR consumption is then estimated according to the average AMR consumption of the group in which they belong.

 Type b: Those providing observations within the network. These sensors measure the quantity of water passing through the node giving local information about the flow rate and flow direction. According to sensors nodes we can constrain the capacity , introduced earlier in section 3.1, with the value measured by the sensor. So, for all edges connected to a sensor node in , the maximum possible flow become an observed flow . Moreover, the read direction of sensors is known, giving us the flow direction of the flow rate measured. We can then set the direction of the adjacent edges of any sensors.

Flow Network Construction

In this section we present how we build a flow network according to the data presented earlier to apply a data driven maximum flow problem in our case of a WDN.

First things first, as define in graph-theoretic field (Hieneman et al., 2008;[START_REF] Ahuja | Network Flows: Theory, Algorithms and Applications[END_REF]) a flow network must be a directed graph in which each edge has a nonnegative capacity

The nonnegative capacity was set through structural information for non-measured edges and by the sensors observations for the measured ones (section 3.1 and 3.2). But our network is initially semi-directed because all the edges are not observed, and the flow directions are not known.

Because flow could potentially come from any side of the pipe, we duplicate all the edges to create bidirectional edges in the network. For each edge we add an extra edge to obtain two antiparallel edges and and we set the capacity of both edges to the original one . Like in a real-world, flow inside pipe can only go in one direction at a time, so the flow is not allowed to be in both antiparallel edges in the same time. For the measured edges the flow direction is known so the extra edge created will not be used. We will constrain the algorithm to not take a path that could contradict an observed edge.

We need to distinguish two vertices type in flow networks: the sources and the sinks . To determine a maximum flow each vertex must lies on some path from the source to the sink. Our flow network has several sources and sinks rather than just one. As described in [START_REF] Cormen | Introduction to Algorithms[END_REF], we can reduce the problem of determining a maximum flow with multiple sources and multiple sinks to an ordinary problem (Figure 2).

To do so we add a supersource node and directed edges for each of the source nodes. The capacity is set to be the measured inflow of the sensor source node . We also create a new supersink node and add directed edges for each of the sink nodes. The capacity is set to be the measured outflow of the node . Intuitively, any flow in the multi-sources, multi-sinks network remains the same. The single source provides as much as flow as desired by the multiple sources and the single sink likewise consumes as much as flow as desired for the multiple sinks .

We now have a flow network as a directed graph , where and are node set and edge set, respectively; s and t are the supersource, and the supersink, respectively; and is a nonnegative capacity on the edges. Let be a real-valued function . The nonnegative quantity is the flow from the vertex to vertex . We want to reconstruct the flow in that satisfies these constraints:  Maximum flow:  Conservation :  Antiparallel coherence:

FLOW RECONSTRUCTION

We choose an implementation in C++ of the Ford-Fulkerson method [START_REF] Ford | Flows in Networks[END_REF] to compute the min-cut max-flow problem. Like in Edmonds-Karp method [START_REF] Edmonds | Theoretical improvements in algorithmic efficiency for network flow problems[END_REF] we use a breadth-first search (BFS) algorithm to find the augmenting path. We want to constrain the algorithm to find path first by observed edges to saturate the flow in these edges. To do so we consider, preferred as a vector containing all the observed edges for which the flow rates and flow direction are known. These edges are considered as preferred edges. Because they represent real observation in the network, we must first saturate them while solving the maximum flow problem. These preferred edges must be traveled in the observed flow direction. The flow inside them can only increase resulting in a constrained maximum solution but not the maximum flow solution of the Ford-Fulkerson method as described in the figure bellow. A bidirectional BFS is used to force path to go from the supersource to the supersink passing by all the preferred edges. As described in Figure 4, it starts at source node and explore the neighbors nodes before moving to the next level neighbors. While a path exists and for each nodes of the same level we repeat the same process until the sensor node is reach. The operation is repeated to find a second path starting to the sensor node to the nearest sink passing by edges still unvisited by the first path to avoid loop in the network. If the two paths are not empty, we found a valid path from to through the sensor node preferred . We can add a flow through the path representing the smallest remaining maximum capacity of all edges in the path. This process is repeated for all the preferred edges until there is no more path available going through them from to or if the flow of the preferred edges has reach the observed flow (

). If the sensors capacities are reached or if there is no more augmenting path available for the sensors edges, we try to add all the remaining flow in the network as a classical maximum flow problem by looking at augmenting path from to . Decreasing the maximum flow or going through reverse direction on observed edges is still forbidden during this process. For all the nonobserved edges both antiparallel edges are available. But as described in section 3.3 theses antiparallel edges represent the same physical pipe and water can't be at the same time in both. When a new flow goes through an edge in the same direction we simply add it (see line 12 Algorithm 1). When a new flow goes through an antiparallel edge while the edge was already visited in the other direction, the flow must be updated to respect the antiparallel coherence constraint and to determine in which edges the remaining flow is.

The constrained Ford-Fulkerson algorithm presented in the pseudo code Algorithm 1 returns for all edges a flow rate. For all the non-observed edges the flow direction is known according to the nonnegative edges. For all the observed edges we have the flow rate regarding to the expected flow. This information will help us determine if the maximum flow solution is close to observed state of the network. The Figure 5 present an output of the Algorithm 1.

CONCLUSION AND DISCUSSION

We presented a methodology to create a flow network to estimate flow directions and flow rates inside a real WDN from sensors and GIS data. These results allow us to determine the age and origin of water in any point and time of the network which is an important result to answer to most of the future WDN operation challenges. We introduced a constrained Ford-Fulkerson algorithm to take advantage of all the sensors information and force the solution to respect the observed value. The result obtained on the case study of the Bordeaux Metropolis WDN are satisfying. They helped us to detect inaccurate information in both structural and sensors data. We could for example check the validity of the flow direction given by a sensor, if no flow was able to go through it during the algorithm and if by reverting it we were able to saturate the edge. The information was then confirmed by a real observation and updated into the database.

The fact that the outflow information isn't completely known on the case study do not allow to saturate all the sensors nodes. Indeed, more than 50% of the outflow is estimated. Since this estimate is based on annual consumption profile, there is area of the network where consumption is overestimated and conversely underestimated. Moreover, to apply the maximum flow problem a proportion of the missing outflow (due to underestimate or leak) is smoothed through all the estimated nodes to obtain inflow equal to outflow. We could detect through connected sub-graph of the network (in which flow entering and leaving the area was measured) that even if sensors were saturated we still have sink node requiring outflow describing the fact that consumption was overestimated in this area. Conversely, we detected that consumption was underestimated in some area because sensors were not saturated, but all sink node were satisfied. We can therefore improve the results provided by the algorithm by spatially refining the consumption estimates by looking at connectivity of the graph. Future work will be to enhance the methodology with more data related to management of WDN that could constrain the number of solution of the maximum flow problem with for example intervention (e.g. valve operation, pipe break) or leak detection information.

Figure 1 .

 1 Figure 1. Schematic data representation related to the management of water distribution network.

Figure 2 .

 2 Figure 2. Converting a multiple-source, multiple-sink problem into a problem with a single source and a single sink.

Figure 3 .

 3 Figure 3. (a) A flow network with one source and one sink . Each edge is labeled with its flow and capacity (flow/capacity). (b) A flow in with value with no preferred edges. (c) A flow in G with value respecting the observed flow direction and capacity of the edges and .

Figure 4 .

 4 Figure 4. Bidirectional breadth-first search from source node s to sensor node v and from v to sink node t.

FORD

Figure 5 .

 5 Figure 5. Output of the Algorithm 1 on the Bordeaux Metropolis (France) WDN composed by nodes and edges. In light green sink nodes that have been saturated, in light red non-saturated sinks. Squares represent sources nodes. Saturated ones are in blue and those with remaining flow are in yellow. The green dot represents sensor nodes saturated during the bidirectional BFS, and the red ones are those where the flow didn't reach the measured flow.