---

This page was published as:

• Sutherland, Jeff. Business Object Design and Implementation. 10^th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications Addendum to the Proceedings. OOPS Messenger 6:4:170-175. ACM/SIGPLAN October, 1995.

Workshop Co-Chairs:

Jeff Sutherland - VMARK Software 
Cory Casanave - Data Access Corporation 
Glenn Hollowell -- Sematech 
Joaquin Miller - SHL Systemhouse
Dilip Patel - South Bank University

Background

X3H7 Object Information Management

Interoperability of large grained objects existing in these environments was identified as a core activity in the standards process.

In addition, X3H7 projected that implementation of systems will move up to a higher level of abstraction. A business model will be built for enterprise applications using standard object-oriented analysis and design (OOAD) techniques, legacy CASE models will be incorporated, and major amounts of code will be autogenerated, rather than hand coded. OOAD models, documentation, and code will be stored and versioned in an object repository and injected into the run time environment. Furthermore, the business object model will be a component-based model that supports component distribution over arbitrary processors on a network.

Provision for interoperability between standard business components was identified as a major priority. One can conclude, based on the experience at SEMATECH and NIST, building large software frameworks for chip fabrication plants requires a Business Object Component Architecture to enable interoperability. This insight is generalizable across a wide variety of application domains.

The need for a component-based enterprise architecture led X3H7 to propose development of an ISO RM-ODP Enterprise Viewpoint Companion Standard. This resulted in the initiation of three activities:

• ISO/IEC JTC 1/SC 21 WG7 initiation of a New Work Item proposal for an Enterprise Viewpoint Component Standard to be reviewed at the May 1996 meeting of S21 in Kansas City.
• X3H7 initiation of a close liaison with the OMG BOMSIG work on a Business Application Architecture.
• X3H7 and OMG BOMSIG sponsorship of an OOPSLA'95 Workshop on Business Object Design and Implementation to facilitate technical input from industry, government, and academic communities.

OMG Business Object Management Special Interest Group (BOMSIG)

The current focus of OMG BOMSIG is development of a Request For Proposal (RFP) to address the OMA component called Common Facilities. The RFP solicits proposals for the following:

• Common Business Objects
• Component Interoperability Facility

• To address the need for significantly enhanced levels of simplicity, over and above that which exists today, to the task of defining, designing, building and deploying integrated yet flexible business solutions. Reduction of complexity is to be achieved through a higher level of abstraction and greater reuse than exists today for business applications.
• To provide a common starting point for the work of domain standards groups.

• Business objects as design-time (modeling-time/analysis-time etc.) constructs or models, some of which are domain-specific, others having cross-domain applicability (Common Business Objects)
• A set of facilities that brings significantly greater levels of simplicity in developing the run-time deployable software that implements those constructs or models (Component Interoperability Facility). This set of facilities would include both behaviors shared by all business objects and through business object linkages to underlying computational mechanisms.

The Common Business Objects component of this RFP should provide a common starting point for enterprise application developers and domain industry standards groups by providing a set of business concept abstractions from which more specific business objects can be specialized. In some cases these abstract objects may be quite generic since the concept varies considerably from one industry to the next. In other cases, the abstractions may be quite specific because the concept occurs much the same in all industries. The objective is to promote consistency across industries and enterprises and minimize the duplication of effort to define and eventually implement (using the Component Interoperability Facility) enterprise and industry frameworks.

The people who will benefit from the greater levels of simplicity include

• those tasked with business object modeling, analysis and design, and
• those whose job it is to implement those designs in code such that their end products will interoperate with those of other implementers, and
• the business that use the resultant business object based applications, through a flexible information system designed to serve business needs.

Goal of the Workshop

Of particular concern is the infrastructure required for supporting domain specific business object models. At a recent Object Management Group meeting BOMSIG outlined four layers of object technology for standardization:

• Distributed Object Layer (CORBA, OLE/COM, ...)
• Component Interoperability Facility (Business Object type, Business Process Object and Business Entity Object subtypes, generic functionality subtypes of Business Process Objects, generic data specification subtypes of Business Entity Objects)
• Common Business Object Layer (Customer or Part as subtype of generic functionality object, Order as subtype of generic data specification object, ...)
• Domain Specific Application Frameworks (Will need to have a consistent infrastructure to be widely used within and across industries. The concepts for this infrastructure are just beginning to emerge as standards for the distributed object layer are stabilized by the Object Management Group and individual software vendors.)

Papers addressing issues related to component interoperability and common business objects were solicited from academia, government, and industry for the workshop.

Presented Papers

The software industry has been struggling with how to produce software IC chips for years with little success. Meanwhile, the custom chip industry has learned how to shrink wrap software, embed it in hardware, and market custom chip sets. This is the model of the future for software distribution.

Business Object Architectures and Standards - Cory Casanave, Data Access Corporation

As the Chair of OMG BOMSIG, Cory presented the latest thinking of the committee on the business object infrastructure that is needed to support large domain specific frameworks in finance, manufacturing, heath care, amd insurance. His paper summarizes the current BOMSIG view of a Business Application Architecture.

Implementing Business Objects: CORBA interfaces for legacy systems - Thomas Grotehen and Rene Schwarb, Swiss Bank Corporation/SYSTOR

In 1991, the OMG defined an architectural framework (OMA-Object Management Architecture) as a milestone in realizing the vision of distributed object-oriented computing. This paper describes an experiment designed to examine whether an OMA CORBA (Common Object Request Broker Architecture) implementation can be successfully employed in the existing information technology environment of a bank. It provides an overview of both the benefits and the problems involved and an outlook on future technology developments in this area.

An Architecture Framework: From Business Strategies to Implementation - William Hertha, Jim E. Bennett, Frank J. Post, Ian M. Page, Canadian Imperial Bank of Commerce

Business systems architects and their clients increasingly suffer from information overload. To help businesses to partition and relate the kinds of architecture information they must build and share, we propose a framework consisting of three related models, each incorporating four tiers of subject matter connected by use cases.

An Architectural Framework for Semantic Inter-Operability in Distributed Object Systems - Rainer Kossmann, Bell Northern Research, Ltd.

This research paper reports results of research on semantic inter-operability in realtime, distributed object-oriented systems. It proposes an architectural framework for distributed heterogeneous object system organization. The major goals of the framework are to provide a basis of inter-operability for different kinds of object models and application domains.

Position Paper - William E. McCarthy, Michigan State University

• As an accounting professor, Bill McCarthy has been working for years on specifying the standard design pattern for accounting systems. There is general agreement in the accounting community that there is one pattern that should be the basis of all accounting systems. Bill argued that systems built in every domain should be based on this pattern. It is clear that any business object application architecture must support it as a central concept. This was an innovative and seminal paper.

• Bruce presented an experience paper outlining the structure of a distributed object framework for client server systems based on Smalltalk.

• There is a need for specifying standard component types that can be used to structure large object systems, in the same way that gothic arches are used repeatedly and recursively to build a cathedral. Colin Ashford presented the latest BNR thinking in this area.

• This paper was a preview of Oracle's next generation object-oriented CASE tool that will support Business Process Reengineering and integrate it seamlessly with object-oriented analysis, design, and code generation. Of high interest, was the fact that the target platform for delivery of this system is Oracle's new object database.

The stated, accepted philosophy for systems development is that systems development process is a well understood approach that can be planned, estimated, and successfully completed. This is an incorrect basis. SCRUM states that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used.

Experiences with a Manufacturing Framework - Selden L. Stewart and James A. St. Pierre, NIST

This paper describes the first year of a joint project between the National Institute of Standards and Technology (NIST) and SEMATECH. After studying the SEMATECH CIM Framework, we present a roadmap for adoption and use of manufacturing frameworks with four components: developing a specification, reaching consensus, standardization, and testing and certification. Results of our study include numerous recommendations about online specifications, supplier involvement, standards organizations, usage scenarios, reference implementations, and a testing and certification plan. 

Conclusions of the Workshop

• In the future, cycle time will be the most critical issue for business operations. The speed with which new or enhanced products and services can be developed and delivered to the marketplace will determine market share and profitability.
• Products and services will be increasingly supported by software components. Most of these components must be reused from previous development efforts in order to meet required cycle times. This requires major advances in component interoperability and availability. A model for this activity exists in the custom chip industry which is already selling software components packaged as hardware [Digre95].
• A radical reversal in the current approach to software engineering is required to meet market demands. Currently, systems have tight coupling between software components (inflexible systems), and loose coupling between analysis, design, and implementation (leading to excessive cost and delivery times, as well as poor fit of software to user requirements). In the future, Business Process Reengineering methods will be tightly coupled with object-oriented analysis and design. Most of the code which is currently written by hand will be generated from design, or reusable components will eliminate the need to write it.
• Advances in the software development process are required to dramatically improve productivity in a component based development environment. In particularly, previous methods have assumed software development is a controlled process rather than an empirical process. Component based object systems are not Turing machines because of their event driven nature [Wegner95], and as a result are not fully specifiable. The process control industry has developed methods to deal with these types of empirical processes and these methods must be applied to software development using a SCRUM approach [Schwaber95].
• Component based architectures will be built from replaceable units of functionality that reduce the surface area of systems that are doubling in complexity each year. Large grain components will have clear sets of responsibilities or roles, and expose semantics of the business as well as syntax of interfaces [Digre95].
• There are specific design patterns that should be implemented throughout business systems that will substantially improve reusability and rigor in business systems logic. The "Give/Take" pattern that has been standardized by accounting research should be rigorously implemented in all business systems and mandated in all accounting systems [McCarthy95]. As much as 50% of the typical business application could be built from recursively implementing this pattern. Many companies (even banks) have trouble balancing their books or accurately determining the current status of business operations because of failure to implement this pattern properly in their business software systems.

Pointers of Interest

• Design Patterns
• X3H7 Object Model Features Matrix
• White Paper on OMG Business Application Architecture - Draft/Overview
• BOMSIG Glossary of Terms
• Component Design Pattern for Business Objects

---

   

This page was built by Jeff Sutherland using Netscape Navigator Gold. Your feedback is appreciated!