Systems Department Number: 005 Date: 08 01 2002 Author: Intag Source: Intag   Coping with the Increasing Complexity   The danger of foolish economies in the Analytical and Design Steps Here we depict some problems arising from the growing e-Systems complexity. The systems modules are now connected in a multiple level n-tier structure not shown here in the sake of simplicity. However, we may distinguish on it the main components of a modern e-system, namely: è which stands for Data Input/ Output Yellow perimeter: the data ring, sometimes a complex network with hundreds of entry/exit ports, and a high traffic of different type of data, different codes, and communicating via different protocols either online or batch, either in synchronous or asynchronous modes. The different modules that defines each application, for instance "Billing", in this example through 4 interconnected modules, each one encapsulated in a universal shell that allows each of them to read/write, import/export, get/send, different type of data. Each module could be built in different systems and programmed in different languages. The communication itself is realized via a sort of "synapses", shown as light green bubbles at both extremes of the data channels that communicate the modules among them. They communicate almost based in the server/client mode, indirectly with bursts of different data, the type of data that handles each module (each synapse handles a specific type of data at a time. If something happens in these extremely complex systems it's very difficult to detect where the system fails unless we may have, for each application and for each procedure of them, a data flow scheme as it's depicted to the right of the figure above. In most cases I would dare to say that without these flow schemes it will be almost impossible to detect the failure's causes. Unfortunately this obliged step of a good design is frequently ignored because foolish "economic reasons". On account of that most actual systems behave like "black boxes". If something happens the support people may identify only the most frequent causes of malfunctioning by accumulated experience at customers expenses. In many cases the decision is to quit the whole box, arguing some appropriate excuse like: "this box is not well suited to cope with such and such type of data and scenario, or it's becoming obsolete, etc". On the contrary, having all the logical mapping of the applications, correlated to the physical units of the real processes: offices, departments, warehouses, factory sections, the failure detection is straightforward. You may design traps to isolate and focuses more and more the failure possible causes. In the figure above we mark encircled in red a failure detected in one of the modules, over a pair of coupled elemental procedures.