Enterprise integration of intelligent business objects
Tom Strickland
I.T. Futurist & Chairman of OpenGIS Telecommunications
SIG
Byers Engineering Company
6285 Barfield Road
Atlanta, Georgia, 30328, USA
Voice 256.430.1718; Fax 256.430.1719
Email: Tom.Strickland@Byers.com
Objects
The term ``object' 'has been defined in many different ways. The Socratic view of an
object is that it is what it is. The view based on an Aristotle definition is that an object is
as it is perceived and used. In the computer world, we have too often followed Socrates
in our treatment of business objects. This was appropriate, because it is easy and
pragmatic. However, Aristotle's definition provides greater flexibility, if this can be
exploited efficiently. In essence, this philosophy says "this may be a table to you, but for
me, at the moment, it is a footstool."
Application
In the world of Telecommunications and Utilities, a business object is typically defined
as a digital implementation of a real world item, used in business operations, such as a
pole, a trench, a switch, service request... created or used in providing service. A
business object also contains information and behavior. This is a good definition, as far
as it goes; but how are these implemented?
In the historical world of computer implementations, islands of automation or silo
implementations existed. In this silo, the model of the object is established to contain the
behavior and data content needed by a single organization. Tremendous quantities of
legacy data exist to support this, typically in procedural definitions, rather than object
oriented. In taking a high level view of an industry, huge amounts of information overlap
are visible. For instance, in telecommunications, both operations and engineering deal
with a circuit. The physical cable is in the accounting database, coded with the
appropriate tax codes so that taxes may be paid. The immediate reaction of a systems
analyst is "this is duplication."
The analyst is correct. However, although some objectives maybe clear, the actions to
take are not obvious. If multiple organizations have individuals who collect and input the
same data, then obviously elimination of this redundant activity will result in cost
savings. It is clear that Engineering creates the proposal to cause a cable to be placed,
defines both where and what it is, and updates this based on communication with
construction. Because of this, someone may suggest Engineering should input all
Accounting and Operations data. As a decision, this adds overhead to Engineering and
may result in poor data reaching the other groups.
It could also be argued that because Planning defines the need for many items prior to
Engineering design, maybe they should input all data. This one is immediately seen as
bogus. Planning works years in advance of the item being placed. A Planner defines that
a device or conductor to offer some level of capacity three years from now should be
placed in the network somewhere close to a location. The item defined must be general
in nature, such that when the decision is made to move to deployment, the current best
specific item, based on cost, availability, and quality, may be used.
Just as a Planner does not deal with details, the needs of the different organizations for
the same item differ. An object may contain Electrical Engineering details. It may
contain Civil or Mechanical Engineering details. It may be abstracted to a logical level
where the individual conductors taken from different spools may be defined as a single
item. Just because a conductor must report how much of it resides in county A versus
county B does not mean it must be broken there for the other uses. These different object
definitions should not be overlooked in a quest for a "unified business object model".
