The existing environment –

One of the least thought-about factors in the systems development process is often the existing production environment. In other words, some relatively easy questions are commonly left aside, such as:

• What computers do we have?

• What software do we have?

• What PRODUCTION MIX do we have?

In this article, continuing on the theme of systems development, the author will address the first two questions in brief terms. The third is usually forgotten, that causes an array of problems within organisations.

Like it or not, our system will be required to function in an already existing environment, with all the attendant problems, handicaps and pitfalls. Not to recognise this point amounts to dismissing the constant plethora of issues associated with the technical environment. No doubt, anyone of us would like our system to be born in the best possible environment. For example, we would expect full telecommunications availability.

Human factors are, again, particularly relevant since problems may arise between two computer groups. In fact, we may be tempted to tell other people what they should have done. However, we must accept that we do not:

1. know everything about the current environment;

2. know what constraints may have existed before;

3. have the power to make things change immediately.

Consequently, when complaints are aired we are likely to be directed elsewhere. People may just listen, or we may be told that when our system reaches implementation, the whole environment will have changed. In fact, we should assume that the environment will not change - in any way that will facilitate system implementation.

We should always remember, ladies and gentlemen, that the existing environment includes people and systems. Whatever design we have reached, we must take account of the existing resources, because they will become crucial to the successful operation of the system in the future. If people are only accustomed to, for example, reading totals at the day-end, we had better provide a facility that will similarly organise the system to this end or else be prepared to retrain the people concerned adequately enough, or the system simply will not work.

Maintenance -

The topic of maintenance is often less than appealing to systems developers. We usually look at maintenance as something you have to do, not as something you would like to do. However, once the system is implemented, a maintenance team invariably will be required to update it. Not that I particularly support the idea of having a maintenance representative in the project. In fact, I have never personally used that approach and probably never will. Nevertheless, the company's maintenance needs will have to be considered in the design, coding and documentation of the system. Thorough knowledge on the part of the maintenance team will be necessary, so that the consequences of poor documentation can be understood.

It is important to appreciate the fact that the more we ignore maintenance, the more likely we are to become the maintainers of our own system. Nobody else will really be in a position to undertake major or minor systems surgery.

This problem has in the past been tackled through techniques such as structured programming and systems documentation. However, the best approach is to ensure that the coding and documentation can be understood by people outside the development team, so that they may be able to modify the system where necessary, at some future stage. Empirically, many of us have looked hard at our own programs to work out what we originally intended. So how can we expect someone to understand what we have done if we ourselves have problems and issues deciphering our own work?

This issue has been addressed in many different ways, but I personally feel the worst of all is what is called structured programming. The aim has been to state a series of rules such that anybody reading a program will understand what the code says. However, let us think about this. Programs, historically, were written in assembler. Then somebody invented something that would accept plain, English words, and convert them into machine language. Subsequent developments yielded high-level languages such as FORTRAN and COBOL. Typically, when we look back and read programming lessons of those days, we find that such languages were expected to be easy to code and read. Does such a consideration bear directly on the maintenance problem, whether then or in the future?

No matter how extensive our documentation, no matter how structured our programs, we will still have maintenance problems. We must also ask ourselves if we are building a system that can actually be maintained. The question then becomes: what is a maintainable system?

In my most recent project - and currently ongoing - a decision was reached in automating a system from excel spreadsheets that will, in due course, be fully automated. The cost implications of this decision, given the position of the company, is, in my opinion, a correct one. It avoids the difficulties of being concerned with bottlenecks that commonly arise with off-the-shelf packages and, most people competent with excel, will at least be able to systematically flow-chart the links. In this instance, documenting the procedural processes of maintenance will be minimal because excel works from a standard set of Microsoft procedures whatever the standard or capability of future users. A terms of reference will always exist either from reference material or from help-topics within the computer itself. In addition, running a company' accounting system under such a format can produce management accounts that are as good as any produced by advanced accounting packages. The principles of how accounts are formulated and produced is, of course, the overarching objective and not how complicated or costly a bought-in system will cost. To many small type organisations have been entrapped to the flavours of sales rhetoric when considering how they should proceed. As a senior management accountant once told me: "The best systems are derived from knowing the business and environment one is in and knowing how to build around those parameters". I endorse those sentiments, to this day.

In the next phase of my writing on 'systems development' the author intends to look specifically at the user and, in trying to understand him. This work will begin with a new post and, during the course of such deliberations, the writer intends to introduce further case studies drawn from personal experiences.