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". Business Object Redefined The business object may be redefined as a digital implementation of a real world item, which contains information and behavior needed to perform a specific task at a specific point in time. Other information and behavior, which also define and comprise this object, may be defined such that the object may assume these properties as needed. Why would someone propose such a definition? Object definitions change over time, as real objects do. Many telecommunication devices could at one time only exist in a central office. Important attributes included a limited temperature operation range and the device heat output per unit of time. They could only operate in a climate-controlled environment. Due to the utilization of integrated circuits and the use of different materials, temperature tolerances have grown and heat production has diminished. This has occurred to such an extent, that for most devices these attributes or properties are no longer of interest. Change within an object, although important, is only one driver for change. Fifteen to twenty years ago attempts were made to have Engineering Models support taxation requirements. Software and procedures to count and measure facilities within tax districts were developed. Due to the large volume of facility data, the complexity of political boundaries, the brute force algorithms deployed, and the speed of 1/0 and processors at the time, this failed. The decision then became one to require Engineers or records people to break conductors into multiple records at political boundaries and insert one or more tax codes into each record. Today, the volume of facilities is much higher and tax boundaries are no less complex. However, better algorithms and processor speeds no longer require this established practice. In spite of the ability to easily do today what failed a decade ago, conductors are still being broken into new features at tax boundaries and "hard coded" with taxation designators. This results in more facility items than need to exist to represent the engineering model. This also requires considerable rework of existing facilities when a tax boundary moves. This creates additional arbitrary data or results in miscoded data, or, more probably, both. The problem of tax boundary to facility data is a good example of why business objects and practices should change over time. Changing data is not itself the greatest reason for the variable and distributed definition of business objects. The most important reason is object size. Original silo implementations were on large computers, mainframes, and mini-computers with attached terminals. These terminals depended on the main computer processing power, even when they contained sufficient memory to store a bit mask for a display or text for a form. The slowest area of processing was then 1/0 or the ability to get the data from a storage device into the processor and to put any changes back to storage. From there, technology advanced to where the distance from the storage to an intelligent terminal, with some processing power, could be increased. The age of client/server was born. Still, the gating factor on performance was 1/0. The size of the feature was still important. As multi-tier architectures become dominant, one factor remains. The ability to provide performance is most affected by 1/0. In this environment, 1/0 includes initial retrieval from permanent storage, bandwidth requirements for communication to an application server, and bandwidth requirements for communication to the client. In spite of tremendous enhancements in processing speed, device controllers, and the speed of storage devices themselves, object size is still an issue. An object, which must be everything to everyone, is obviously much larger than one that serves a single role, at a point in time. This is true as the object relates to 1/0 requirements. In another sense a distributed object is actually larger due to its need to exist in multiple parts, all of which must be maintained with a common access key and the knowledge of how to reach all parts. However, this can be implemented in a manner to not impact 1/0 for time sensitive operations. Technology Today At one time, distributed database was a concept. Today databases, whether relational or object, can deal with an object split across multiple storage mediums and processors. These increasingly can support attributes or properties, which do not fit into a simple data type of the row and column implementations of the past. We have the ability to move to an Aristotle view of an object. What technology is required to support this? The hard part in the support of distributed database was ensuring that all parts of a transaction completed successfully or else none did. Transaction support is an item needed to support distributed business objects today. This is why Java and NT 5.0 both offer transaction capability. Just as separate database vendors offered incompatible distributed algorithms originally before moving to the ability to integrate, so today the language versus operating system implementations are incompatible. In the past, one had to decide whether to use DB2, Oracle, or Sybase as their sole database, if they wanted distributed capability. Today one must decide whether to have distributed objects implemented as DCOM or Java. In the future, language or OS implementations should become more compatible, just as today a distributed database can cross Informix and DB2, for example. 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. | ||
|
|