3 Years Plan 2004-2006

Three research themes: OAI, Models for Information Systems Management, Algorithm Synthesis

1. OAI (Optimization of Application Integration)

My second field of research comes from a practical observation that the deployment of EAI (Enterprise Application Integration) yields very interesting problems, from an OR (Operations Research) point of view.

The problems can be stated simply (cf. following Figure) as the optimization of a grid of systems so that the SLAs (Service Level Agreements) of a set of global (across the grid) process are met. This is a truly practical issue, namely a QoS (Quality of Service) issue.

Defining the QoS of a process does not differ from what one may expect in the world of IT: it is a question of throughput, latency and availability. Throughput measures the number of individual processes that can be performed in a fixed amount of time like a day. Many business challenges, from sales to customer care, rely on the ability to process so many customers events in a day. Latency is the time taken for the end-to-end execution of a single process, which is most often what the customer sees and reflects the quality of service that is perceived. Availability is the percentage of the time when the system is able to start a new process. A Service Level Agreement (SLA) will state that the IT systems must accept this many customer processes in a day with a completion time lower than a given bound for at least so many of them (a ratio) and a rejection rate less than another (small) number.

Meeting such a SLA, and even monitoring this SLA, is a hard task because the engineering (sizing and capacity analysis) is done on the individual systems and the infrastructure. We do indeed design and build individual systems with a fairly precise characterization of their availability, their throughput and their latency. However, the reverse-engineering from the SLA at the process level is hard for multiple reasons:

(1) The availability of systems coupled in asynchronous manner is difficult to evaluate (it is definitely not the product of availabilities, as with a synchronous approach). It depends on a lot of parameters and one may build a reliable asynchronous system with components that are far less reliable (using buffers and replication)

(2) The sizing issue is not a stationary flow (which is itself not so trivial because of the multi-commodity aspect) but a stochastic problem about the resolution of busts. Real-life situations create burst of messages that are difficult to process.

(3) The management of the flow is complex from a functional point of view: it is a matter of protocol rather than “simply” a matter of sizes of pipes & engines. The analogy with fluid physics is …only an analogy and the tricky questions come from the rules for handling priorities and congestion in the message traffic.

(4) Processes are interdependent because they operate on shared business objects. This dependency (a classical problem with databases) may be handled with serialization, which induces serious constraints on QoS, or with interleaving of processes and additional “re-synchronization” processes to correct the possible discrepancies.

(5) The pure stochastic asynchronous problem is made harder in real life with a combination of synchronous and asynchronous communications, and a combination of planned flows and stochastic flows which creates interesting planning issues.

We have coined a new name, OAI, Optimization of Application Integration, for this problem, which is illustrated by the following Figure. It is a multi-faceted problem, since we need to find:

- sizing rules, for our system architect,

- message handling and routing rules, for our software architects,

- monitoring strategies, to understand what goes wrong,

- operations procedures, for our operations staff when an incident occurs,

- simulation tools, to validate software and system architecture, as well as monitoring strategies

You may find my first OAI paper here. A longer (journal) version should be available soon. You may also find an introduction to this topic in my book.

2. Models for Information Systems Management

The theme here is the understanding of information systems and their organizations.

I started in 1998, when I was asked to build a model for Bouygues Telecom's IT costs forecasting. It has been an endless journey since then, but I managed to make some progress along the way. I have grown over the years various models which seem to reflect the budget and activity of our division with some accuracy.

The second set of questions that I have found in my management practice has to do with organization principles and how they are reflected in the various recipes which exist in the field of management consulting. I have been reading "classics of organization theory" (literally, this is the title of an excellent book by Shafritz and Ott) and got very much interested by the "organizational architecture" topic.

This has led to a research program called SIFOA, for "Simulation of Information Flows and Organizational Architecture".

3. CECILE

This my last theme, which is active only when I participate to a ROADEF challenge ...

CECILE’s main objective is the ability to produce an efficient problem solving tool using a method that is as declarative and as simple as possible. Since a fully automated approach does not seem feasible based on the past twenty years of experiments, a compromise must be found between a declarative approach that would be too naïve and a pragmatic approach that would be too “deep”, thus requiring an expert-level in the field of OR and a complex development process (one might say those are the LAURE and the CLAIRE approaches).

Finding the proper balance requires two things:

(a) the ability to encapsulate prior knowledge about problem solving in a truly re-usable format,

(b) the ability to guide a semi-generic solution search method with the user insights, using a “language” that is declarative (the contradiction is intended).

The main idea for CECILE is the principle that objects should be used as foundation paradigm for integration, not constraints or logic variables. This is a departure from the “global constraint” and the “solver libraries” approach.

The following figure is a crude description of what CECILE may look like. The light-colored boxes are the problem-dependent pieces of the puzzle.

Here is the long term roadmap for the CECILE project:

(1) Collect problems and produce models

(2) Identify library of components

(3) Design Glue “Toolbox” : “Combinators” = Relations & Constraints

(4) Design Declarative Assembly Language

(5) Design Algebraic Factory for handling large-scale problems

(6) Build Component Library

(7) Build Library of Heuristics

(8) Build CECILE v0 system

A word about CLAIRE:

The CLAIRE project is 10 years old in 2003. It has become a mature programming language with a small but stable community, thus the activity on the CLAIRE project is expected to continue, but with a focus on quality rather than innovation. As a research project, my feeling is that CLAIRE has received enough attention and that most exciting leads have been looked at, if not followed.

CLAIRE was itself the successor of the LAURE project (from 1984 to 1994), and it is time to switch to another slow-pace, language-based project (CECILE).

CLAIRE plays a major role in all my other research projects: it is a fabulous productivity accelerator. It enables me to spawn many short-term research projects during the year although I have very little time. Thus my involvement in maintaining CLAIRE should be stable for at least the next ten years.

Google Sites

Report abuse