OFFICE AUTOMATION :: for Smooth Operations

"A first step towards the application of computers to data processing problem arising in the routine paper-work operations of the IIT was taken with the preparation of programmes to process and prepare grade reports. Not only jobs can be done with greater speed and accuracy in this manner, but it is also possible to do a far more efficient job". These lines from a report for the year 1964-64, mark the beginning of the use of computers in the day-to-day functioning of IIT Kanpur.

The use of computers in the offices at the Institute has come a long way from programs written in FORTRAN running on the IBM 1620 computer to today's heterogeneous client/server systems on a variety of hardware and database platforms. IIT Kanpur now has a full-fledged Office Automation Cell to formally address the continuous development and maintenance of the software required for the smooth functioning of its various offices.

The Growth

The data processing software at IIT Kanpur went through several phases of technology adaptation and rewriting. The first set of applications were written in FORTRAN. Around the mid 70's, these were converted to COBOL. By 1979, all the data processing software was in COBOL and an autonomous division, called the Data Processing Cell was created to look after this work. By 1988, dbase entered the picture and most of the functionality (and some of the COBOL programs) was rewritten in dbase. In 1991, it was decided to develop an institute-wide integrated data processing environment and an external software company was hired to do the development. A software contract was awarded in 1991. About two years later, midway into the total deliverables, the contractor abandoned the project, paid up the penalties and walked out! IIT Kanpur continued the development with an in-house team of programmers and completed most of the originally envisaged targets.

The Move

The Institute took stock of the status of automation in 1997 with an idea of enhancing its scope and functionality. It was quickly realised that there was a large amount of software on an ill- supported software platform (Ingres) and it had become increasingly difficult to maintain it. Also, the software, developed in Ingres would be difficult to modify or enhance, as there were very few trained lngres programmers in the market. In India, the database segment had turned to Oracle! And the need of the day seemed to be a client/server version with internet browser front ends. Today, with PCs on the desks of every faculty member and in most of the offices in the Institute, it is possible to think of a large scale work flow automation as well. But the first step would be to port the existing set of applications onto a stable and well supported database environment and a good application development tool. After considerable evaluation, the automation group took a decision to use the Oracle, Designer/2000 and Developer/2000 suite. A major consideration, apart from the fact that this seem to be a market favourite right now, is that the Institute already has considerable expertise and investment in Oracle - the Library Automation package on iit-KLAS, was developed by IIT Kanpur on Oracle.

So a re-engineering project was started with the express intention of porting all the functionality on to the Oracle platform. Re-engineering tools for this task are few and expensive. There are no well known methods for estimating the re-engineering effort. Also, it is essential to have a clearer idea of the complexity of the problem. So a small module was put through the paces to measure the likely effort on converting the existing Ingres software onto Oracle and to come up with a re-engineering methodology. The measurements predicted an overall effort of 250 person months for porting the full functionality. Questions came up on how the Institute should go about this work? Should the work be contracted to an outside organisation? Or should it be done in-house? Based on the past experience and the expenses involved in a contracting out, the contract out model was ruled out; it was decided that the porting/development will be done in-house. The next question that came up was that although the Institute does definitely have the programming competence, does it also have the project management expertise to handle such a large programming problem? And again, as a confidence/competence building/testing exercise, a pilot project was started with the goal of porting the core functionality onto Oracle. In this pilot project, four modules, namely, Personnel Management, Payroll, Provident Fund and Income Tax, will be re-engineered onto an Oracle platform. A team of 6 full-time programmers, 6 student programmers and a full-tirne project manager have been put together for this. This project will run for a year and will serve as a benchmark for the total conversion program.

Some Lessons

1. The changing technologies demand a continuous rewriting of the automation software. At IIT Kanpur the first phase of automation was in FORTRAN. It lasted about 7 years. The second phase was in COBOL (16 years); the third phase was in dbase (4 years), and the next phase was on Ingres (8 years).

2. Each phase involved revamping not only the software but the hardware set up as well. Often this total cost to recast the total solution into new platforms, is not kept in mind when going for computerisation.

3. Each of the rewrites enhanced the scope and functionality of the software and re-engineered some business processes as well. In that sense the cost of migration may be worthwhile.

4. The only attempt to hire an outside agency for software development at IIT Kanpur failed. But, there was considerable success in in-house development. This is strange! It is a wonder why a professional, competent and commercial organisation was unable to deliver the goods. The in-house teams, which are often run in thesis mode (like the supervision of an M.Tech. thesis - not too much incentive/punishment/ management strategy) seem to do better. One possible reason could be that the software development model that an outside agency needs to adopt for such work - complete specification, design, code, test, deliver - is not suitable for academic institutes. The simple reason being that one can never get the users (mainly of the academic kind) to sit down and write all the requirements once. Such institutes are better handled through an incremental development model.

5. Many crucial decisions, like choosing the software platform, need not be based on technology issues alone. Ingres was chosen in 1991 since the quotation for Ingres-based software was the lowest. The reason for going to Oracle now is the in-house presence of Oracle expertise.

6. A considerable percentage of the developed functionality doesn't get used in the final analysis. At development time, the user comes up with a large set of requirements which eventually won't get used or are rarely used. At IIT Kanpur, about 20% of originally specified requirements are not used.

Finally ...

What any software is able to deliver, seems to be continuously trailing behind what the user wants. This is not necessarily a result of incomplete analysis at development, or changing business rules after deployment, but often is a result of the rapidly changing technologies. In automation, it is the web-centred workflow that is mandatory today. Will it be speech tomorrow?

For more information, contact

Professor T V Prabhakar

Coordinator, Office Automation

Department of Computer Science & Engineering

IIT Kanpur, Kanpur 208016

Telephone: (0512) 597618

e-mail: tvp@iitk.ac.in

[back] [next]