Workshop Report: Business Object Design and Implementation
This page was published as:
Sutherland, Jeff. Business Object Design and Implementation. 10th
Annual Conference on Object-Oriented Programming Systems, Languages, and
Applications Addendum to the Proceedings. OOPS Messenger 6:4:170-175.
ACM/SIGPLAN October, 1995.
Jeff Sutherland - VMARK Software
Cory Casanave - Data Access
Glenn Hollowell -- Sematech
Joaquin Miller - SHL Systemhouse
Dilip Patel - South Bank University
The OOPSLA Workshop on Business Object Design and Implementation was jointly
sponsored by the Accredited Standards Committee X3H7 Object Information
Management Technical Committee and the Object Management Group (OMG) Business
Object Management Special Interest Group (BOMSIG) for the purpose of soliciting
technical position papers relevant to the design and implementation of
Business Object systems.
X3H7 Object Information Management
In 1994, the X3H7 Object Information Management Technical Committee projected
that over the next decade, more than 80% of new object-oriented software
systems would be built in three object-oriented languages (Smalltalk, C++,
and OO COBOL) and communicate through a Object Request Broker to four primary
external environments (SQL databases, Object Databases, Microsoft OLE/COM,
and CORBA objects).
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
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 Object Management Group's central mission is to establish an architecture
and set of specifications, based on commercially available object technology,
to enable distributed integrated applications. Primary goals
are the reusability, portability and interoperability
of object-based software components in distributed heterogeneous environments.
To this end, the OMG adopts interface and protocol specifications that
define an Object Management Architecture (OMA) that supports applications
based on distributed interoperating objects.
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:
The objectives of the RFP are:
Common Business Objects
Component Interoperability Facility
Providing the required higher level of abstraction has two separate, but
closely related, aspects:
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.
The Component Interoperability Facility should provide the abstraction
which hides computational complexities, and enables business objects to
interoperate efficiently and reliably in multi-user, concurrent, distributed,
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
The people who will benefit from the greater levels of simplicity include
The work of OMG BOMSIG is directly related to the current work of the X3H7
Object Information Management Committee. Industry consortia standards developed
by OMG can be formalized through the accredited standards process through
the current ISO work item that is the designated task of X3H7.
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
The goal of the workshop is to facilitate development of design patterns
and frameworks for building business object systems. A common business
object infrastructure is essential to an object-oriented software platform
that enables systematic reuse of components across an enterprise.
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
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.
Business Application Components - Tom Digre,
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
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,
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
Position Paper - Bruce
Miner, Koba Software, Inc.
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.
Position Paper - Stéphane
Poirier and Colin Ashford, Bell Northern Research. Ltd.
Bruce presented an experience paper outlining the structure of a distributed
object framework for client server systems based on Smalltalk.
Position Paper - Guus
Ramackers, Oracle Corporation
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.
SCRUM Development Process - Ken Schwaber, Advanced
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
The wide variety of papers presented and the high level of expertise at
the workshop led to a consensus on several important issues:
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
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
Pointers of Interest
This page was built by Jeff Sutherland using
Gold. Your feedback is appreciated!