If, like me, you have at some stage performed an IT role acting as in intermediary between the business user and the programmer you probably realise that more often than not there is a communication ‘gap’ of some sort.

It could be terminology or it could be assumptions about ‘what people know and understand.’ Or maybe a question of familiarity.

The non-technical end user knows their data (or we must assume they do if they have been assigned to talk to the IT people about requirements. Of course, this is not always true …). They will assume that the IT people they are talking to understand their data in just the way that they do themselves.

I would suggest that this is rarely the case.

The IT people will see the problem in an IT light without really having the faintest idea of how the business runs and uses the data fields. If a field has a name and an intended use that is what they expect it to be used for. That the users, since time immemorial, have used it for something else of that it is merely a repository for some information from an an earlier redundant system will, more often than not, be unknow to them.

So things are discussed, questions half form, half presented and half answered and, perhaps six months later, a new report is proudly delivered to a client who has no idea what it is telling him but feels that it is unlikely to be what he thought he was asking for.

The output is never used. 90% of all saftware code ir, apparently, never used, especially reports. (They may be run once to see if they work …)

The 6 month development cycle probably suffers from ‘things moving on’. Heck, in that time I have know of companied being bought and sold several times over with a ‘corporate integration’ in each ownership cycle!

Now, with Monarch as a pro-typing tool IT has the possibility to satisfy immediate demand very early in the request cycle but yet retain control and iteratively develop a pro-forma or prototype solution for their client before deciding whether to move to an integrated coded solution (and all that goes with it including revenue transfer) at a future point.

Protyping can relieve the immediate client/delivery conflict AND ensure that the final coding project, if it comes about, has a complete and working specification (the Monarch solution) against which the coding and testing should be able to delivery very rapidly indeed.

If not, why code at all?

Grant