A Multimedia Interlude

As I said earlier, this blog is based on a presentation that relied heavily on the use of multimedia, and every now and then I will try to give an insight into the 'live' show. At this point in the proceedings I would put up the following slide;

This shows how the Gartner Group views the topology of client server systems. As you can see the model splits applications into presentation, etc. Which is all very well, all very sensible.

But.

I had seen this slide fifty times with fifty different explanations from fifty different marketeers. So, to make a point I used a piece of fun software called Gunmouse and fired blanks at the screen whilst my assistant (the lovely Bob (Richards)!) clicked his mouse and a few seconds later this was the result;

By the way, the blood from the bullet holes ran down the slide.

Star Wars

During the failure of this system patients would wait hours for an ambulance to turn up, and in some cases they just did not turn up at all. Not only did I consider what users really want from their systems during this time but I also thought about the term 'mission critical system' in a new light and wondered;

'would you like your life to depend on your systems?'

And then I thought;

'would you like everyone's life to depend on your systems?'

....and it was at this point that I felt very glad that Ronald Reagan’s 'star wars' initiative had been abandoned.

Mission Critical?

Why the X-rays? Well, the X-ray shows my lungs as they are today and how they were at 11:00 PM one Saturday night in October a few years ago. I was having dinner with some friends and at midnight started coughing, the cough became worse and was accompanied by severe chest pains. By three in the morning I was so bad that a doctor had to be called out (this was the UK for you doubting Thomas's), an ambulance was called and I was carried down stairs on a stretcher and given oxygen.

Whilst in the ambulance I never once thought 'I wonder if ambulance was despatched by a well architected system?' In fact, I wonder if any users anywhere really cares about the architecture of the system he uses, nor should he.

In the hospital I was diagnosed as having 'raging phenomena', put in an oxygen mask and given massive doses of drugs. I was later told that I was lucky I was taken to hospital so quickly. And I was lucky because around this time one of the biggest ambulance services in England had recently tried to install a new system ..... and it had failed spectacularly. This is what the press said about it;

Extreme Personalisation

All very interesting Terence, but what is the point of all this?

The point is ....that I wanted to go one better than John Thalhuber's presentations, should I include photographs of myself, of my wife, or my children?

No, none of these, I included an X-ray of my lungs;

Thalhuber Koan

I used to go see presentations and product updates for a particular 4GL called Mapper, these were given by a technical expert John Thalhuber, who was involved in the development of the product but who helped out the marketing function from time to time. During the years he had been giving the presentations, I had been to see many of them, and they were very, very good. John made lots of use colour, pictures, and stereo music, all written in the particular 4GL and running on a PC. One of his techniques was to include photographs of his daughters, the Thalhuber girls, to explain various features and concepts, I watched those girls grow up.

One example of the Thalhuber girls in action was when John showed a photograph of his daughters with a monitor covered in jelly and cream on it .....a gooey interface!

Another of John's presentations was a 25th anniversary in which he looked back to the accompaniment of pop records of the time. Unfortunately, he explained that he had dropped his portable PC on the way in and instead of going back 25 years it became stuck in the 70's playing;

night fe-ver night fe-ver night fe-ver night fe-ver

...by the Bee Gee's. This was obviously an error as no one would want to be stuck in that decade.

A Software Cost Estimating Game

Here's a game you can all play, I wouldn't say its going to be great fun but you may learn what some of the real costs of different technologies are, and they say that we learn from play. This is what you do;

STEP 1

Find a specification, preferably a big one, it would be excellent if it was one that you had actually build and had metrics on, but any will do. Having found your specification ..... blow the dust off of it .... isn't it amazing how specifications get put in out of the way places to gather dust? Well, having read quite a few I'm surprised they are kept at all, but all that money in creating the document......

STEP 2

Find a software house with ability to develop software using two different technologies you are interested in using, perhaps even ‘traditionalcentric’.

Now come on Terry, you can't use made up words like 'traditionalcentric', after all they stand no chance whatsoever of getting through the spelling checker!

««« INTERRUPT

Of course these days some people and technologies are described as 'dinosaurs', but then 'Jurassic Park' was about dinosaurs and went on to become one of the most popular film ever made.... and they

may be in museums, but they are usually the most popular attraction in there.

If you can't find a single organisation who can produce the systems in both ways, then you may have to find two separate companies - one for each method. In fact you could use as many as are willing to co-operate.

STEP 3

Ask the software house (or houses) to provide fixed price quotes for the two developments, clearly saying what is included and what is not..

Stand back in amazement!

QUESTION; Is this game being unfair to software houses? No, because some of you will end up accepting the quotes you have been given because its more cost effective and less risky than doing it yourself. Which leads you to wonder why you do anything in-house.

Productivity?

One of the biggest issues in IT, and it is not simply a cost argument, is that of productivity, how important it is, why it is important, the business pressures, the pounds and dollars, and how we should always strive for it.

So, what is happening? Well, under current conditions it appears that we are moving backwards from 4GL's through to 3GL, and more likely, 2GL levels of productivity.

(But I could be wrong, I was once)

Distributed Data & Software - blah, blah, blah

For the last thirty years systems people have been concerned with the integrity of data. How to ensure that once we have captured something we do not allow it to be corrupted, inadvertently deleted, etc. So how do you achieve the same objective when the data is spread around, when the users are spread around, when the software is made up from disparate elements, and when it is difficult to see the wood for the twigs for the branches for the trees for the woods for the forests for continents for the Earth for the Universe. OK, I exaggerate, so shoot me.

Then there's the question of controlling the correct versions of software. Making sure that the correct versions are in use in all devices at all times. New releases of software being a especially entertaining but again, if you are just building the software then somebody else can handle this can't they? As you move through development and production running you not only need to know what the current configuration is but what it was at a certain time and any planned future changes.

Now you did not believe that you get away forever from any responsibility did you? I am afraid that designing and building the recovery into the system has to be your responsibility. But do not worry, I am absolutely sure that all the components will fit together perfectly and deliver you transaction level recovery just the way you used to know it.

Ideally, the user should only be required to sign onto the system once, no matter how many layers or levels are between him and the data and applications he wants to get to.

We are nearly there, that was not so bad was it? Only one more hurdle to go. All we have to do now is to test this system! Oh, my god!

Issues with Client/Server for Example

It is difficult to pin down the issues with client/server when no one really knew what it really is anyway. However, whilst the following comments may not apply in every single case, they certainly help to focus the mind.

All the issues revolve around multiplicity. Multiple software products, multiple hardware platforms, multiple development environments, multiple run time environments, and consequently multiple teams. Not only can all this result in multiple teams working on multiple products, it can also throw together teams who do not want to work together.

The basic problem with client/server was concerned with integration. Integrating many different components into a working whole. Which is not to say that this is very entertaining, the technical problems will be so many and so various that

1. you will find the task very challenging, and …

2. you will have so many more excuses to use when you are late that you can be very relaxed about the whole exercise.

It is not as if there was a single accepted infrastructure you could use to move forward. In fact you could spend the entire time allocated to developing the system to just choosing what you are going to build it with. Although you may find this idea intellectually interesting it is a well travelled route, the CASE and IPSE (remember Integrated Project Support Environment anybody?) guys have been here before, you will have to look for something else to trailblaze with.

But, relax, you are not on your own here. If you ever managed to build a system pity the poor sod who has to try to manage it. Configuration management is particularly difficult in a client/server system. How do you know where all the disks are? Are they full? Do you need more, and if so where? Like I said, consider yourself lucky.

Remember Client/Server?

"The people were standing all around
at a shotgun wedding here in town" - Roy "C"

First of all I want to make it very clear that Client Server is not a buzz word ....it is two buzz words.

The 'What is In A Name' Koan

By the way; what happened to the phrase 'Master/Slave', and why did we drop it in favour of client/server?

If the press and the guru's are to be believed then everyone was building client server applications, so how is it I didn't know anybody who has one in and working? Every week there were stories about another spectacular failure of client server. I wonder how many there are now?

What is Client/Server Anyway?

In a recent survey the following answers were given to the question 'what is client/server?';

The Addition of LAN's to a Host

Diminishing Role of the Host

Increased End User Computing

Emotional Attachments

I have great difficulty with the concept of being a 'believer' or a 'non-believer' when it is applied to software techniques. Not just to techniques, or languages, or methodologies, or 'concepts', but to certain hardware platforms or operating languages. Can you believe this? Does everything have to be so black and white? Can’t I take the best parts of everything or is it a binary thing?

OO comments that can apply to lots of things really

The real advantage of 00 is when it is applied across multiple projects. Although identifying and objects across a single project is difficult, it surely cannot be an order of magnitude more difficult across multiple projects with multiple teams can it?

Yes it can!

As with most things, there is always more than one way of looking at problems. If the issue is maintenance, which I agree with, then consider this;

Cars become increasingly expensive to maintain as they become older. One option is not to use the car, a more realistic one being to replace it after a time. Of course you could buy an aluminium bodied, highly over engineered auto to last a long time but few people would consider this option. And if 00 leads to easier maintenance, as relational databases were going to, surely this means that we have accepted the fact that it is impossible to once and for all fully specify software before it is initially built. Quick, someone, better go warn the methodologists about this!