Sealion Syndrom

Paul Perez, London 01/09/06 paul.perez@pymma.com

Preamble:

The old books often contain a big wisdom. In one of the volumes of the Talmud of Babylon (finished towards the year 500), There is a question of an animal named "kelev a yam" which translates roughly to "dog of sea". In fact, the description given by the talmud resembles more and makes us think more of the "sea lion".

The Question asked: The "sea lion" is he an animal of the land or an animal of the sea?

Answer given by the sages of the talmud: "it is a land animal".

Why then?.

Answer: because the sea lion takes refuge on the land when a predator pursues it.

Objection: That is true, but he spends a very big part of the time in the sea or on the oceanfront. In fact, he is on land for a very small part of his life. So how can we consider him like a land animal?

Answer of the sages: When a man or an animal is under pressure or in danger, where he goes to take refuge, determines what he is. Example: a person in a big danger will aim to take refuge near their family in their native country. It is who they are!

I repeated this story of the sea lion to illustrate what happened recently with one of our customers. For several years, our customer made an important effort to evolve their computer system towards a sufficiently flexible architecture to respond to the needs of their marketing and commercial services. For several years now, all the developments were based on professional components. A number of important components had been defined and implemented. Teams specialised in the management and the maintenance of these components were created. In brief, all the technical specifications talked only of components. It became the pride of the companies architects and the Director of Information Systems.

However, a recent demand of the marketing service allowed us to measure how superficial the adoption of these technologies in the development teams had been. For several years the company possessed a quotation system for the benefits passed on to the customers and the partners. Following decisions taken in high places, this quotation system needed to change in depth. Technically the modification didn't have anything extraordinary. It allowed the marketing department to be more flexible and more precise at the time of quoting the benefits. I estimated the necessary time for the development of this modification to be maximum of a few working days including the unit tests.

So, what's so special here? The point of interest of this modification is that it nearly impacted on the entire set of applications of the company. To give an idea of the work effort involved, it is worth knowing that a technical team of 15 people had been enrolled to do nothing but write a feasibility report. We therefore had the possibility at this point to validate the capacity of the architecture to adapt to new specifications on a big scale. In another interesting element, the marketing service, the supporter of the project, asked what modifications could be achieved in the relative short term. It implied a decision of GO or NOGO to a short deadline. Two months were given for the technical team to produce a feasibility survey. After this too brief a period, a document of about a hundred pages was produced. We were asked to study the document from an architecture point of view.

After a first reading of the document, we had an interesting surprise at the approach taken from the architects and developers at the time of their impact analysis. We had assumed before reading this document, that a Top-Down approach for the specification of the business processes would have been undertaken so that the components would be in the center of this survey. Well, in fact, this was not at all the case! :-(.

The starting point of the analysis was... the database. Knowing the tables and the procedures stocked enabled a quotation, and with the help of the research function of eclipse, a Bottom-Up approach was then used. Gradually, step by step, a number of important components that would be impacted were discovered. While knowing the stocked procedures, it is possible to recover the interface components with the database, while knowing the interface components it is possible to discover which components are calling them etc etc...

Were all the components discovered? Were all the impacts analysed? With more than a million lines of code, I will let you try to imagine the work that it represents and the rate of uncertainty that it generates.

I now return to our story of the « Sea Lion ». A thing is sure, the notion of a component was not yet fully understood or assimilated by our customer. As the sea lion heads towards land if there is panic, the programmers in stress go to what seems natural and protective to them: "the database". Reassure yourselves that in all companies there is more or less the same thing, there is a technology that dominates. Among some customers, it is the mainframe that serves as the haven of peace, where there could be a problem of a migration to consider or a development on the mainframe. At another it is a J2EE server.

And in your place, which one is it?

If you are the director of information systems or responsible for a service then this simple test will allow you to locate the peace haven of your teams.

Decidedly, there is a lot of wisdom in the old books!