Business Object Transitioning

Lenny Estrin

Introduction

This paper will describe the experience and history of introducing Business Objects into large organization. The purpose of this paper is to illustrate the history or evolution of the transition process, so that the process of the transition is documented and shared in the among the OOPSLA Workshop participants.

The road of establishing the Business Objects as a best practice in a large insurance company, which has a tremendous investment in a legacy code and which has had problem adopting a new technologies, has been a challenging one. We have experimented with variety of new concepts that would help us to transition more quickly and less painfully to the new architecture which is required. Business Objects is one of these tools or concepts, however we have had a few others before we have reached the BO.

Brief History

Several years ago we introduced object technology as a primary tool for improving the design and development of applications, particularly graphical user interfaces in client/server environment.. Throughout the projects which used OO we have found that the learning curve was almost prohibitive for the end product delivery. Moreover, reuse only impacted the construction of GUI widgets and no design reuse was taken place, which raised a lot of questions about the visibility of the OO benefits.

While using object-oriented development and design tools a long time must be spent in order to understand the low level class hierarchy of the classes and their interaction. The classes which were being used during construction are of a fine grain and in order to be efficiently applied to solve a particular problem would have to interact with another class of similar granularity to produce the desired result. The study by Barry Boehm of the reuse cost of a single component in NASA illustrates that any change has its cost. One has to locate the appropriate component, (the same impact on learning curve of object-oriented languages - finding the right component to satisfy the appropriate request) understand its interface and determine how to fit into the system under construction. Furthermore, an electronic catalog of reusable components and the components themselves has to be maintained. The components have to be built for reuse, a more expensive process than special purpose component construction. The study corroborates that single-component reuse is almost as expensive as development from scratch.

Realization and Improvements

This realization lead us to several new moments. First, we established the Reuse Group whose job was not only to keep and promote the reuse across the organization, but manage the electronic catalog of components and its design. The group also was responsible for the certification process, knowledge management and the knowledge transfer activities. The targeted goal of major value is not only reusing the code but sharing the knowledge of common design patterns to resolve the business as well as the technical challenges.

Another group which was established to concentrate on the component and framework design and construction. The group closely worked with the business units to build the enterprise framework for mission critical initiatives. The problem this group experienced is well documented by the known researches (references to Ralph Johnon, Wolphgang Pree). The frameworks and components do evolve and it is fairly difficult to design a flexible framework to resolve the business problem on the first try. However, there were several framework adaptation efforts for the GUI construction efforts which brought tremendous pay back to the development efforts. Still, the problem in this area also well documented (reference to Coplien) interaction between frameworks. Clearly, our experience showed the need of standardization in this area, which had begun to materialize.

ASF diagram of the patterns relationships

Thru the knowledge sharing initiative we established Pattern movement across several lines of business. The user groups were formed and the review of the design and domain patterns became a routine activity during these meetings. The groups not only reviewed and studied the design and analysis patterns, they also tried to establish the patterns technical and domain catalogs. One of the major outcome from one of these meetings came the concern for lack of business patterns on the market. While the awareness of patterns, brought the realization of proven design techniques for specific technical design resolutions, there were hardly anything in a public domain to help resolve the business problems such as designing insurance underwriting component or claim processing component.

Two patterns from GOF specifically were used in several projects to standardize the interfaces for redundant information. For example, in the institutional business area we had several different systems that had dealt with eligibility/enrollment process. Facade and Adopter patterns were introduced to deal with the common interfaces to the multiple problem domains, while reengineering the multiple sub systems and replacing it with the common component. As mentioned above, the design patterns helped dealing with the interfaces, however, the bulk of the problem is reengineering of the business problem, which had not been widely addressed by the pattern community nor by any other communities known to us.

The search for commonality lead us to the area of standardization at the meantime. We established the participation in the forums where the standardization for the industries was considered to be the primary objective. Among the groups we participated were OMG and Acord. Both of these groups were involved in resolving the business problems as we perceived them. One area of the OMG attracted our attention since it was dealing with the most emergent issue as we defined it - Business Objects. We had to establish the project charter of the importance of this concept to us, primarily from the business stand point of view.

Business Drivers

How do the business objects and/or business patterns could help the application development community? Again the answer is the reuse but not widgets but coarse grained business object (components, frameworks). The challenge was to illustrate it from the specific business problem.

The application-based approach to software development arose during the period in which business problems were relatively stable and software was relatively simple. Under these conditions, a software solution could be developed fairly rapidly to address any given business problem, and the solution could remain to be valid for some years before being retired in favor of a new and better solution. Neither of these conditions holds today. Business conditions are becoming increasingly volatile, and software is becoming ever more complex and difficult to develop. The results of these two opposing trends are that application development can no longer keep up with business problems.

Enabling application development teams, so that eliminating business backlog and empowering the faster delivery and integration are major business drivers. When business users seek short time-to-market or higher productivity, they should achieve these goals at any cost. Business Objects should help to deliver the solution better, cheaper, faster.

Business Objects

While considered by many as a concept, standardization of the business objects is essential to us of improving the time to market by providing the framework for the standard interaction and patterns the business solutions can be built on or perhaps even generated. The concept of purchasing the component from vendor and replacing it in the future with the component from another vendor is very attractive. In addition, designing the business problem from the reusable blocks which are more resilient to the technological changes as well as the specific business changes presented an immediate improvement to the organization.

The components examples that addressed the business domain problems we found in IBM’s IAA (Insurance Application Architecture) and OLIFE from ACORD. While both of these frameworks are not mature they both present the solution for our on-going domain problems. The area are of immediate concerns are the flexibility and extendibility and the main concern since both of these standards are rather based on proprietary architecture the possibility of undesirable lock in. Our level of resistance and indecisiveness would have been different if these frameworks were built on open standards such as business objects.

The road less traveled

While Business object represent the ideal way of building the business solution on the common application framework they do mainly address application architecture domain and more specifically the interfaces the developers need to use. From the discussion we have had we would like to see more of the Business Patterns movement. From the popularity gained by Design Patterns it appear puzzling that the more logical extension dealing with the business vertical domain has not been addressed. In OMG for example, the Financial SIG does concentrate on interfaces to the common vertical domains such as party, calendar and general ledger, instead of treating each one of them as a collection of business patterns which would make general ledger pattern catalog. In effect, this would benefit the designers and developers immediately.

The idea of business pattern would treat the system as white box promoting level of the awareness of best practices. In addition, such catalogs could serve as a checklist for evaluation of the off the shelf solution. The idea seems so simple and yet obvious, especially since the popularity of the Design Patterns, it seems awkward that it has not gained the momentum. We have attempted for a while to work in this area and found it a very powerful tool during our user group session. We also have had several discussions with different parties which might be interested in organizing this activity.

References

AdAPT Application Developer’s Guide, Version 1.1, March 1997, Austin Software Foundry

Gamma E., et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1994, Addison-Wesley Professional Computing Series

Pree Wolfgang, Design Patterns for Object-Oriented Software Development, 1995, Addison-Wesley Publishing Company

The Power of Frameworks: for Windows and OS/2 developers, 1995, Taligent, Inc.

Bushman B., et al., Pattern-Oriented Software Architecture, 1996, John Wiley & Sons Ltd.

Coplien J., Software Patterns, 1997, SIGS

Boehm B., http://www.uvc.com

OOPSLA'98 Business Object Workshop IV