Complex Systems and Autonomy

This blog is “moving” very slowly because I am currently much more involved with the theme “Information flow and Enterprise architecture”. I am currently working on Social Networks, and it turns out that there are a number of themes which are equally relevant to my two research interests.
For instance:

• I will soon post a review of Robert Axelrod’s book “The Complexity of Cooperation”, which could appear in both my blogs. This book introduces a few key concepts, such as the use of game theory and genetic algorithms to study patterns of (stable) cooperation.
• I attended a few sessions of the conference on “Complex Systems”, which I thought was appropriate considering that DIS (Distributed Information Systems) are indeed complex systems, and it turns out that social networks, including those that represent the information flows within a company, are the focus of “complex system approaches” as well. The 7th PCRD has made “socially intelligent IT” a hot priority.

My program nowadays is mostly to continue my education and read books. I will give a lecture in October for which I would like to extend the OAI research I have already talked about. More precisely, here are the two directions that I will pursue this summer when I resume my experimentation work:

1. Explore different scales and designs of systems to see what kind of influence they have on the behaviour of “smart” routing rules for process control (through message passing). Most of the experiences that I have made so fare try to reproduce business processes from Bouygues Telecom. Since I am using different “Enterprise Simulation Scenarios” in my SIFOA experiments, I plan to reuse this modelling effort. By scale & design, I mostly mean the number of processes, the number of tasks and systems involved in a process, and the interaction topology induced by the SOA architecture.
2. Try to model the handling of exceptions, that is, to model the alternate processing path which is used once a component is unavailable to deliver a business process. The difficulty here is that it is often an ad hoc approach (cf. my papers and my books). On the other hand, with the current trend of virtualization, more systematic alternate approaches will become available. I attended an interesting lecture on Autonomic computing from IBM which made the obvious-but-profound point that there is no autonomy without choice, and that choice comes (mostly, in the world of IT) from virtualization. There is little room for improving the handling of exceptional situations and failures with autonomic computing if a traditional architecture (hard links between dedicated resources) is used. On the other hand, in a virtualized world, there are many interesting options (hence a choice) when a server becomes unavailable.
   

This means that I am currently focusing on the points (1) and (2) of my previous list.
Following the suggestion from Cedric Nicolas, I just read “the age of spiritual machines” from Ray Kurzweil. It is a fascinating book, with very insightful thoughts, especially about consciousness and intelligence in a machine (or a network of). I am less enthusiastic about his prediction of the future (2009-2019-2099), but it is only a fourth of the book and the first three quarters are enlightening. I will return to the topic of consciousness when I post a review of Kevin Kelly’s book. I also finished a book from Jean-Claude Ameiesen, “La sculture du vivant” (following a suggestion from Pierre Haren) which is totally different (a biology book about programmed self-destruction of cells) but equally fascinating. This type of biology book makes it even more convincing that large scale man-made systems must draw their inspiration from living organisms. There are a number of mechanisms designed to yield both stability and flexibility/adaptability (somehow antagonistic) which are worth reproducing.

Five Challenges for Entreprise Architectures

I have defined previously the subject of this blog in a very general manner, trying to look at the “big picture” (almost from an epistemological point of view). The “big question” is : how much autonomy and “intelligence” needs to be fed into an information system in order to achieve the properties that are expected - resilience, performance, reactivity … and so forth. The reasoning is as follows. Large-scale information systems are, truly, complex systems which exhibit all the classical properties of such systems : fractal/recursive structure, non-linear behaviour when they receive an incoming flow of event (cf. the interesting amplification loops of acknowledge/resend messages due to fault-tolerant mechanisms), “emergence” of large-scale properties that are different from those at the component scales, etc. This is why I will use this blog as a forum to relate my (slow and progressive) journey into the world of complex systems and their theory.

Today I will look at the topic from the other side, taking my former “CIO hat”. I will describe five architectural/design challenges that face a modern (large) enterprise. The following is a list of the issues that I have been struggling with during my five-years tenure, and which, I believe, are relevant to many companies with similar scale (size of IS) and scope (role of IS within the business processes). This is not to say that these are “open problems”. Indeed, we found solutions to each of those, as did other corporations. On the other hand, no definite answer has been proposed yet :

• these are ad hoc solutions and they leave some questions un-answered,
• the state-of-the-art, as defined in books or architectural frameworks that are sold by consultant, is surprisingly shy on these topics,
• the academic research is only touching the “surface” of these problems.

These are very practical questions, one of the goal of my research is to build a link with the more forward-looking / science fiction / philosophical discussion on autonomic and intelligent systems. As a matter of fact, one of my long term goal is to address these issues in my computational experiments, such as those I made for the OAI research :

Self-adaptive middleware: Supporting business process priorities and service level agreements
Advanced Engineering Informatics, Volume 19, Issue 3, July 2005, Pages 199-211

Here is a short description of each of them, I will return with a more detailed description on some other occasion.

(1) How does one guarantee the Quality of Service, defined at the business process level, from the system-level properties of the individual components? This is a key a challenge for any IS architecture framework, including service-oriented architecture (SOA). I have coined the OAI term to describe this issue and a simple description may be found on my web site (http://claire3.free.fr/yves_research.htm), while a more detailed presentation is included in the afore-mentioned AEI paper. This is clearly an open-ended issue, my preliminary work has led to more questions than answers.

(2) What is the proper approach to achieve resilience (lowest possible impact of system-scale failures of one or many components) ? This is where the biology comes in (cf. my previous message) : the mechanical view of robustness through redundancy (multiple copies and spare parts) shows its limit in the real world, and, most often, real life crisis are resolved through alternate scenarios (an “organic approach”). It turns out that there already exists a number of alternate approaches: an older system that has not been disconnected yet, a simplification of the business process that is still acceptable, a different component that may render a simplified version of the service, a raw computer utility/patch/batch that fixes 80% of the problem (measured in dollars) with a fraction of the effort (measured in function points), etc.

(3) What kind of data architecture is best suited to distribute business objects in a coherent and efficient way ? Business objects need to be distributed in a large-scale system for performance reasons, but they participate to business process executions, which require some kind of coherence. This leaves roughly three options:

• Assume a separate mechanism that will ensure the coherence of the distributed objects (precisely, a distributed database system management system - DDBMS J). On a small-scale system, or with a homogeneous system, this is obviously the most logical approach. We sub-contract this coherence issue to another system, and run the business processes assuming that distributed objects are coherent. It turns out to be difficult (the so-called “snapshot problem” of DDBMS cannot be solved in its full generality) and quickly unpractical once one builds an information system out of COTS (commercial, of the the shelf) software components (heterogeneous).

• Take responsibility of “business object distribution & coherence” as part as the business process management. In other words, ensure that the business process flow pushes all relevant updates so that it guarantees that, as far as the execution of the process is concerned, the objects always are in a coherent state. The synchronization of business process events and object management events is, indeed, a tricky issue.

• Define an acceptable level of “chaos”, that is accept that complete coherence is not necessary ! This is actually a generalization of the previous approach, and is closer to reality (real large-scale systems survive with a fair amount of non-synchronization).

Finding a proper approach that is robust to errors, (i.e., contains a proper long running transaction mechanism) is, as far as I can see, both a truly practical question (this problem is everywhere, although many fail to recognize it) and a difficult one.

(4) What is the nature of service-level contracts which will yield the ability to evolve in a flexible and distributed manner? This is the quest for “upper compatibility” when designing service interface (for instance in a SOA approach) which should enable a truly distributed evolution of the IS as a whole. My experience is that this is a difficult topic, and that large IS projects are often necessary when one components is upgraded from one version to another – a lot of interface work and a lot of non-regression testing.

(5) How does one achieve a modular architecture that still takes advantage of the opportunity to share and reuse services? In the world of SOA, this translates into the definition a common, global directory of shared services. There is an obvious (and classical) tension between distribution and centralization. A common shared service is the opportunity to reduce cost, reduce size (hence complexity) and ensure more coherence. On the other hand, it may render the evolution of the system more difficult, and certainly requires mechanisms to operate the community of stakeholders (who use the service), to govern the roadmap of the shared component. It is also essential (as for large-scale software) to introduce some level of abstraction and encapsulation, which prevents a unique, common and shared directory of all services. The structure that defines a distributed directory of services with its proper governance mechanism (with visibility and decision rules) is yet to be defined to implement an enterprise-wide service-oriented architecture.

Since one of my current goals is to draw as much relevant information as possible from the literature on complex systems, I will post regularly my findings and try to explain how they related to these five questions.

Strong AI and Information Systems

The following is a translation of a discussion with three students from ESIEE: Philippe Glories, Erwan Le Guennec, Yoann Champeil.

- According to you, where mostly does one finds IA in everyday’s life ?

There are two types of answers, according to the scale of systems. Large scale systems require distributed AI (multi-agents, etc.) , whereas smaller scale systems may rely on the many technologies that have been developed so far for “local use” (such as expert systems, constraints, knowledge bases and inductive or case-based reasoning, fuzzy logic, etc.). Actually AI is already everywhere ! In picture cameras, cars, central heating, … and equally in existing applications from current Information Systems. As far as embedded systems are concerned, fuzzy logic (and neural nets) are heavily used for intelligent control. Information Systems applications make use of rule-based systems (sales rules, monitoring rules, and so on).

Large-scale applications of distributed AI are scarcer, as far as I know.

- May one talk about “strong AI” (as opposed to “weak AI”, see http://en.wikipedia.org/wiki/Strong_AI) to deal with autonomy ? (The autonomy would require self-awareness to manage oneself)

This is both a possible and useful distinction, although it is difficult to manage because of the continuous nature of autonomy. However, one may distinguish between AI based on applying rules to a situation and AI that uses a model of the problem it tries to solve, together with a model of its own action capabilities (a meta-representation of oneself being a first step towards consciousness), to that it may adapt and devise different appropriate reactions.

I would present a different type of distinction: made (or “built”) AI vs emergent (or “born”) AI. In the first case, a piece of software produces (intelligent) solutions that are predictable as a consequence from the original design. In the second case, the nature of solutions is harder to foresee, they emerge from the components together with the reflexive nature of the application (meta-model). It is another way to look at this weak/strong difference.

- Is the creation of autonomous AI already feasible ? Do we hold the technical means ? If missing, are we about to get them in a few years ? Are there any special theories that are requires to develop these ?

I am no longer enough of an expert to answer this question with any form of authority. I believe that the answer is positive, in the sense that we have all that we need, from a technology standpoint, to create autonomous AI. It is mostly a knowledge representation issue.

- Do you feel that the creation of autonomous AI is advisable and desirable ? From an industrial perspective? From a society perspective? From a scientific perspective ?

This is a large and difficult question !

I would answer positively, since I believe that only a strong AI approach will enable us to break the complexity barrier and to attack distributed AI problems. This is especially true for Information Systems issues, but I believe this to hold for a more general class of problems. To say it differently, solving successfully distributes problems may require to relinquish explicit control and to adopt an autonomous strategy (this is obviously the topic of this blog and of Kelly’s book).

There are associated risks, but one may hope that a rigorous definition of the meta-model, together with some form of certification, may help to master those risks.

Obviously, one of he risks, both from an industrial or social perspective, it to see the emergence of systems with “too much autonomy”. As a consequence, a research field that needs to be investigated is the qualification of “degrees of freedom” that are granted to autonomous systems. A precise answer with collide with classical indecidability problems, however abstract and “meta” answers may be reachable.

- From a philosophical point of view, do you see autonomous artificial intelligence as a threat to mankind ?

No, from a philosophical point of view, autonomous AI is an opportunity. There is a danger, however, from both an ethical and practical standpoint. Practically, the abuse of autonomy without control may have negative consequences. From an ethical point of view, there is a potential impact on society and work economy, as the delicate balance between production and consumption roles may be affected (which is true, by the way, for any method of automation).

- To summarize, would you qualify yourself as an opponent or an advocate of autonomous AI ?

Without a doubt, I see myself as a proponent of AI ! The reasons are, in part, those expressed in this blog: autonomous AI is the only approach to resolve complex problems, for which a solution is really needed. I see delivering the appropriate level of quality of service in an information system an example of such a worthy cause :)

A last remark : the scale issue is really key here. The same rules should not apply …

(1) On the small scale, components should be built using a “mechanical vision”, with proper specifications, (automated) testing and industrial quality using rigorous methods. When “intelligent” behaviour is needed, classical AI techniques such as rules or constraints should be used, for which the “behavioural space” may be inferred. Although this is just an intuition, I suspect that components should come with a certification of what they can and cannot do.

(2) On the other hand, large-scale systems, made of a distributed network with many components, should be assembled with “biomimetics” technology, where the overall behaviour will emerge, as opposed to be designed. My intuition is that declarative, or policy-based, assembly rules should be used so that a “overall behavioural space” may be defined and preserved (which is why we need certified components to start with). The issue here is “intelligent control”, which requires self-awareness and “freedom” (autonomy).

Autonomic Computing

Since "Autonomic Computing" is a key concept related to the topic of this blog, I have translated an extract from my book ("Urbanisation et BPM"). It is not the best reference on the topic :) but it will give an overview for readers who are not from the IT community. This extract was written in 2004 (therefore, it is no longer precisely up to date ...)

Autonomic computing (AC) is the name given to a large-scale research initiative by IBM, on the following: mastering the ever increasing complexity requires to make IT systems « autonomous ». More precisely, « autonomic » is defined as the conjunction of four properties :

(1) self-configuring : the system adapts itself automatically and dynamically to the changes that occur in its environment. This requires a « declarative » configuration, with a statement of goals and not a description of means. A good example of such a declarative statement is the use of SLA as parameters. When something changes, the system tunes its internal parameters to keep satisfying its SLA policy.

(2) self-healing : the management of most incidents is done automatically. The discovery, diagniosis and repair of an incident are made by the system itself, which supposes a capacity to reason about itself. Therefore, such a system holds a model of its own behaviour, as well as reasoning tools that are similar to so-called “expert systems”. This is often seen as the comeback of Artificial Intelligence, although with a rich model, simple and proven techniques are enough to produce an action plan from incident detection.

(3) self-optimizing : the system continuously monitors the state of its resources and optimizes their usage. One may see this as the generalization of load balancing mechanisms to the whole IT system. This requires a complex performance model, which may be used both in a reactive (balancing) and proactive (capacity planning) manner (cf. Chapter 8).

(4) self-protecting : the system protects itself form different attacks, both in a defensive manner, while controling and checking accesses, and in a proactive manner though a constant search for intrusion.

(note: To start with an excellent introduction to « autonomic computing », one must read the article « The dawning of the autonomic computing era » from A.G. Ganek and T.A. Corbi, which may be found easily on the Web)

The interest of these properties and their relevance to the management of IT systems are self-evident. One may wonder, however, why a dedicated research initiative is called for, instead of leveraging on the constant progress of the associated fields of computer science. The foundation of the Autonomic Computing initiative is the belief that we have reached a complexity barrier: the management cost of IT infrastructure (intallation, configuration, maintenance, …) has grown relentlessly with their size and power, it represents more than half of the total cost. Next generations of infrastructure will be even more complex and powerful. IBM’s thesis is that their management is possible only if it becomes automated. In the article that we just quoted, a wealth of statistics is given that shows the ever-increasing part of operational tasks, while at the same time the business reliance on IT system is equally growing, resulting into financial consequences of IT outage that are becoming disastrous.

Therefore, a breakthough is necessary to overcome this complexity barrier : in the future, IT systems need to manage and repair themselves automatically, with as little human intervention as possible. This may sound far too ambitious and closer to a “marketing public relation initiative” than a directed research project : after the eras of distributed computing, autonomous computing and ubiquitous computing, here comes autonomic computing. This initiative flows continuously from computer science research themes of the past 30 years. Some of the problems and solution directions are actually old. However, two paradigm shifts have occured. First, the center of attention has evolved in the last few years from software (component, application) to software system (hence the focus on enterprise archictecture and business process). In the 80s and 90s, the focus on problems similar to those of AC has given birth to the concept of intelligent agents, but their application to the full scale of corporate IT has proven to be difficult. From a CIO perspective, the focus on enterprise architecture and infrastructure is a welcome shift, especially since the research budgets are impressive. On IBM’s side, this is the main theme for a R&D budget of over 5 billions dollars. Most other major players also work on similar initiatives, even though the vocabulary may vary.

The second paradigm shift is the emergence of the biological model of incident processing. This is a departure from an endless search of methods that would produce software free from bugs and multiple back-ups that would guarantee a complete availability of infrastructures. Autonomic Computing applies to the “real world”, where software contains many defects and run on computers that experience all sorts of outage, and draws analogy from “living organisms” to deliver fault-tolerant availability. Living organisms cope with a large spectrum of aggressions and incidents (bacteries, viruses, …) with a number of techniques: redundancy, re-generation, self-amputation, reactive aggression, … etc. Similarly, autonomous IT systems need to be designed to perform in an adverse environment. The analogy and inspiration from biology is a long-lived trend in computer science. For instance, the use of “ evolution theory” as an optimization strategy has produced genetic algorithms or swarms approaches. To quote a NASA expert, who is applying the concept of swarm to micro-robots, some part of the design is replaced by “evolution as an optimization strategy”.

Even though there is a form of utopia in this field and many goals are definitely long-termed, this is not science-fiction. There is an evolutionary course towards autonomic computing and the first steps correspond to technologies that have already demonstrated in research labs. Actually, there is a symmetry in the founding argument: if we are not able to provide our new systems with more autonomy, there progress in scale and complexity will soon reach a manageability limit. It is, therefore, logical to bet on the forecoming availability of autonomic capabilities. The issue is not: “If the systems become autonomous”, is is “when” and “how”..

Automic Computing is not a philosophy, it is an attitude, according to the experts. Systems should be designed to be autonomous from the very early design, even though some of the choices and options may still be very rudimentary. An illustration drawn from the practice of real-time systems is the heartbeat principle. A heartbeat is a periodical simple signal that each component broadcast as a testimony to its status (alive, weakened, distressed, etc.). The « heartbeat » principle comes from the real-time systems community. For instance, it is used for NASA ‘s satellites under the « beacon » designation. On this topic, one may read, the papers from the NASA research center in the proceeding of the autonomic computing workshop that was part of EASE’04.

This proactive attitude seems relevant to the design of information systems. The paper form Ganek and Corbi makes a strong argument in favor of evolution, as opposed to revolution, based on a roadmap that goes from “basic” to “autonomous”. The progression is labeled through the steps: managed, predictive, adaptative and autonomous. It is completely relevant to the transformation of business process management, as described in Chapter 8.

AC and Enterprise Architecture

The foundations of autonomic computing are well suited to the field of Enterprise Architecture, since IT components make a large and complex system. Hence, many aspects of the AC approached are relevant to the re-engineering of IT. We shall now consider three: autonomic computing infrastructure, autonomic business process monitoring and “biological” incident management. There is a clear overlap, but we shall move from the the most complex to the more realistic.

The concept of autonomic IT infrastructure has received the most media attention since it is the heart of IBM strategy, being a cornerstone of the on-demand computing (cf. 11.3.2). An autonomic infrastructure is based on computing resource virtualization; it manages a pool of servers that is allocated to application needs on a dynamic basis. The global monitoring allows load balancing, reaction to incidents through reactive redistribution, and dynamic reconfiguration of resources to adapt to new needs. The ultimate model of such an infrastructure is the GRID model, which implies that grid computing is de facto a chapter of autonomic computing. A grid is a set of identical anonymous servers that are managed as one large parallel computing resource. The management of Grid computing has already produced valuable contributions to the field of AC. For instance, the most accomplished effort to standardize with “quality of service” means in the world of Web Services, WSLA, comes from the world of grid computing. One may read « Web Service Level Agreement (WSLA) Language Specification”, and see, for instance, how performance-related SLA are represented (under the measurement headins, 2.4.8). One may see the grid as a metaphor of tomorrow’s data center. Therefore, even though the grid is often reduced to the idea of using the sleeping power of a farm of PC during the night, most CIOs should look into this field as a guideline for their own infrastructures.

A grid is by construction a resource that may be shared. It has interesting properties of robustness, fault-tolerance and flexibility. It is, therefore, a convenient infrastructure to bridge the gap between the autonomic and the on-demand computing concepts. A “on-demand” infrastructure is a flexible computing infrastructure, whose capacity may be increased or decreased dynamically, according to the needs of the company’s business processes. Such an infrastructure may be outsourced, which yields the concept of “utility computing” as a service, or it may be managed as an internal utility. There is more to “on-demand computing” than the infrastructure aspects, which will be covered at the end of this chapter. The synergy with autonomic computing is obvious: the business flexibility requirements of the on-demand approach demand a breakthrough in terms of technical flexibility which translates into autonomic computing, and is well illustrated by the grid concept.

This vision is shared by most major players in the IT industry. However, we consider this as a long-term target, since the majority of today’s application portfolios in most companies may not be migrated smoothly onto this type of infrastructure. This does not mean, as was previously started, that some of the features are not available today. For instance, “blade server” infrastructures deliver some of the autonomous benefits as far as self-configuration, self-management and self-healing are concerned.

On a mid-term perspective, one may expect the field of autonomic computing to have an impact on business process management. The field of OAI (Optimisation of Application Integration, cf. chapter 8) is equally a long-term, complex research topic, but which will benefits from small-steps improvements. Two family of software tools are currently evolving towards autonomous behavior: integration middleware and monitoring software. BAM (business activity monitoring) software is integrating capabilities to model and to simulate the occurrence of business incidents. Adaptative middleware or “fault-tolerant” middleware are emerging. For instance, look for the Chameleon project, which belongs to the ARMOR approach (Adaptive, Reconfigurable and Mobile Objects for Reliability). Chameleon is an integration infrastructure which combines adaptability and fault-tolerance.

On a short-term perspective, one may apply the “biology metaphor” of autonomic computing to formalize the management of incidents, as it often occurs in the “real world”. To summarize, one may say that system operation relies on two visions: a mechanical and an organic one, to deliver the continuity of service that is required by its clients. The mechanical vision is based upon redundancy, with back-up and spare copies of everything. When something fails, the faulty component is replaced with a spare. Depending on the recovery time constraints, this approach translates into a disaster recovery plan, into clusters, fault-tolerant hardware, etc. For instance, one may look at the discourses from Carly Fiorina, HP’s former CEO, who focuses on mutualization, consolidation and virtualization under « Adaptative Enterprise » vocable. The same keywords appear in SUN’s or Veritas’s strategy about servers and data centers.

The organic vision is based upon alternate scenarios and re-routing. It is derived from an intimate knowledge of business and its processes. It consists of a network of “alternate sub-processes”. It requires a strong cooperation between operation managers, application developpers and business owners. Only a precise knowledge of the business and its priorities enable a transverse team to find valid “ alternate approaches”. We named this approach « organic operations », which may be described with the following goals :

1. Create an operations model which supports the definition of scenarios and takes all operations tools and methods into account (some of which are represented with hatched boxes in the figure). Stating existing recovery procedure in a formal and shared manner is both the first stage of maturity and a possible step towards automation.
2. Create multiple levels of “reflexes and reaction”, which are automated incident management rules. An interesting contribution from the biological metaphor is the separation between reflexes (simples, distributed) and reactions (centralized, require a « conscient » intelligence).
3. Create the tools which allow us to make “intelligent” decisions. These may be representation/cartography tools (which is linked to the topic of business activity monitoring) or planning/simulation tools : what would happen if the message flow from component A was re-directed towards B ?

Welcome Message

The first message of a blog is always the most difficult : one does not know where to start. Today I’ll just describe some of my motivations and objectives.
I have become fascinated over the last few years with the topics of emergence, biomimetics (http://www.bath.ac.uk/mech-eng/biomimetics/about.htm), autonomic computing (http://www.research.ibm.com/autonomic/) and artificial life. I look at these topics from a dual perspective : as a sientist and as the CIO of a large organization.

1. Motivations :

The opening of this blog is the result of three converging threads :

1. OAI : Optimization of Application Integration.
   OAI is the field of optimizing the quality of service in a business process-oriented IT infrastructure. The link with EAI is obvious ... and dated. Today, it would be smarted to talk about an SOA architecture. The problem is the same, though : how does one optimize the quality of service, measured at a business process level, in a real-life information system (i.e., with failures, bursts, and so on).
   I have looked at this problem with my operations's research culture, it is a beautiful problem : rich, complex and very relevant to real life operations.
   You may look at my last published paper on this topic: Self-adaptive middleware: Supporting business process priorities and service level agreements • ArticleAdvanced Engineering Informatics, Volume 19, Issue 3, 1 July 2005, Pages 199-211Caseau, Y
2. Autonomic Computing.
   I won't start telling with AC is for me in this short message. I wrote quite intensely about it in my book about Enterprise Architecture and Business Processes. I'll post a message with a translation of a short fragment to state my positition. The key point is that I am a believer, from my CIO standpoint: the only way to achive the kind of cost reduction, complexity reduction and improvement of QoS is to let Information Systems become "autonomic".
3. The reading of the fascinating book "Out of Control" by Kevin Kelly.
   It will take me a number of messages to share all the insightful comments which I have found in this book.
   For instance, these are two my favorite quotes from this book.
   « Investing machines with the ability to adapt on their own, to evolve in their own directions, and grow without human oversight is the next great advance in technology. Giving machines freedom is the only way we can have intelligent control. »
   "The great irony puzzling cognitive scientists is why human consciousness is so unable to think in parallel, despite the fact that the brain runs as a parralel machine. [...] That's why the first computers were programmed in the von Neumann's serial design : because that's how human think. And this, again, is why parallel computers must be evolved rather than designed: because we are simpletons when it comes to thinking in parallel."

It turns out that these three threads are totally related, and the combination is the foundation for the "theory of the live information system" :)

I will illustrate this with a quote from my own new book (coming out in a few months) :

"Information Systems complexity will be mastered once the IS has become alive. This "livelyhood" must be understood according to the meaning that is proposed by Kevin Kelly : "Life is is an emergent property, contingent upon the organization of inanimate parts but not reducible to them" [...] By stating that the ideal IS must not be designed but grown (through emergence), I include information systems in the large family of (truly) complex systems. Kevin's Kelly analyses leads us to think that the "satisfactory behavior" of complex systems (in the case of IS, this would be the quality of service - availability and performance) is precisely an emerging property, at the global system level, and not a feature that would be built at the component level. In that sense, the ideal IS is a "vivisystem" which blends properties that are built intentionally (for instance, through the architecture of the system) and properties that emerge through self-regulation and self-adptation to the environment.

2. Objectives of this Blog

This blog has three main objectives:

• Act as an "idea workbench" (as for most blogs of the same kind) : improve the depth of my own analysis (though writing) and expose my thoughts to early criticism.
• Create a network of people (who share similar interests) and bibliographic references.
• Develop a unified theory of high avalaiblity / high efficiency / highly adaptable information systems with a practical roamap.

This last point about "practicality" is worth a remark. There is a tension between an "Artificial Life Theory" perspective and the "Adaptative Middleware Experimentation" perspective. One may wonder if I see my own thinking as a philosopher's pastime ... or as the resolution of a CIO practical issue. This would require a lengthy debate, I will simply say that I believe that both a "science-fiction" and a "computational experiment" twists are necessary to achieve success.


3. Methods

I plan to use this blog in a way that is similar to my other blog on organizational architecture:

1. share bibliography : post book reviews and ask for further readings.
2. share thoughts, once I am ready to formulate them.
3. share the results of computational experiments. I plan to use computer simulation to explore some the ideas, as I did for the work on OAI.

I decided to write this blog in English, because most of my bibliographic references are written by Americans. The topics that are mentionned here were born in the US and the likelyhood of joining a thought-network with relevant contributors is much higher if I use an intenational language (a litle bit of provocation here :)). However, comments posted in French are welcome !

One may ask if there exists a relationship with my other blog (http://organisationarchitecture.blogspot.com/). The simple answer is negative: there are no links but the common use of simulation tools. At a "far, far level" a company may be seen as a distributed information system, thus a few connections may be drawn in the future.