Enterprise integration of intelligent business objects
What exists?
Silo implementations may have evolved to remain current with technology and business
needs or they may have stagnated under the weight of huge quantities of legacy data or
the pain of having to support old procedural interfaces. For many, the cost of change has
antiquated the implementation and even the content of the data. In most cases, the ability
to add a new attribute field has been easier than the elimination of a field, even though
existing data was not updated with valid values. Fields, which were at some time
important, may still exist, but without consistent quality content. In most instances, silo
implementations require considerable evaluation to determine what the object definition
should really be.
This does not mean existing data is worthless. Quite the contrary, existing data, being
used to make some area of the company more productive, is extremely valuable. Much
of this information, however, may best remain private to the organization that uses it.
Other parts of the information maybe useful across the enterprise.
Implications on Design
How does one design a distributed business object? A first step, not covered here, is
application of the principles of reorganization to define the correct processes. Assuming
this has been done, evaluation of data needs can begin. This evaluation must include a
data dictionary to unambiguously define data content, quality, completeness, and data
types stored. This should also identify useful or needed information, not currently
available. This becomes the metadata definition for moving forward. Where information
can now be calculated, rather than collected, this is still metadata for information,
although algorithmically defined. In a similar vein, where data can be calculated given
sufficient processing power in the future, this fact should be captured for future savings,
once technology advances.
With a fill data dictionary for each area defined, the ability to find redundancy exists. A
full data dictionary would not confuse a logical circuit with a physical circuit, for
instance. Once assimilated, this information is grouped according to category theory into
a unified object. The important step is not to stop here, but rather to then examine which
aspects, both information and behavior, are needed for which parts of the business
process. This allows the definition of the distributed, and obviously denormalized, object
model. In this model, the owner, of each part of the object is defined, as well as those
who need access. For any object, some owner can create and destroy an instance.
However, in a distributed model, this creation and destruction may involve notification
and collaboration with other parts of the object in order to preserve integrity between
defined relationships.
In this model, it is obvious that storage and presentation are separate. This supports the
concept that symbolization can be performed to make the items important to the current
process stand out via exaggeration, color, or other symbology. It also supports the
creation of an object with the behavior needed within the job process. The weight of the
object is minimized for each use. This reduces the 1/0 for the multi-tier distribution of
the objects and provides for modification and creation only for the appropriate individuals
doing a business process where these are needed. In fact, overhead associated with
maintenance of information to support the transaction process is totally avoided where
update is not required.
This approach can be extended to further reduce bandwidth requirements for network
connected users. This does require the separate identification of information always
needed to support a process from information that is either sometimes or rarely needed.
This low need data is not delivered with the object to the web browser, but instead a
proxy defines how to retrieve this information on demand. This proxy approach can
greatly reduce the time to prepare a data set for initial viewing and interaction with a user.
Other "tuning" or performance implementations may involve distribution of the view to a
user first, and then during idle computer cycle and bandwidth periods the shipping of
additional object components and properties.
What does this cost?
Nothing is ever free. Obviously, reduced bandwidth, faster initial response time, and the
other benefits do require some increase in model and processing complexity.
Specifically, the knowledge of how to drive the transaction process to ensure that
updates, and especially deletes, is propagated to all parts of the object. Also having
object components on demand does tend to drive programs to be threaded or spread
across the multiple processors available in an n-tier system. This is typically where you
want your applications to be anyway.
Most multi-tier implementations that exist today have been created to offer three-tier, not
to support the distributed business object. A three-tier implementation in itself may not
offer distributed object capability or even transaction capability. A distributed object
capability does not necessarily have to support a multi-tier processing architecture, but
must have some transaction capability. However, these will have some aspects in
common. The separation of capabilities into clear and distinct parts with well-defined
interfaces is required for each.
Summary
A business object exists to support a business process. Because the needs of each process
are different, obviously the object can, and should differ in behavior and content to be
optimized for these needs. Consideration of this can also lead to implementations that
offer better user performance and reduce bandwidth requirements. The added complexity
to support this follows along the design of the same capability demanded anyway to
support a three-tier environment. Moving to an architecture that supports both aspects
does not complicate the development activity of a system very much beyond support for
only one of the aspects. However, the metadata definition to support distributed business
objects does typically take longer, because of the need for additional data details. This
does not guarantee a better solution. It does however mean that you will know why data
is needed and should support the data and process evolution needed to compete.
