PDM Editorial - Compliance, the Loch Ness Monster! (February 1998)

PDM's editor Neil McNaughton attended a ratherrare event at the POSC London member meeting, a POSC meeting on the old chestnut, or LochNess monster that is 'compliance' (the last was in May 1996!). He wasunderwhelmed by the progress made in what should be a critical area for the standardsorganization.

We had just brainstormed our way through compliance and decided - well I was not very sure what had been decided, the sinking feeling was now accompanied by severe head scratching. This unpleasant state of mind and body came from the realization that it was impossible to come out with a simple statement on what should be done to achieve and monitor compliance. Despite the collective wisdom of the POSC enthusiasts present, it was not even possible to come near to an agreement on what compliance meant. All this against the backdrop of the major vendors claiming that their products are "fully compliant" with POSC's "specifications".

At the PPDM AGM last year a similar discussion took place, but with PPDM management proposing specifications that would make a product PPDM compliant (PDM Vol. 2 N° 11). PPDM's definition of compliance was based on metrics such as the number of "pure" PPDM tables in a data model. Call it simplistic if you like, but it is a definition. What of POSC? There is not even agreement as to where to start. Recent developments in POSC's board structure make it fairly clear that the idea of standardization at table and row level of a "definitive" implementation of Epicentre is dead. No shrink wrapped Epicentre now - we are now definitely stuck on a higher plane. But where in the multi-tiers of the POSC agenda will the common ground be found. At the DAE level - as originally believed. Or with business objects - and if so with whose? Open Spirit or POSC's. And if it is to be objects - then what will be the granularity of the standard - one could go on questioning but that is not the point. The point is that today, POSC have no idea as to how compliance can be achieved, and without compliance there is no interoperability and without interoperability - there is no raison d'être for POSC.

I'd like to offer a possible explanation for this state of affairs. POSC was set up by big oil companies. They were soon joined by an ever increasing number of software vendors. To the extent that, at this month's London meet, oil company people were outnumbered two to one by vendors. On the corporate plane, there were three times as many software companies as oil companies present. The recent changes in POSC governance largely reflect this demographic change; POSC is fast being taken over by the software vendors. It is therefore not very surprising that the ground rules have changed. That the focus for a vendor is interoperability through a proprietary API - preferably their own.

If I may make a suggestion then POSC needs more vision than is evident in the status quo. If we are to remain within the initial remit of POSC - in other words within the general area of Epicentre, then the only hope for interoperability is in a fully specified DAE with compliance testing of products against this. The workings of the Document Management Alliance (DMA - see article in this issue) would tend to suggest that this is possible if the middleware comes from a major vendor - and although the DMA is not out of the woods, it makes for a credible business model. How would this map across to POSC? Well I'm not sure. What is clearly required is a sequence of actions that will lead to the establishment of specifications, compliance, testing and branding. Without this there really is very little point in continuing. Finally I guess I owe an apology to the software vendors for doubting their claims for POSC compliance. I now realize that you are all "fully compliant"- with nothing. My humblest apologies!