Organisations involved in applications development and building scalable enterprise systems are faced with the problem of selecting compatible technologies. This is where the challenge lies, writes Dr R Srinivasan

WE have mentioned in one of the earlier articles that in any engineering discipline the most important aspect to be taken care of is the decision of the architecture of the end-product under development. Software engineering is in no way an exception to this. We are now in the era of networks; whether it is an intranet or Internet, the transactions and even development of a software project take place through the Net. Moreover, we make use of different types of applications developed by different organisations spread across the world, employing the most successful object technologies. This has lead us to the scenario of Distributed Object Technology (DOT) where each application developer prefers his own language like C++, Java, Small Talk, etc. At the same time we also have legacy applications developed in COBOL, C, etc.

The vital requirement under this scenario is the pressing need for the applications under these languages and platforms to interoperate with each other so that a user sitting in front of his terminal on the network gets his job done with seamless integration of all these applications. This is the typical case of an enterprise system with a multitude of applications on different hardware and software platforms handled by many users across the globe. So the success of the enterprise applications lies mainly in the selection of the appropriate middleware architecture which would provide the needed interoperability under the Distributed Object Technology.

The problem normally encountered in those organisations which are involved in applications development as well as in building scalable enterprise systems, is the selection of compatible technologies. This is where the challenge lies, because selection of the technology may depend on the way the organisation perceives it. William Brown mentions that there may be at least three different options for the organisation. One of them may be that the organisation might have decided to have a uniform and single architecture. Second option is the decision of the project team, as and when a new project comes for development. The most difficult option is the one dictated by the customer. All the three options have some problem or the other; it may not be possible to integrate all types of technologies on the corporate architecture under the first one. The project team will resort to deciding the architecture based on its experience and skills. This is not a good alternative at all because the more the number of projects, the worse will it be to face a spectrum of independent architectures. Customer-driven architecture is normally from his view point towards his advantages to fall in his line of business and not that of the organisation. The ultimate result of adopting any one of these options will lead to arriving at the correct solution to build enterprise systems.

This kind of indecisiveness in selecting the appropriate technology for integrating various applications in an enterprise will lead to an antipattern called, "Distributed Disaster AntiPattern". Under this situation, incompatible programming languages in the environment of Distributed Object Technology will have only restricted applicability of the architecture to the problem on hand and will lead to technical failures. Architecture having been decided in a mandatory manner at the planning stage itself, technical failures arising at a later time in the life cycle cannot be amended and may even warrant a revision of the architecture.

What is the refactored solution for handling this antipattern? In order to deliver a scalable enterprise solution, the organisation should seriously take into account the approach of having flexibility in deciding the architecture, namely, the selection and implementation of an architecture must be managed both at the project level as well the corporate and product level. The important steps to achieve this goal are to have a good planning of the architecture, follow a thorough schedule in planning, adhere to architectural standards and come up with a scheme for controlling it. The scope and use of the types of languages to be supported must be spelt out in the planning stage. There should also be very intensive reviews of the architecture, to be approved only after certifying through proof of concept activities. In order to take care of actions like proof of concept activities, experts in developing enterprise systems advocate that it is mandatory to develop a prototype so that software requirement specifications and the code are tested sufficiently. As mentioned by Brown, "otherwise the architecture is no more than a theoretical exercise".

  ( To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)