2001
	By Dr. R. Srinivasan, CTO, iCMG, Bangalore

In an earlier article I have compared a Government to a large "Enterprise" with each one of its department developing their own applications, computerise them and bring out the necessary information required for various categories of users, namely other departments, other governments or for the dissemination to the common man. Application development goes through different processes like system study, evaluation of the study made, design steps, development, testing , porting and maintenance, i.e it has go through the necessary development cycle like any other software product development. I have also indicated that there must be a good co-ordination with every department in the Government in the sense that the applications developed by them should have the provision to interaction so that it will be possible to extract useful information out of this interaction. This is where the care must be taken not only in deciding the Application architecture but also the middleware architecture through which the applications will interact. If every State Government follows this standard methodology, including the Central Government there will be seamless integration of different applications to provide the vital information at finger tips for many like administrators, ministers, corporate people, and above all the common man. Particularly with the government's initiative to set up information Kiosks, the information needed may have to come out of application packages from more than one department or even from more than one government. For example if one has to see his land records, it will come from one department and the tax he has to pay will be from the other department. If he has to get these two together, the applications of the two departments must integrate and give him the necessary information. Another example could be a person wants to buy a flat in Mumbai and tries it through a Kiosk in Bangalore, the Housing Boards of Maharashtra and Karnataka must be integrated to get the information. This may look like a freak example; however it may not be too far to look for this type of requirement in future. Another simple example could be the facility that could be provided to pay online the Electricity and Water Bill at one stroke under "Utility Bill" for which the information from the Water and Sewrage Board and Electricity Department should be integrated for each person in that locality. A sophisticated example could be such that a person holds only one credit card with some identification on it and keying facility in an Automatic Teller Machine, he should be able to access the one which he has keyed in, i.e the concept of "Universal Credit Card". This means that the application packages relevant to each credit card transaction are integrated to one so that the person need not carry multiple credit cards. In all the above examples the system will comprise of Applications developed to a common defacto standard middleware architecture.

This is going to be the technology of the future and e-Governance should implement this methodology. Today, as the Government is racing towards "Digital Economy", its structures should increasingly be made up of interlocking applications, because isolated applications are history. But disparate applications are like building blocks, they have to be put together systematically to create an e-Governance enterprise. After studying the system requirements, the first question that will arise will be the standard to be adopted in Application Development. The trend now is shifting from Object Oriented Analysis and Design into Component-Based -Development (CBD), the main advantage of which is reusability. If the components are developed towards a standard architecture throughout the enterprise, CBD can significantly reduce the cost of development and minimise the time for integration. Another advantage is that one component developed as part of one application may be made use of in the development of another application either within the same department or in another Government. For example the components and applications developed by the Housing board of Maharashtra can be used by Karnataka rather than reinventing the wheels again. Similarly the applications developed by the Information Department of Karnataka can be used by Andra, the only variation will be the type and nature of data that has to be used under the applications. Typical tools that are used in CBD are Microsoft's Component Object Model (COM), Obeject Management Group's Common Object Requester Broker Architecture (CORBA) and Sun Microsystem's Enterprise Java Beans (EJB). Majority of the proprietary component development environments adopt one of these standards for inter component/application communication. As Jason R. Lango of PRL Scotland says, "Components written to same standard utilizing any one of these technologies can easily inter operate in a flexible and scalable environment. Mixing these technologies, however will result in an environment that requires another level of integration". This is a very important observation that has to be taken care of in developing applications under e-Governance. If each department in a State government and the Central Government adopts different technologies, we will be spending more money in integrating them, if we have to bring the concept of One-Net as Singapore has done. We will discuss more about Component Based Development in the next article.