E&P Business Objects – some basics (April 1997)

Nigel Goodwin of Essence Associates and a leading proponent of Business Objects offers some words of explanation – and caution – on this hot topic.

As a relatively immature profession, the IT industry is in a better position than most to create a language whose purpose is obsfucation and confusion. Some of the buzz words widely used by those selling and purchasing software, but which are almost meaningless without some further explanation, are client server, fourth generation, data warehouse, database and last but not least, object. It is not surprising that a simple question such as 'what is an object?' can cause great discomfort in the responder - if translated into 'what is a thing?', most philosophers would fail to give a simple, brief, all-embracing response, because the term itself is heavily overloaded. At its simplest level, an "object" is a "thing" - anything. However, IT professionals fear they may be held in ridicule if they refer to, for example, C++ as a thing-oriented language, so they substitute the word "object" instead. "Things" are nouns. "Walking" is not itself an object, it is an activity - something which happens in time and space, which changes the state of something. It is a possible behaviour of a person object. "Things" have information about them. Indeed, whenever we talk about information, we need to identify the thing the information is about. In data model terms, the thing is the entity, the information is the attributes. In many cases, information is about more than one thing - a salary is information about both a person thing and a company thing. A person’s name is not itself an object - it is information about a person object. In the IT world, the term "object" generally refers to the thing itself (the person), the information about the thing (the person’s name) and the behaviours of the thing (a person can walk). Below are some examples of the application of these concepts.

This concerns the way in which, in interactive graphics editing, a graphical object is first selected, and then an action is performed. For example, in a drawing package, a symbol (such as a rectangle) is selected using the mouse. Then an action is chosen (delete, move, resize, change fill colour, change line thickness etc.). This contrasts with a more conventional command interface (such as DOS) where, for example, an action is chosen (RENAME) and then a file object is selected. This change from verb - noun to noun - verb has, for most of us, become completely intuitive when dealing with simple graphics editing. Whether the style is appropriate in, for example, interactive log analysis is more open. Is it intuitive to first select a log and a log depth, and then select what action is to be performed (depth shift, interpolate, change value, scale, shift)? Or is it more intuitive to first select that a depth shifting process is going to take place, and then select the log to be shifted? Most interactive log analysis products adopt a semi-object oriented user interface.

Object oriented languages in principle enable libraries of reusable objects to be maintained. Of course, there have been libraries of reusable code available for decades, be it from algorithm specialists such as NAG or a programmer's personal toolkit. Design concepts such as coupling and cohesion have guided programmers into writing code which has a greater chance of widespread applicability. Reusable code is much more of a design and management issue than a programming issue.

C++ was invented to support object-oriented programming. Object-oriented programming takes the best of the ideas embodied in structured programming, and combines them with powerful new concepts that allow you to organise your programs in a different way. A program is decomposed into subgroups, which combine the program code and the data in a tightly coupled object. There are three important concepts:

Encapsulation, a mechanism to bind together the code and the data into a "black box" which is protected from outside interference. A well designed FORTRAN program can similarly bind together code and data, but there is no protection mechanism, and the design tends to become abused over time.

Polymorphism, whereby one interface can achieve multiple methods, depending on the type of data. For example, a single function "add" can be used for integers, reals, imaginary numbers, and maybe even characters (where "add" is treated as a concatenation). Polymorphism tends to reduce program complexity, by eliminating multiple interfaces to very similar functions.

Inheritance, whereby one object can acquire the properties of another. An object can be a special case of another object, in which case it can have particular additional behaviour. For example, in a map drawing package, all graphical objects can be moved, changed colour, scaled etc. A road object has all these general properties, but also it may have the property that it can be linked to a route database, and be presented in flashing colours when selected as part of the best route. Inheritance again reduces complexity and programming effort, because all the basic graphical manipulation code has only to be programmed once for all graphical objects.

It can be misleading to discuss database management system technology in terms of 'relational' or 'object'. It is better to think of it in terms of 2nd and 3rd generation. 2nd generation databases were implemented using relational technology (following Codd and Date's 12 rules for relational databases). At a similar time, 2nd generation object databases were being developed, arising out of the need for persistent C++ structures. The database world is now moving towards 3rd generation systems. It is widely accepted, by both the 2nd generation DBMS vendors and many sectors of industry (both commercial and technical), that 2nd generation relational or object databases do not fully satisfy business requirements, although they were a major advance on previous 1st generation systems.

Three of the major technical limitations with 2nd generation relational and object databases, which have important business consequences in the E&P industry and all other industries, are (and these address both the data model and the database implementation):

complex data types

multiple inheritance

query language

The business consequences which are impacted by these technical issues are: 'can I store my business data at all?', and 'even if I can store it, can I model my business satisfactorily, and can my application development and maintenance be done effectively?'.

A 2nd generation relational database cannot store E&P data effectively at all; nobody seriously stores log data in a 2nd generation relational table. If log data is stored at all, it is stored in object extensions to 2nd generation relational databases. A database which includes object extensions to 2nd generation relational databases is essential. Such databases have been available for some time - some RDBMS databases include functionality to store log data intelligently, and allow retrieval of individual depths. Other RDBMS's have implemented fewer object features, and have to store log data as complete unintelligent BLOBS (merely a sequence of bits with no structure).

Regarding the query language, it is accepted that an SQL - based query language is essential for application development as well as for end-user access. DBMS vendors, both relational and object, have been, and will continue to, implement the necessary features to overcome the limitations in 2nd generation DBMS's. In particular, DBMS vendors from a relational background have been implementing object features, and DBMS vendors from an object background have been implementing features commonly found in 2nd generation relational DBMS's (such as query languages and transactions).

In this sense, current commercial DBMS's such as Oracle, Sybase, Informix, DB2 etc., are not pure relational. They historically come from a 2nd generation relational background, but they are moving, some faster than others, towards a 3rd generation hybrid technology. 2nd generation relational databases are history.

RDBMS vendors believe they can offer a relatively smooth path towards 3rd generation hybrid databases. New SQL standards, such as SQL3 and SQL/MM, integrate most of the beneficial object-oriented features into an existing relational query language as follows;

Distributed objects. Initiatives such as CORBA (Common Object Request Broker Architecture) deal with the needs to manage objects which are physically distributed across a network. This becomes relevant when two people working on different work stations want to communicate their interpretations dynamically - if a well marker is moved by one person, it also moves on other workstations.

Business objects (for programmers). These are formal definitions of things with their associated data, and the behaviour of the thing. For example, a thing might be a well log trace. It has data (a log name, a set of values), and behaviour (it can be deleted, changed, resampled, displayed as a log curve, a cross plot, a histogram or depth shifted). During the design stage of software development, all data objects and behaviours would be defined. These formal definitions will probably be written using a formal language, understandable by IT specialists.

Business objects (for analysis). These are informal descriptions of the things used by the business, described in terms understandable to business practitioners. The information about these things can be mapped to formal data models if desired. These business objects can be regarded as data footprints - the footprint of an application, or the footprint of a data exchange file. In many cases, the business objects can also be related to documents - a document is a business object plus the presentation layout of that business object. These informal business objects are very useful when performing business or system analysis, or business process reengineering, as they help identify the information flows and the opportunities for greater effectiveness, either through organisational/cultural change or through better utilisation of information technology. In business modelling , the business objects are linked to the business activities which use or create them. Example of these business objects are: well log, production rates, material shipping order, electrical line index, share register. Examples of such business objects, covering the whole E&P lifecycle, may be found at: http://www.essence.co.uk/essence/

Which of the above aspects of objects need concern the end user? There have been conferences devoted to the business benefits of objects, but this is almost always restricted to business benefits to software developers, not end users. The user interface issues mentioned earlier are familiar to workstation users. While the strictly programming aspects actually have no direct implications for users, they may lead to faster, more reliable implementations, with better user interface features. The database issue will enable better control of E&P data, and reduce the proliferation of unmanaged data files (as its name implies, a database management system is about the management of data, not just storage of data).

Distributed objects may have longer term consequences for the ways in which people work together, but introduces a whole new set of user interface design decisions. Business objects, inasmuch as they facilitate clarity and hence improved communication between users and IT professionals, may have as much an overall business impact as any of the other aspects. It will mean that when a log analysis package says it can handle well header information, we can have a common agreement on what well header information really is. Or if a design contractor hands over to operations an ‘equipment list’, we know what we are getting, and how it relates to other business objects such as Piping and Instrumentation Diagrams (P&ID’s). Through agreed common definitions of E&P business objects, there will be a lingua franca, understandable to end users, which can be mapped to standard data models, such as POSC’s Epicentre, which is a lingua franca understandable to data model specialists.