Business Objects as Constituents of Future Distributed ... - CiteSeerX

Business Objects as Constituents of Future Distributed Object-Oriented Business Information Systems 1-97

Axel Korthaus, Dipl.-Wirtsch.-Inf. Lehrstuhl fur Wirtschaftsinformatik III Universitat Mannheim, Schlo D-68131 Mannheim, Germany Tel.: +49 621 292 5493, email: [email protected]

Abstract:

As a result of the focusing on changing business requirements and the increasing popularity of object technologies for software and business engineering, the term \business object" has become a catchword. In this paper the most important denotations of the term \business object" are examined. It is shown how dierent authors and organizations understand business objects. Special emphasis is laid on the concept of business objects as proposed by the Object Management Group (OMG). The OMG Business Object Domain Task Force (BODTF) is currently making a great eort to drive forward the standardization process for Common Business Objects and a Business Object Facility. This paper describes what is being standardized and elaborates on the importance of striving for such standards. Key words: business objects, business object facility, object technology, distributed information systems, business engineering

1 INTRODUCTION

1

1 Introduction In the eld of software engineering the object-oriented approach has been receiving growing attention for several years. Object technology is bringing about a fundamental change to the way computer software is developed, used, re-used, distributed, and maintained. Lately it has been propagated to expand the area of application of object-oriented concepts to business (re-)engineering activities, i.e. the development and design of business models and business processes. Organizational structures and business processes on the one hand and business information systems on the other hand are no longer treated separately, but are integrated through the use of object technology (Fingar (1996), Gale and Eldred (1996), Jacobson et al. (1995), Taylor (1995)). The continuously accelerating change of environmental determinants forces enterprises to reorganize their business processes and leads to the need for new business engineering and software development paradigms in order to keep business processes and the supporting business information systems up with the changing requirements. For example, new organization concepts like decentralization, attened hierarchies, team work and \virtual enterprises" facilitate new business processes and increase the demand for distributed systems. Flexibility and reactivity are needed at every business level, including for instance the possibility to quickly modify existing information systems. The object-oriented approach supplies concepts like modularization, encapsulation, inheritance, and polymorphism, which facilitate the pursuit of these goals. The abstraction mechanisms provided by object technology help deal with the enormous complexity of business processes and distributed information systems (Fingar (1996)).

2 Categories of Business Objects As a result of the focusing on changing business requirements and the increasing popularity of object technologies, the term \business object" has become a buzzword. Unfortunately, the term is used to describe diering concepts, which partly not even belong to the world of object-orientation (see for instance section 3.1). Although there are many dierences in detail, it can be observed that there is a common idea behind business objects which is shared by most of the authors and organizations who use the term. In the object-oriented sense, an object is a building block that packages data (attributes) and procedures (methods), which are related to a speci c concept represented by the object. Business objects in particular are representations of some business semantics, they represent the structure and behavior of real world things or concepts from a business domain. Typical business objects are for example \employee", \product", \customer", \order", \machine", \warehouse", and \trade" (Schader and Rundshagen (1996), Shelton (1994b)). According to Object Management Group's (OMG) Business Object Domain Task Force (BODTF), a business object is \a representation of a thing active in the business domain, including its business name and de nition, attributes, behavior, relationships and

2 CATEGORIES OF BUSINESS OBJECTS

2

constraints. A business object may represent, for example, a person, place or concept. The representation may be in a natural language, a modeling language or a programming language." (BOMSIG (1995)). Robert E. Shelton, president of Open Engineering, Inc., adds to this de nition that business objects package business procedures, policy, and controls around business data. He calls this principle \semantic normalization", because business objects \hold together in a coherent unit the right business policy with the right data, ensuring that data is only used in a manner semantically consistent with business intent." (Shelton (1994b)) Business objects, as opposed to technical objects, which are only meaningful to IT people, are representations of something meaningful to business people. In the past, mainly the technical objects were the center of attention, leading to the development of numerous class libraries and GUI frameworks. Some authors do not restrict themselves to the distinction between business objects and technical objects. Shelton (1994b) for example forms three categories of objects, namely business objects, technology objects, and application objects. Shelton's application objects glue together business objects and technical objects in order to solve a speci c business problem (e.g. order entry, quarterly report, etc.). According to Sims (1995), \in many cases there need be no such construct as an `application' in the solution domain." Sims believes that business objects can be an entity such as a \customer", an encapsulation of business rules such as in an \order form", or a whole work ow. Consequently, the set of business objects is sometimes subdivided, for example into business entity objects and business process objects (OMG (1996)). There is a great variety of aspects from which business objects can be looked at. Graham (1995) identi es for instance an information systems framework view, a client/server infrastructural or Object Request Broker (ORB) view, an object modeling or reusability view, and a business process reengineering view of business objects. In the following subsections, a classi cation is used which is based upon three principal functions of business objects.

2.1 Business Objects as Modeling Concept

Modeling the world is a means of making complexity manageable by concentrating on the details relevant to a speci c purpose. Traditional systems analysis and design methods based on functional decomposition are not suitable to address today's need for an integrative, cross-functional approach to business process reengineering and software engineering eorts. Business process reengineering is about analyzing and reinventing core business processes that serve customer needs. It is about discovering fundamentally better ways to increase the customer value added. Since information systems have to support the redesigned business processes, business (re-)engineering requires a tight coupling to information systems engineering. This can be achieved by applying object-oriented concepts seamlessly at each level of the system lifecycle, from business process reengineering through design of the information systems architecture to implementation. One of the great advantages of object-oriented modeling techniques is that object-oriented business and software models will re ect real-

2 CATEGORIES OF BUSINESS OBJECTS

3

ity more naturally, since they are based on real-world objects. Thus, some of the problems with conventional computer-centered models are resolved, because business object models can be understood and communicated much easier. Business objects can model what is happening in the real world of business using concepts business people are familiar with (Fingar (1996), Hammer and Champy (1994), Shelton (1994a)). Viewing business demands as the driving force and combining business and software perspectives as two dierent facets of the same system is sometimes called \convergent engineering" (Taylor (1995)). This approach not only simpli es the engineering process, but also eliminates the gaps between business processes and their supporting software and thus facilitates change and adaptivity, because the problems of coordinating modi cations to the business and its software are minimized (Taylor (1995)). This view is corroborated by James (1996), who states that business object modeling facilitates a more precise analysis and provides, on the basis of modularization and encapsulation, the foundation for adaptive information systems. Furthermore, it becomes possible to reuse existing results even in the early phases of analysis and design. If a company has got a viable reuse strategy, reuse may lead to a reduction of costs and development times, while at the same time high quality standards can be preserved. In section 3.2, an example of a company's business object strategy in practice is given: SAP AG. SAP introduces business objects for modeling, interfacing and programming issues. In the area of modeling, SAP provides the Business Engineering Workbench (BEW) which contains editors and tools for modeling business objects. The BEW is used to facilitate the implementation of the distributed standard business application solution SAP R/3 in a company.

2.2 Business Objects as Interfacing Concept

One important feature of business objects is their ability to encapsulate underlying implementations. This can be exploited for solving problems with interfacing to existing software applications. Strictly speaking, this is just a special case of their function as programming units, but it is separated here because of its practical importance. Today there are still many companies (e.g. insurance companies) who depend on mainframebased legacy systems, in which enormous amounts of money have been invested. Consequently, these systems have to be kept alive for a while. Managers are looking for a way to migrate smoothly to object-technology. Business objects are an ideal starting point for this kind of migration, because they can encapsulate entire applications and thus make it possible to integrate these legacy systems in an object-oriented environment (Homann and Scharf (1996)). With business objects, a legacy system (e.g. an application that handles the company payroll) can be placed inside an object and access to the system is granted via methods of the business object capsule. Harmon and Morrissey (1996) state this more precisely by saying: \In fact, although we speak of the application as being placed inside an object, normally an object simply serves as an interface to the legacy application, taking messages

2 CATEGORIES OF BUSINESS OBJECTS

4

directed at the legacy application, causing the application to run and then sending the results back to other objects. (...) In eect, the legacy system becomes a special kind of business object that performs some large-scale task, like payroll generation." Encapsulating a whole legacy application within one \wrapper object" should of course be avoided, because it preserves the old problems and does not allow a gradual removal of the legacy system. Better strategies of encapsulating legacy systems are described in Homann and Scharf (1996). A very good example of the use of business objects for interfacing issues is SAP AG's current business object strategy (see section 3.2).

2.3 Business Objects as Programming Concept

A major trend in software engineering in the last years is the move towards componentbased software construction. Component technology promises high quality software that can be easily assembled with low expenditures of time and cost (Thomas (1995)).

Stal (1995) de nes components and objects as self-contained binary software units which make their functionality externally available through interfaces. Component technology is closely connected with the principles of object orientation. As stated by Leach (1994), \developments in object technology hold out the prospect of the creation of a componentbased software industry, in which applications are assembled from components from many sources; which can be deployed on multiple platforms; and can interoperate with other components and applications in a heterogeneous environment." Considering the problems of the well-known \application backlog", which is characterized by long software development cycles, high costs and poor quality, this prospect is very appealing. If components are documented in a precise and comprehensible way, and if they can be integrated in existing applications easily, the object-oriented components approach will result in productivity increases, easier maintenance, and real software reuse (Stal (1995)). To illustrate what is meant by components, gure 1 gives an overview of some representatives of this kind. A key feature of components is their potential suitability for reuse. While at rst small-scale classes like those used in C++ or Smalltalk were the only components for reuse, midsized components like those used in linking and embedding standard PC applications followed, and presently, very large-scale business object components are becoming the focus of interest. According to Harmon and Morrissey (1996), object-oriented applications will be built by combining these various kinds and sizes of components in the next years. Although there are established markets for class libraries and document components, business object components are hardly available and must be developed individually. Examples of companies who have built their own business objects and business object frameworks are given in Harmon and Morrissey (1996), who describe outstanding objectoriented business applications awarded by OMG in 1995. Some companies join together to form business object consortia in order to develop industry-speci c business objects

2 CATEGORIES OF BUSINESS OBJECTS

5 Large Components

Small Components Individual Components Programming Classes

Groups of Components

Specialized Programming Classes

Business Objects Document Components

Class Libraries

Frameworks Frameworks of Components for Interface and Generic Application Development

e.g. Rogue Wave’s C++ Booch Components

e.g. Next’s OpenStep Framework

Frameworks of Business Objects for Vertical Market Application Development e.g. Semitech’s CIM Manufacturing Framework

Figure 1: An overview of components (Harmon and Morrissey (1996)) and to create a market for them. An example of this is the Computer Integrated Manufacturing (CIM) Application Framework Speci cation, which has been developed by the SEMATECH consortium, a group made up of semiconductor manufacturers (Freed and McGuire (1995)). The ideas of componentware have been consequently developed further in the visions of OMG's Business Object Domain Task Force and Oliver Sims: they view business objects as independently developed executables, which can be plugged into a distributed environment by an end user or application developer and which will then interoperate with other business objects to meet the business needs without any additional programming required (OMG (1996), Sims (1996c)). An important prerequisite for the viability of this kind of business objects is the existence of a software infrastructure (\middleware"), on top of which business objects will operate. The rst steps in the direction of making the vision of distributed components a reality are made by software buses such as OMG's ORB, IBM's SOM and Microsoft's DCOM. But, according to Sims (1996b), \... there is a gap between what's being oered by ORB vendors and what application developers actually need. While products such as COM, OLE, OpenDoc, and CORBA-compliant ORBs do an excellent job at the `plumbing' level { that is, at the software technology or systems programming level, they do not directly help the business-solution developer." Before we examine in detail how these problems are to be overcome by the ideas of Sims and the BODTF, the somehow more `conventional' business object strategies of OAG and SAP AG are described in the following section.

3 EXAMPLES OF PRAGMATIC BUSINESS OBJECT POLICIES

6

3 Examples of Pragmatic Business Object Policies To avoid competitive disadvantages, many companies are forced to actively pursue a strategy for overcoming the problems of today's software applications. It is sometimes not appropriate or possible to migrate to pure object-orientation immediately or to wait for the business object vision come true. The following subsections describe two examples of a pragmatic move towards business objects.

3.1 Open Applications Group's OAGIS

The Open Applications Group (OAG) is a non-pro t organization formed in 1995. OAG's goal is to promote Open Applications Integration, which is the connectivity and multiplesource integration among enterprise software applications. To this end, the OAG establishes the so-called Open Applications Group Integration Speci cations (OAGIS), which describe data and process sharing and explain how application program methods can exchange data with other compliant business applications (OAG (1996)). It is the intention to allow users to buy OAGIS-compliant business applications from multiple vendors which can then be mixed and matched. When describing the focus of OAGIS, the OAG speaks of the business object level as opposed to the technical integration level, which involves operating systems, databases, middleware etc. By business object integration the OAG means the integration of software responsible for the automation of business functions. In order to provide business object integration, the OAG has speci ed an architecture called the Business Object Document (BOD). Unlike the concepts described in section 4, OAGIS will not enable \plug-and-play"-interoperability, because \the requirement to improve inter-operability across a diverse representation of existing application software precludes this, at least in the near term." (OAG (1996)) The Business Object Document serves as the message vehicle used to communicate requests from one software application to another. It is independent of the physical communication between the applications and can thus be based on any standard protocol like RPC, queuing, messaging, OLE/COM, CORBA etc. Business Object Documents contain information provided by the sender application, which is needed by the destination application to perform the required task. OAGIS links dierent business applications and normalizes the communication (including cross references of naming conventions) to de ne integration points of applications (OAG (1996)). The author feels that within OAGIS the term business object is used laxly, being valid for any kind of business application software, even if object-oriented concepts like inheritance and polymorphism cannot be applied. Furthermore, there is no turning away from thinking in terms of applications instead of focusing on business object components as proposed by Oliver Sims (see section 4.2).

3 EXAMPLES OF PRAGMATIC BUSINESS OBJECT POLICIES Business Engineering

Process

Compre-

Reference Model

hensive

Enterprise

Compre-

Business

hensive Object

Object Model

Reference Models

7

Models

Enterprise

Model

Model

Verification

What-If-

Enterprise

Analysis

Model

Business

Configuration

Driven Modeling, Simulation and Execution

Client/ Software Engineering

Server

R/3

Distribution

Object-

Workflow

Interfacing

oriented

R/3

93/94

R/3

95

Distributed Object Implementation & Execution R/3

96

R/3

97/98

Figure 2: SAP's Vision for Object Technology, Zuck (1996)

3.2 SAP AG's Business Object Strategy

SAP AG is one of the leading vendors of enterprise application software solutions. According to IDC, the client/server business application system SAP R/3 is commanding a 31% share of the worldwide client/server enterprise application software market. With R/3 Release 3.0, SAP has introduced business objects as a strategy for the integration of object-oriented concepts into their products. It is often stated that the basic technology of standard business software architectures like SAP R/3 is obsolete. The vendors of standard software have to react to these and other reproaches. The adaptation of new technologies, continuous improvements without disruptions, upgradability, high scalability and distribution, high interoperability, and manageability are some of the partially con icting goals mentioned by SAP concerning the further development of their product (Zuck (1996)). SAP has recognized the need for the exploitation of object-oriented concepts. With their SAP Business Objects, they have introduced an abstraction which they assume to be helpful for modeling, interfacing and programming issues (see section 2). SAP Business Objects serve as a link between business engineering and software engineering. Figure 2 shows SAP's vision for object technology. As an object modeling concept, SAP Business Objects are used in business process modeling, which can be done with the Business Engineering Workbench tool in order to facilitate a faster implementation of R/3 in an enterprise. Thus, many of the advantages ascribed to object oriented analysis techniques can be exploited, as for example the support of an easy communication between business and IT people.

3 EXAMPLES OF PRAGMATIC BUSINESS OBJECT POLICIES Presentation Layer

8

Presentation Layer

Business Object Broker Application Component Function Module

Function Module

Business Object

Business Object

Function Module

Function Module

R/3 Before

After

Figure 3: Object-Oriented Interfacing in R/3, Zuck (1996) Another important way of using SAP Business Objects at present is their application for interfacing. SAP has developed an object-oriented \shell" to present an object-oriented view of their existing application, which oers some of the bene ts of objects to external users or systems while the underlying mature applications and infrastructure are kept. SAP Business Objects provide a higher-level programming interface to R/3, which can be used by clients such as SAP's own Business Work ow product and external programs written by users or systems integrators (see gure 3). Thus, they facilitate a smooth transition into object technology without sacri cing the stability of the operational system (Benchmarking Partners (1996)). SAP's vision for object technology is not limited to modeling and interfacing, but also includes programming issues. Presently, SAP is extending their proprietary 4GL programming language ABAP/4 with object-oriented features, including for example inheritance and polymorphism. New modules, e.g. internet application components, will be directly developed in an object-oriented way. In the long term, the goal is to achieve a close relationship between modeled SAP Business Objects and code of the system written in object-oriented ABAP/4. R/3 today contains about 170 SAP Business Objects, with which a user can work, instead of being confronted with the 4000 R/3 data entities and 3000 ABAP/4 transactions. SAP Business Objects generally map their attributes to the underlying relational data tables of SAP R/3 (SAP AG (1996)). The methods of SAP Business Objects constitute the so-called Business Application Programming Interfaces (BAPIs), which are meant to be longterm stable interfaces to R/3. They are speci ed in cooperation with Microsoft, SAP customers, and standards organiza-

4 THE VISION OF COOPERATIVE BUSINESS OBJECTS

9

SAP GUI R/3 Application SAP Business Workflow

CORBA Client (under development)

R/3 Application

CORBA Server

CORBA Communication

RFC Visual Basic, Excel, MS Project, ... COM/DCOM Internet, Explorer, Netscape

OB OCX

B r o k e r

Purchase Order

Purchase Requisition

Material

Business Object Repository HTML

R/3 Internet Application

R/3 Database

Figure 4: Business Object Broker, Zuck (1996) tions like OAG and OMG, so that they will provide COM/DCOM, OAGIS, and CORBA compliance. The new R/3 Internet Components, introduced in Release 3.1, use the new BAPIs to access R/3 (SAP AG (1996)). SAP Business Objects are managed by the Business Object Repository (BOR) shown in gure 4, which also provides the mapping to the R/3 database. Runtime access to SAP Business Objects is provided by a Business Object Broker, which is part of the BOR. The BOR environment not only contains SAP Business Objects, but also technical objects and metaobjects, which serve for documentation purposes (SAP AG (1996)). In conclusion it can be said that SAP's use of business objects brings some of the bene ts of encapsulation and reuse into their product, e.g. reuse of SAP Business Objects by the SAP Business Work ow product. In fact, it is a very good example of the use of business objects for encapsulating a `legacy system', i.e. the old R/3 core application, which was built using conventional techniques. The key advantage of this strategy is, that it shows a practicable migration path to pure object-oriented implementation of future SAP modules, or even an entirely new, next-generation system. But, even if it is a good starting point for evolution, it is yet far from the vision of delivering self-contained business software components like those described in the next section.

4 The Vision of Cooperative Business Objects The prospects of component-based software construction, which are based on the concepts of componentization, model-based speci cations, and end-user solution assembly, are rounded o by the business object vision promoted by the OMG Business Objects

4 THE VISION OF COOPERATIVE BUSINESS OBJECTS

10

Domain Task Force, Oliver Sims, and others. This vision questions the programming models we have today in principle by replacing the idea of applications with the idea of cooperative business objects.

4.1 OMG's Business Object Domain Task Force

The Object Management Group (OMG), founded in 1989, is a consortium of over 600 manufacturers, software vendors, and users, whose primary goal it is to establish an architecture and a set of speci cations to enable distributed integrated software systems based on object technology. Therefore the OMG issues Requests For Information (RFI) and Requests For Proposals (RFP) to adopt existing interface and protocol speci cations submitted by the software industry.

The OMG has made remarkable progress in the formulation of object technology standards. A milestone was OMG's adoption of an Object Request Broker (ORB) standard in late 1991. The ORB is a kind of software bus which provides interoperability between objects on dierent machines in heterogeneous distributed environments. In 1992, CORBA (Common Object Request Broker Architecture) Version 1 was published and adopted by over 50 computer manufacturers and software developers (Leach (1994)). The conceptual framework for OMG's adoption of interface and protocol speci cations is the Object Management Architecture (OMA), published in 1995, which includes a reference model for distributed object computing and de nes OMG's technical objectives and terminology (see gure 5). OMA consists of ORBs, which enable objects to transparently make and receive requests and responses, CORBAservices, that support basic functions for using and managing objects, Application Objects, which are objects speci c to particular industries or end-user applications, and CORBAfacilities. While originally there was only one box for so-called Common Facilities, OMA now (after the reorganization of OMG in 1996) contains two boxes { one for Vertical CORBAfacilities, which apply to a speci c application domain, and one for Horizontal CORBAfacilities, which apply to virtually any application domain (Siegel (1996)). In 1993, a Special Interest Group for Business Object Management (BOMSIG) was formed within the OMG, which has now become the Business Object Domain Task Force (BODTF). In February 1996, the BOMSIG issued a RFP for \Common Business Objects" and for a \Business Object Facility" (BOF) through the Common Facilities Task Force. This RFP marks a shift in the topics addressed by OMG: while OMG's activities used to be aimed mainly at the infrastructure builders' needs, this RFP explicitly picks out the needs of end users and application developers as a central theme (Sims (1996b)). The RFP solicits proposals for the following two items:  \Common Business Objects (CBOs): Objects representing those business semantics that can be shown to be common across most businesses.  Business Object Facility (BOF): The infrastructure (application architecture, services, etc...) required to support business objects operating as cooperative application components in a distributed object environment." (OMG (1996))

4 THE VISION OF COOPERATIVE BUSINESS OBJECTS Application Objects

Vertical CORBAfacilities

Horizontal CORBAfacilities

Healthcare

Financial

User Interface

Info Mgmt

Telecomm

etc.

Systems Mgmt

Task Mgmt

OBJECT

Lifecycle

11

REQUEST

Naming

BROKERS

Persistence

etc.

CORBAservices

Figure 5: The Object Management Architecture (OMA), Siegel (1996) Common Business Objects (CBOs) stand for basic business model concepts that are found in any business, such as \resource", \transaction", and \legal entity". CBOs can be seen as models, templates, designs or patterns on the one hand and also as corresponding runtime software constructs on the other hand. The Business Object Facility will be based on CORBA to provide the foundation for business objects (Casanave (1996a), OMG (1996)). Figure 6 illustrates the layering approach chosen by the BODTF to base more specialized business objects on general technology objects. The major goals of the OMG Common Business Object (CBO) vision are:  \Interoperability of OMG Business Objects as both design-time and run-time constructs including the possibility of ad-hoc integration.  Simplicity, so that design and implementation, con guration and deployment is viable for the average developer." (OMG (1996)) By \ad-hoc integration", the RFP means that run-time business object components (called application components in the RFP) must be able to \plug-and-play", i.e. they can be put together in a run-time environment and will then work without any intervention by IT professionals. Furthermore, a newly plugged-in business object will be able to interact with other business objects in order to perform some business function. This interaction can take place even if it was not planned or foreseen by the developers of the business objects. The demanded simplicity has to guarantee that software technology complexities are hidden. Thus, it becomes possible for application developers, who are trained in building

4 THE VISION OF COOPERATIVE BUSINESS OBJECTS

12

Enterprise Specific Business Objects Financial Business Objects

Manufacturing Business Objects

Other Business Objects

Common Business Objects Business Object Facility CORBA, CORBAservices, CORBAfacilities

Figure 6: Architecture for Business Objects, OMG (1996) business solutions, to implement business objects without the need for system programming skills. Business objects as plug-and-play interoperable components can be used directly by the end users as parts of a business solution. The ad-hoc combination of business objects for some business purpose may be enabled by tools or even more directly by dragging and dropping business object icons on an object-oriented user interface (Sims (1996a)). The RFP aims at a peer-to-peer, multi-tier architecture for distributed computing instead of focusing on the more traditional client-server models of \fat clients", which contain all the business rules. The multi-tier architecture helps to separate business concerns from user interface, storage and other technology issues. The business object interoperability strived for by the RFP implies a number of requirements to be met. According to Sims (1996a), this kind of interoperability requires loose binding and semantically encoded message data to allow for ad-hoc integration. Semantic message data is described in the next subsection. In section 2.3, the SEMATECH CIM framework was mentioned as an implementation of industry-speci c business objects. Prompted by OMG's standardization process, SEMATECH is now trying to generalize the CIM framework and base it on OMG CBOs and the BOF (Casanave (1996b)). The responses to the RFP for Common Business Objects and a Business Object Facility are due by November 15th, 1996, and results from the OMG are expected by mid 1997.

4 THE VISION OF COOPERATIVE BUSINESS OBJECTS

13

4.2 Oliver Sims' Newi Approach

The goals and areas of standardization described in the BOMSIG RFP have been strongly in uenced by the ideas Oliver Sims discusses in his book \Business Objects" (Sims (1994)). Sims originated the concept of Cooperative Business Objects (also abbreviated CBOs) as an end-product of the software development process. Instead of applications, Sims views CBOs as the units of delivery. Sims' CBOs are executables, which can be independently developed and integrated at run-time. CBOs can be implemented using any programming language including non object-oriented languages as long as they have the shape described by Sims. Sims also explains in detail the middleware necessary to enable these concepts.

Interoperability of CBO executables, which has not been pre-planned by the CBO developers, requires a loose, message-time binding of CBOs, because their interfaces are unknown in advance. This implies that CBOs must handle their own method resolution (there is only one exported entry point), because the message code must be found at runtime. Furthermore, messages must be expressed semantically. For example, \instead of saying that some CBO method expects two character strings of 20 and 30 characters respectively, plus an integer plus a oating point number { in that order { we need to be able to say that the CBO method expects a Product Name and Description, plus a Stock-on-Hand plus a Price." (Sims (1995)) With this approach, only these semantics have to be agreed on, so that all developers know which string refers to which concept. Common Business Object standards could provide this common understanding. Semantic interactions not only have the advantage, that they are directly based on business terms, they also decrease the `surface area' of the system, that is the amount of information which has to be shared in advance (Sims (1996b)). Message data is always in a self-describing form, i.e. metadata (semantic labels) is carried within the message data, thus allowing for late semantic binding. The business object executable is loaded by the middleware, when there is a message for an instance of the class whose implementation it is. The message is handed to the object's single entry point and resolved within the implementation (Sims (1996c)). The concepts described by Oliver Sims are proven to be viable by the \Newi" product from SSA Object Technology. Newi is a framework for creating and running CBOs. It consists of run-time frameworks, development tools, and a proprietary ORB, which has a lot of similarities with CORBA. It is to be expected that Newi will be based on CORBA in the future, because with the new dynamic skeleton interface, a CORBA 2.0 ORB can provide all the underlying mechanisms Newi needs. Newi also shows a way how business objects can be used at run-time by end users. Each CBO is represented by an icon on a graphical user interface, and one way to integrate two CBOs is by moving their icons. For example, the icon of CBO customer could be dragged over an icon of CBO address form, which will have the eect that the form is automatically lled with the customer data. \The goal of Newi is to hide system-level complexities and make it easier for users to play legos with CBOs." (Orfali et al. (1996))

5 CRITICISM AND PROSPECTS

14

4.3 Areas and Bene ts of Standardization

The establishment of a standard for Common Business Objects and a Business Object Facility promises a number of advantages. The standardization process for example can synergize the work being done in creating business applications and distributed object components into a cooperative industry eort. It will be easier to develop software for distributed, heterogeneous environments, because application developers do not have to care about the additional complexities. Independent developers will be able to produce compatible components if architecture and computing mechanisms are standardized. Open markets for pre-built CBOs and tools for using and building components will develop. Customers will no longer be dependent on single software vendors, who may not always have the best oer. They can buy business objects from the open market and build their best solutions individually. Another important advantage is the expectation that these standards will lead to better quality. CBOs can be developed from a number of software manufacturers and therefore software can be assembled using widely-developed and tested, stable components which in turn will produce the required productivity and quality gains. Although standards can be very positive, there is a danger of establishing standards that are not appropriate or too restrictive. The consequences would be that innovation is hindered and the technology cannot be fully exploited. To avoid overspeci cation, standards should be minimal in the sense that they should provide a sucient level of standardization to meet the given goals. According to Sims (1996a), the BODTF should restrict itself to the following general areas of standardization concerning the BOF: 1. \Interfaces to supporting/enabling CORBA objects within the BOF. 2. Precise way in which the BOF uses CORBA and CORBAservices and CORBAfacilities. 3. Message structure, including self-de ning data formats. 4. Technical description of the executable (the binary), including how it makes itself known to the BOF. 5. Management of class hierarchies and inheritance. 6. Speci c interfaces for tools, and support for (\hooks into") underlying systems management and security facilities (these may be subsumed in the above ve areas)."

5 Criticism and Prospects The realization of the vision of CBOs and a BOF on a broad basis seems to be an ambitious goal, and many questions remain to be answered. For example, it remains questionable,

5 CRITICISM AND PROSPECTS

15

if it is really possible in practice to agree on the properties and behavior of Common Business Objects. Wooding (1995) describes the experience of projects carried out by the Object Interest Group, a consortium of 16 leading UK companies, during which Common Business Objects were de ned. The members quickly identi ed about 100 business concepts that were common across the involved businesses. However, when these potential business objects were applied to particular problems, it was found that they had only few common characteristics that could easily be applied by all the members. It turned out that it was very hard to reach an agreement on common business objects and that the work on CBOs across corporations had to be con ned to non-competitive issues. Otherwise the process would have led to valueless or vacuous components only, i.e. components that were too abstract to be of any practical use. The problems of de ning standard business semantics also aect the realization of a semantic interaction, which depends on a basic agreement on semantics. Furthermore, semantic interaction rises the question of a generally acceptable compromise for the tradeo between performance and exibility. Loose, message-time binding in particular and the BOF in general require another layer of system overhead which could lead to losses in application speed, at least as long as current hardware is used. Having the problems of standardizing business semantics in mind, one could ask, if it is worthwhile waiting for the OMG standards to evolve or if one should choose a pragmatic approach just as SAP AG and others, who have already begun to de ne business objects by themselves and use them for their purposes. In the author's opinion, this should not be regarded as a con ict. Keeping the OMG standards in the back of one's mind, starting with business objects now brings about the bene t of introducing the new way of thinking into the enterprise and gaining experience early. If the emerging problems can be solved, the potential bene ts are quite substantial, as stated earlier. The most dramatic impact of business object technology will be that end users will begin to develop their own software by `snapping' together dierent objects to form a software solution (Leach (1994)). Sims (1994) comes to the conclusion that \CBOs { as the thing that IT should be delivering { will play a large part in turning the dream of real re-use, and of moving IT o the critical path of business change, into reality." The shift toward business objects will result in a change of the software market structure. On the software distribution side, object warehouses will emerge, who distribute objects from many vendors. Perhaps there will be a need for object integrators who assemble dierent business objects from multiple vendors into chunks of objects solving a speci c business problem. Finally, a new profession of \domain experts" will probably emerge, who know the problems of particular vertical industries as well as the process of assembling business objects (Leach (1994)).

REFERENCES

16

References Benchmarking Partners (1996). The SAP R/3 Business Object Repository. White Paper Volume 1, Issue 1. Benchmarking Partners, Inc. http://www.sap.com/mall/ newstand/litera/interf.htm. BOMSIG (1995). `De ning Business Objects'. First Class. Special Issue \Business Object Management" S. 5. Casanave, C. (1996a). `The OMG Business Object Domain Task Force'. First Class VI/IV(33), 9{11. Casanave, C. (1996b). SEMATECH CIM Framework { Generalization Feasibility Analysis. Technical report. SEMATECH and Data Access Technologies. 14000 S.W. 119 Avenue, Miami, Florida 33186. Fingar, P. (1996). The Blueprint for Business Objects. Managing Object Technology. SIGS Books & Multimedia. New York etc. Freed, K. and P. McGuire (1995). Computer Integrated Manufacturing (CIM) Application Framework Speci cation 1.2. Technical Report. Technology Transfer: 93061697EENG. SEMATECH. Gale, T. and J. Eldred (1996). Getting Results with the Object-Oriented Enterprise Model. Managing Object Technology. SIGS Books & Multimedia. New York etc. Graham, I. (1995). `Perspectives on Business Objects'. First Class. Special Issue \Business Object Management" V/II, 12{13. Hammer, M. and J. Champy (1994). Reengineering the Corporation { A Manifesto for Business Revolution. Nicholas Brealey Publishing. London. Harmon, P. and W. Morrissey (1996). The Object Technology Casebook { Lessons from Award-Winning Business Applications. Object Management Group. John Wiley & Sons, Inc. New York. Homann, F. and T. Scharf (1996). `Sanfter U bergang der zahlreichen Altsysteme in die neue objektorientierte Welt'. Datenbank Fokus, Beiheft Objekt Fokus 2, 8{14. Holzer, T. (1996). `Objektorientierte Standardsoftware?'. OBJEKTspektrum 1, 68{71. Jacobson, I., M. Ericsson and A. Jacobson (1995). The Object Advantage { Business Process Reengineering with Object Technology. Addison-Wesley. Wokingham, England. James, B. (1996). `Business Engineering with Business Objects'. Proceedings of Object World and Internet Forum Europe 96, Frankfurt, Germany, Tutorial O3. Leach, E. (1994). The Impact of Object Technology and OMG Standards on Software Development. In K. Spurr, P. Layzell, L. Jennison and N. Richards (Hrsg.). `Business Objects: Software Solutions'. John Wiley & Sons, Inc. Chicester. S. 177{194.

REFERENCES

17

OAG (1996). OAGIS { Open Applications Group Integration Speci cations. Technical Report 1996.09.12 Version 1.024.0. Open Applications Group, Inc. 401 North Michigan Avenue, Chicago, Illinois 60611 USA. http://www.oag.org. OMG (1996). Common Facilities RFP-4, Common Business Objects and Business Object Facility. Request for Proposal. OMG TC Document CF/96-01-04. Object Management Group. Orfali, R., D. Harkey and J. Edwards (1996). The Essential Distributed Objects Survival Guide. John Wiley & Sons, Inc. New York etc. SAP AG (1996). R/3 System { SAP Business Objects. White paper. SAP AG. Neurottstrae 16, 69190 Walldorf, Germany. http://www.sap.com/mall/newstand/ litera/interf.htm. Schader, M. and M. Rundshagen (1996). Objektorientierte Systemanalyse { Eine Einfuhrung. Reihe Objekttechnologie. 2. edn. Springer-Verlag. Berlin etc. Shelton, R. (1994a). `Business Objects { BPR with Object?'. Data Management Review Shelton, R. (1994b). `Business Objects { What is a Business Object?'. Data Management Review Siegel, J. (1996). `OMG's Domain Task Forces: Getting Started'. First Class VI/IV(33), 6{8. Sims, O. (1994). Business Objects { Delivering Cooperative Objects for Client-Server. IBM McGraw-Hill series. McGraw-Hill Book Company. London etc. Sims, O. (1995). `A Programer's Model for Today'. Object Expert 1(1), 26{31. Sims, O. (1996a). The OMG Business Object Facility and the OMG Business Object. White Paper. Document GD-011-1. System Software Associates Ltd. Sims, O. (1996b). `The OMG Steps up'. Object Expert 1(4), 16{19. Sims, O. (1996c). `Why Projects Don't Get O to a Good Start'. Object Magazine 6(8), 64{67. Stal, M. (1995). `Componentware { die Vision von verteilten Objekten'. OBJEKTspektrum 4, 77{81. Taylor, D. (1995). Business Engineering with Object Technology. John Wiley & Sons, Inc. New York etc. Thomas, D. (1995). `Component-Based Software Construction: Making the Transition from Craft to Engineering'. First Class V/I, 12{13. Wooding, T. (1995). `The Feasibility of Common Business Objects'. Object Magazine 5(6), 16{20, 25. Zuck, W. (1996). `Business Objects for Modeling, Interfacing, and Programming'. Proceedings of Object World and Internet Forum Europe 96, Frankfurt, Germany, Track \Methods", ME.4.