A trip to the moon, an objective view of E&P computing (not) and a plea for a 'BOBM'. (December 1997)

PDM’s editor Neil McNaughton discusses the difference between entertainment and invention and wonders in which camp emerging business objects should be considered. He concludes that although ‘business benefits’ are cited in abundance, a real business model for the deployment of this technology is conspicuously absent.

This month I'd like to ask the question "how do you evaluate the promises of jam tomorrow that various technologies appear to make?" The starting point for this quest is the observation that when Jules Verne wrote his book "De la Terre à la Lune" he was writing an entertainment, and that although he pre-dated NASA and Neil Armstrong by 104 years, he cannot really be said to have stolen their thunder. I mean you do not "invent" something by just writing about it. If you do not agree with this then I must be a pretty clever chap, because I have just dreamed up a system of oil exploration that uses robots crawling around on the seabed recording, processing and interpreting away. When they directly detect hydrocarbons they whip out a laser beam and get drilling. The fused wall of the borehole neatly avoids the need for pipe and specialized go-bots trundle down logging and perforating promising zones using gourmet sniffer RFT’s to "taste" the fluids before micro - nuking in the main perfs. Production is achieved by satellite using the "beam me up Scotty" technology familiar to Trekkies all over the world.

I could go on but you get the point. In reality, many IT presentations today are a mixture of fantasy and reality as we all know. Along with the rest of the software industry we are as likely to hear descriptions of vaporware, designed to spread fear, uncertainty and doubt (FUD) in the minds of buyers and competitors alike as to have a vendor appear with a product that just works! New technologies, from the increasingly integrated but isolated environments that vendors are offering, to the futuristic object-oriented environments promises of this month's lead are all "marketed" long before they are up and running.

What is often unsaid is the time and effort required before one or other of these technologies will bear fruit. In the commercial world mission-critical aspects of the vaporware may be overlooked in the current version of the software, and a wait of many years may be in store before the required functionality is there. Elsewhere - in the "open standards" environment, the initial specifications are so loosely drawn up that it may be quite hard to determine when the job has been done. Often the deliverables of one project turn into the specifications of the next, with all participants living and working in a never-never land in so far as producing anything workable goes. But most are well aware of these issues and have got used to expecting less from the product than the salesman promises, or only using a tiny subset of what the standardization organization comes up with.

I'd like now to add another dimension to the question, one that did not exist when NASA was developing the Saturn V, the business model. NASA's business model was simple to non existent: send a man to the moon, pay for it with tax dollars. Because this was later deemed not to be politically correct, history tacked on "invent the transistor and discover Teflon" but I digress. The Apollo program was without a recognizable business model, but no-one would get away with this today. Nowadays we need to show business benefits, cost savings and jump through hoops before we get a cent for a new project. But while we offer jam tomorrow in the form of interoperability and costs savings and so on, these are really only anticipated business benefits and are never developed into a true business model. The assumption is that is it is good technically, then the business will follow.

In the IT world at large there is a "standards" war raging between the Microsoft and Java camps. References to "bloatware" in the context of Java and objects generally refer to Microsoft's hegemony and products such as MS Word. But these references seem misplaced in E&P. Could the E&P bloatware referred to be applications such as those from our favorite vendors - GeoQuest, Landmark and the like? Surely not, because they are all fully on board the E&P open systems movement aren't they? Without getting bogged down in that, I had better make my point before the turkey gets cold.

Objects are undoubtedly becoming an important aspect of E&P computing and the existence of a reliable underlying E&P business object facility with a standardized interface would allow many more software components to interoperate than is possible today. Also it should be simpler to build more reliable systems with less (or no?) data duplication and which are easier to maintain. But what would this mean for the existing marketplace. Imagine that 2-3 years down the road it is all up and running. What are GeoQuest and Landmark supposed to do with their bloatware? Where does their market share go? Does anyone really believe that the future will be a world of E&P specialists assembling their own applets out of freeware, and that the infrastructure will be maintained by a standards organization? Lets get real and have someone explain - as I say assuming all the technical issues are resolved - how all this is supposed to fit together commercially. Who pays for what, who will own what. We've got business objects, lets have a business object business model - a BOBM please and soon.

Click here to comment on this article

If your browser does not work with the MailTo button, send mail to pdm@the-data-room.com with PDM_V_2.0_199712_3 as the subject.

© Oil IT Journal - all rights reserved.