Columns

Manager's View

In the aftermath of the client/server revolution, information technology methods and business development approaches have begun an unmistakable process of convergence. The technology approach of many large information-driven enterprises has embraced object-oriented and component-based development first in two, then three,

Senior business management and business development functions have adopted the notion of value chains1 and strategic business process reengineering2 and redesign. This has led to the abstractions of the business object3, business event, business process, and business (object) model becoming key words in the vocabularies of senior executives and technical architects alike. In many ways, the business object has become the conceptual cornerstone of today's digital enterprise.

However, in the face of the mass appeal of business object-based approaches, several key limitations in current technologies, tools and techniques have become clear. This column discusses the background and practical application of the business object approach while highlighting the areas where current technologies, tools and techniques are insufficient to meet the potential and the promise of business objects.

The value chain

Michael Hammer introduced a generation of senior business management to the concepts of business process reengineering and redesign. Activity Based Costing4 and other approaches have, in conjunction with BPR, increased the importance of simulation and modeling. This contributed to the wide adoption of such methodologies as IDEF5, Object-Oriented Software Engineering (OOSE)6, and Booch's Object-Oriented Analysis and Design (OOA/D)7. OOSE, with its focus on use cases, maps directly to the analysis models of the value chain approach and supports the kind of strategic business development found in classical business process reengineering. As BPR matured and organizations began to apply lessons learned, the interdependence and alignment of business architecture, organizational design and, technology architecture have become key factors in the success or failure of strategic business development initiatives. Business8 and organizational9 design patterns are joining technical design patterns10 to drive integrated enterprise architectures.

Archeology and exploration

Business objects have played a key role in both the archaeology and the exploration inherent in these business analysis and redesign efforts. In the context of archaeology, business object models codify the industry and company-specific knowledge of large organizations. A business object model may provide a map of the key processes, functional roles and values that would normally only be gleaned from oral traditions or through the sifting of paper for the artifacts of past organizations and their processes. Business objects place the role of complex legacy systems into a value chain perspective, drawing focus on their enduring value or highlighting their current cost/benefit position.

As a tool for exploration, business objects, and business object-based middleware, help meet the demands of rapidly changing business climates by codifying the core competencies of an organization while allowing multiple and new value delivery channels and countless combination and recombination opportunities. Business objects provide a common language and body of knowledge for both business and technical professionals by bridging the gap between "tuples, attributes, stacks, & queues" and "costs of goods and services, value chains and market development strategies."

The real world

While business objects are a widely applied conceptual framework, many key components are not supported by current technology, tools, or techniques. The notions of business rules, policies and constraints are often well understood by even the most junior members of a business' operating groups. Business rules embody both the key to an organizations' processes and the lever for new business development initiatives. Despite their central role in business management, neither tools nor techniques have emerged to provide enterprisewide support for the development, distribution and maintenance of business rules for technical systems. Likewise, the notions of roles and relationships have not been addressed by the tools and techniques of the methodologists and consulting firms or by such technologies as workflow management, transaction monitors, object middleware or database management systems.

In part, this is because business objects that model the real world do not actually exist in the real world. They exist in a cyberspace governed by its own unnatural laws. In cyberphysics, a business object may exist in many times and places simultaneously. Time travel, forwards and back, along countless scenarios happens continuously. This has introduced a complexity that has not been addressed by methodologists, tool vendors, or systems development paradigms.

The promised land

While some of the really complex problems have yet to be solved by theoretical physicists, chief architects or other rocket scientists, several very approachable technologies, tools, and techniques have begun to emerge that improve the value and utility of business objects. The ubiquity of IDEF and the Unified Modeling Language11 are providing a universal notation for describing and redesigning business processes and systems alike. The OMG s IDL12 has emerged as a common interface specification method for both new object-oriented systems development and traditional legacy systems integration. The natural evolution of business objects into larger scale business patterns has also started to occur.

These are important initial foundations. But when business development efforts and technical architecture teams are able to describe problems and develop solutions generically as "point of sale", "bill of material", "order entry," and "general ledger" we will have advanced business objects beyond the conceptual cornerstone into the common building block of both technical and business development. In this context, business objects provide a unified model for both technical and business architecture.

John Gidman is a vice president at State Street, a Boston-based financial services firm. He is an organizing member of the OMG's Business Object Management special interest group. Mr. Gidman can be reached by E-mail at [email protected].

FOOTNOTES

  1. Porter, M., Competitive Advantage, Free Press, New York, 1985
  2. Hammer, M., Champy, J., Reengineering the Corporation, Harper Business, New York, NY, 1993
  3. OMG, Business Application Architecture, White Paper, Framingham, MA, 1995
  4. Brimson, J., Activity Accounting, John Wiley & Sons, New York, 1991
  5. US DOD, Integrated Computer-Aided Manufacturing (ICAM) Definition process modeling methodology
  6. Jacobson, I., et al, Object Oriented Software Engineering,Addison-Wesley, NY, 1992
  7. Booch, G., Object Oriented Analysis and Design, Addison-Wesley, NY, 1994
  8. Coad, P., et al, Object Models, Yourdon Press, NY, 1995
  9. Coplien, J., et al, Pattern Languages of Program Design 2, Addison-Wesley, NY, 1996
  10. Gamma, E., et al, Design Patterns, Addison-Wesley, NY, 1994
  11. Booch,. G, et al, Unified Modelling Language .9, White Paper, Rational, 1996
  12. OMG, The Common Object Request Broker Architecture and Specification, The Object Man- agement Group, MA, 1992