The Perfect Knowledge Work Talk Class (PKWTC) (October 1997)

PDM's editor went to the POSC/Focus Knowledge Work Conference and reports on the state of the art.

As an occasional attendee at POSC meetings I am almost getting used to the successive shocks to the system as you discover that what you thought was important is no longer centre stage, and that some project that had hitherto escaped your attention has actually been consuming hundreds of man-years of effort and is just about to bear fruit. In this edition of PDM we have focused on some parts of POSC's activity which seem important to us, but this is necessarily an idiosyncratic and very incomplete view. It may seem ambitious for PDM as an outsider to try to capture POSC, it is, but what has made us decide to attempt it is that there are many people involved in G&G IT who haven't got a clue as to what POSC is doing. Furthermore if you listen to POSC talks or visit the web page (http://www.posc.org) you tend to get grand claims for POSC benefits (we will save you money, standards are GOOD for you and so on) or incomprehensible technobabble at a much lower level. Where is the overview? Well it is here in your hands, at least a bit, read on.

This year's shock to the system came from seeing POSC from a Norwegian viewpoint. Now all upstream IT-ers know Norway as the home of the first "relational projection" of Epicentre, in PetroBank, but while PetroBank got a brief mention, the focus of activity in this conference was not DISKOS, not even Epicentre, not even POSC, but POSC/CAESAR the construction part of the equation - see separate article. Part of the non-CAESAR part of the conference was devoted to "knowledge work". Now this is a nebulous term, and I have pages of notes taken during the different offerings. I will spare you them and instead try to extract the essential commonality of the knowledge work expose. First though may I offer you the following enigma for your consideration.

Most people working in IT have at some time or another been called upon to write computer code. This is a painstaking task, which even when done badly requires great precision, clarity and an understanding of exactly what one is trying to achieve. When the erstwhile coder moves up the corporate hierarchy, he or she may well be called upon to speak on IT and related issues in conferences - or to write in plain English - in manuals, sales literature and the like - explaining just exactly what their company, organization or product is trying to do. Having listened to some of the self-styled knowledge workers describe their wares one has to wonder - where did the precision go? How can you write detailed instructions to a machine one day, and the next, throw away any notion of clarity, talk in management speak, psycho and technobabble, deviate from the subject, not even have a subject?

I think I have found out the answer to the mystery, it comes from the popular OO programming techniques involving "abstraction". These speakers are actually singing to the same hymn book, it is just that it is an abstraction. This has led me to propose what we ordinary folks would call a knowledge work talk toolkit or template. But since this is too explanatory, we will baptize it the knowledge work talk "class". Now first you must realize that "class" is technobabble for whatever you have in your mind at a given point in time. It could be a subroutine, a data structure, both or something quite different. It is an "abstraction", it doesn't have to mean anything. If you are ever challenged in using these techniques, if you are forced to say what you mean by your class, you can "populate" or instantiate it with whatever seems appropriate then, so you don't need to know what you mean when you actually say it. And seeing as what you say can and will be interpreted differently by the majority of your audience who won't bother to challenge you, you can spread a multiplicity of ideas and warm feelings by using this technique.

I'd like to have a go at a bit of abstraction before your very eyes as it were, and offer you here a totally abstract, class of knowledge work talk the Perfect Knowledge Work Talk Class (PKWTC).

Part one - turn on the top brass by saying what they want to hear cost savings, downsizing, asset team, knowledge work etc. Deprecate - implicitly - the way we used to do business without of course giving examples, let your audience instantiate them for themselves.

Part two - turn on the programmers by ensuring that they will have lots of work, and will be able to use shiny new tools fresh from the box Java, OO, abstraction, code re-use (even if the code hasn't been used once yet, and maybe never will!). Deprecate silly old fools who do things the hard way - again in an abstract way, most of your listeners will be doing it this way anyhow.

Part three (optional) - turn on the users by offering them functionality beyond their wildest dreams such as interoperability. This is optional because there will probably not be any users present; they will all be working!

Part four - conclude with the conclusion you thought of in the first place - do not worry if there is no logical sequence leading up to this, there almost never is! Thus with the same first three sections you might conclude that outsourcing is a good thing, or that we need standards, or the Java is the answer, or business objects etc. Or - and I predict that this will be the new trend - that we should hire more people!

Now all you have to do is to go and populate the class with your own spin - to create an "instance" of the PKWTC. This is of course where the going gets hard. Ultimately, by describing what you are trying to do, by breaking down the specifications, you may find that you are back to writing code, with the precision that we mentioned earlier. Alternatively, you might find, especially if you started with too falutin' or poorly specified instance of the PKW talk, you may well find that what you are trying to do is impossible!