Jeff SutherlandSCRUM

The Object Technology Architecture:

Business Objects for Corporate Information Systems

by Dr. Jeff Sutherland

In Sutherland, J.V. , Patel, D., Casanave, C., Miller, J., Hollowell, G., (Eds.) Business Object Design and Implementation. Springer, 1997.
Home Page: http://www.jeffsutherland.com/

Why Business Objects?

"RADICAL SURGERY is needed in IS processes. One of the first ideas that will have to go is the whole notion of traditional systems development life cycles." Michael Hammer

The global market has become an intensely competitive environment moving at an accelerating rate of change. To gain the strategic advantages of speed and flexibility, corporations must remodel their business processes, then rapidly translate that model into software implementations.

Business Process Reengineering (BPR) sets the stage for continuous evolution of business processes to meet rapidly evolving business requirements. Implementation of software systems that support BPR requires Business Objects that can both simulate corporate procedures and translate smoothly into software objects. Well-designed Business Object implementations can be easily modified as the business changes. 

What Are Business Objects?

Technically, business objects encapsulate traditional lower-level objects that implement a business process (i.e., they are a collection of lower-level objects that behave as single, reusable units). User interfaces can be thought of as views of large-grained Business Objects. Databases maintain a record of the "state" of Business Objects as they change over time.
Business Object
Figure 1: A Business Object 

The Need for a Business Object Architecture

As business models are renewed, software architectures must be transformed. A Business Object Architecture (BOA) is an effective solution for dynamic automation of a rapidly evolving business environment.

Dynamic change requires reuse of chunks of business functionality. A BOA must support reusable, plug-compatible business components. The two primary strategies now being used for implementing client/server systems to support reengineering of business processes are Visual 4th Generation Languages and classical object technology. While both of these approaches are better than COBOL, neither of them can implement Business Objects. Visual 4GLs generate the Powerblender Syndrome -- Write all your business logic in proprietary procedural code and embed it in user interfaces or "GUI objects." Classical object technology produces the Rigatoni Effect. Proliferation of objects without constraints on complexity results in a message path explosion within an object system. This produces unmaintainable code. Even experienced object-oriented programmers find it easier to create this problem rather than implement a Business Object Architecture. We don't have spaghetti code in object systems. We have little balls of rigatoni that stick together producing mush, the result of poor design of object components. Classical object technology is really an assembly language that we can use to build a BOA.

Because of these problems, current attempts at software implementation of reenginneered businesses processes are not very successful.

"The shining examples of reengineering glory remain few and far between, and a recent study of IT systems-development efforts asserts a failure sinkhole equal to roughly an $80 billion sucking sound." Lew McCreary, Editor, CIO/Webmaster Supplement. 

Reduced Cycle Time Is the Prime Directive

The goal of a Business Object Architecture is rapid deployment of reengineered business processes and rapid redeployment of new or enhanced functionality as the business changes. Dramatic examples of this can be found on Wall Street, where a new financial instrument can be defined, implemented, and traded with a one-week turnaround.

Some of the best data in the industry on productivity has been collected by Capers Jones of Software Productivity Research, Inc. Detailed information has been collected on over 6,000 products and is used as a reference database for software project estimation. The Software Productivity Research (SPR) data indicates that reusability of code for C is 15%. This reuse factor is about the same for other 3rd and 4th generation languages. For an object-oriented language like Smalltalk, it is possible to get 50% reuse in year 2 and 80% reuse is achievable in year 3.

SPR data show that COBOL is twice as productive as C. A 4th Generation Language doubles the productivity of COBOL. Smalltalk can be twice as productive as a 4GL, but only when 80% reuse is achievable. 

Return on Investment Depends on Reduced Cycle Time

Flexibility and Adaptability

The primary reason many large users adopt object technology is not reduced costs of implementation. The largest returns are captured by faster time to market with new products and services, and faster enhancement and extension of those services compared to competitors. For example, last year a $500M division of Bankers Trust in New York increased revenue by 30-40% and saved the bank hundreds of thousands of dollars in inaccurately entered trades using Object Studio, an advanced development environment for Business Object design and implementation.

Scalability

Business Object Architectures support scalability better than conventional systems. A small system can be scaled up to large numbers of users and gigabytes of data faster, easier, and cheaper.

On a large European project in 1990, James Martin Associates was hired to provide an independent review of a Business Object system by the world's largest aircraft leasing company. They reported that as the object system was scaled into production and performance bottlenecks forced redesign of subsystems, the object model could be restructured quickly to improve performance without compromising system design. No other technology they had seen could do this, and they reported that scalability was the greatest benefit of object technology.

Ease of scalability depends on a visual representation of an object model. A Business Object Architecture is largely generated from the design and reengineered at the design level. Business Object Management Tools are required because novices cannot build a BOA without them and experts will not spend the time required to do it manually.

Reusability

Flexibility, reduced cycle time, and lower costs are all dependent on reusability of Business Objects. Reusability has been difficult to achieve on early object-oriented projects because class libraries are not inherently very reusable. Searching through a class library, and understanding the details of code used to build the classes, can often cost more than rebuilding the classes from scratch.

This problem is now being solved by Business Object Management Tools that capture the design, documentation, and code as a system is being developed. Changes at the code level are automatically synchronized with design documents. Components built of groups of collaborating objects are specified at the business level. These components are objects that have all the characteristics of fine-grain objects allowing them to be reused as is, or easily modified through specialization through inheritance. 

Building Business Object Components

A group of objects is the ideal unit of reuse. These groups of objects should behave as a higher-level business process and have a clearly specified business language interface. Business components are encapsulated with a protocol that allows efficient communication with other objects on the network.

Consider a typical client/server application like an order entry system. This system takes a Purchase Order as input and produces a validated order as output. The internals of this component should be a black box to the external world. The resulting order is input for another subsystem or, alternatively, an exception condition is raised if the Purchase Order is not valid for processing.

Component
Figure 2: An Order Entry Business Object

To support plug-compatible reuse, a business component must be encapsulated in two directions. The external world must not know anything about component internals, and the internals must not know anything about external components, other than allowing interested objects to register for notification of specific events or exception conditions.

The internals of a business component are made of other encapsulated business components. For example, when a Purchase Order passes through the membrane of the Order Entry business object, an internal component must see it, validate it, look up customer information, inventory availability and catalogue pricing, and build an order that is consistent with business rules and procedures. Each of these tasks is accomplished by embedded components, many of them communicating with external data sources.

External databases must be encapsulated as Business Objects or reuse will not be easily achievable. There must be a database access component that causes values from any kind of database to materialize as objects inside the business component. Whether object-oriented, relational, or other database access is required, a set of class libraries designed to automate this interface will result in a major savings in development resources.

An Order Entry business object will typically have multiple user interfaces. A clerk may be taking the order over the phone, entering purchase information, validating customer records and credit data, and reviewing an order for consistency and customer acceptance. Other users may require different presentation screens. User interfaces are difficult and time consuming to build at the code level. Today, much of this process can be automated. They should be encapsulated as separate objects that communicate by message passing to the Order Entry object. Failure to do this will limit reuse and waste valuable programmer time on laborious, time consuming maintenance tasks. Users should be able to create interface objects with simple object-oriented tools. Subsequently, the programmer should be able to easily snap user interface objects onto the Order Entry object.

A simple Order Entry client/server component has at least three large-grained components, one or more presentation objects, a business component that models the business process, and a database access component that shields the application developer from database access languages, database internals, and network communications (see Figure 3).

Client Server Component
Figure 3: Client-Server Component

Business Object programmers focus their efforts on building business components, or large-grained Business Objects, which can be easily distributed on the network.

Distributing Business Objects

System evolution will invariably distribute these Business Objects to maximize network performance and processor utilization, and to ensure proper control, integrity, and security of information. Business reengineering implies implementing a distributed environment where components encapsulating business functionality can be migrated to nodes on the network that allow maximum flexibility, scalability, and maintainability of a Business Object system.
Distributed Components
Figure 4: Application Business Object with Nested Client/Server Components

Business objects made up of nested components allow distribution of these components across a network. Figure 4 shows the logical application as a coherent set of nested client/server components. Deployment of this large-grained object may include distributing subcomponents across multiple heterogeneous computing resources in dispersed locations. Thus, an application designed on one processor is scattered across a network at run time. 

Requirements for Capturing Business Object Benefits

Rapid deployment of a Business Process Architecture is the key to return on investment in object technology. This will not happen unless the Business Object development environment supports:

· Engineering from design (not hacking code)

· Standard OOAD methodologies

· Automated generation of code for standardized languages and interfaces

Scalability of a Business Object Architecture is a requirement for putting mission-critical systems into production. The Architecture must support:

· Recursively nested components that scale to any size

· Distribution of these components across heterogeneous networked systems

Reusability of Business Object Components is essential to achieving reduced cycle time. The Business Object Architecture must support:

· Continuous Business Process Reengineering

· Controlled complexity through Business Components

· Code changes reflected back into design environment so that current design, documentation, and code can be continuously captured in an evolving object model.

· Legacy system connectivity so that older systems can be encapsulated as a Business Object Components.

Tools and methodologies for building distributed Business Objects are now emerging in new advanced application development tools. The ability of object-oriented software tool vendors to support robust development environments for design, assembly, and reuse of Business Objects is now enabling more widespread use of a Business Object Architecture in corporate development environments. 

The Need for a Business Object Component Infrastructure

In 1986, Brad Cox argued that software objects could be produced like integrated circuits and capture the benefits of Moore's law - the number of components on a silicon integrated chip doubles every year. By analogy, software productivity should double every year as off-the-shelf, plug compatible, software components increase in functionality.

The promise of object-technology has not been achieved during the last decade due the following factors:

"Object technology failed to deliver on the promise of reuse. Visual Basic's custom controls succeeded. What role will object-oriented programming play in the component-software revolution that's now finally under way?" John Udell, Byte Cover Story, May, 1994.

Developers of business information systems are beginning to take advantage of building applications with OLE components. At Object World in San Francisco, Allied Signal won the Computerworld Award for best object-oriented application of 1995. They reengineered the Supply Management Business Process that took 52 steps to purchase a single part, so it now requires only three steps to complete the same transaction. The old process required seven people and took nine weeks to produce an approved purchase order. The new Supply Managment Specialist Tool (SMST), developed with the Object Studio advanced development environment, allows one person to complete the same process in nine minutes for established suppliers with long-term agreements in place. In the case of new suppliers, where a Request For Quote (RFQ) is required, the process takes nine days.

In this example, cycle time of the process is reduced 2400:1 for established suppliers, and 5:1 for new suppliers. Cost reduction is operational staff is 7:1. The impact of improvement in business efficiency leading to greater customer satisfaction and resulting market share is far greater than any reduced costs in operations overhead or development time and is the major motivator for the use of Business Object design tools to assure success of Business Process reengineering practice.

By 1997, it will be possible to buy 50% of an application as off-the-shelf components, effectively doubling productivity. By 1998, early adopters will be buying 50% of the application as external components and reusing internally generated components for another 25% of the application, effectively doubling productivity on an annual basis, and beginning to comply with Moore's law for IC chip design. Brad Cox's vision of software as IC chips will begin to be realized. 

Conclusion

Corporations that take advantage of Business Object Architectures will significantly shorten product cycles. Consulting groups that use Business Objects will significantly underbid their competition and deliver new systems on time and under budget. Because a Business Object Architecture will allow software to change as rapidly as the underlying business processes, corporate viability will be enhanced by early implementation. Laggards will be easily outmaneuvered in the marketplace by enterprises already embarked on large-scale implementation of global distributed object systems. 

Jeff SutherlandSCRUM
This page was built by Jeff Sutherland using Dreamweaver. Your feedback is appreciated! jsutherland@vmark.com
Copyright 1996-99 Jeff Sutherland