by Dr. Jeff Sutherland

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.

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.

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).

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.

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

Interoperability of Business Objects across domains through standardization
of Business Object infrastructure to support plug and play components

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:

Productivity - Software productivity has declined on the average in the
U.S. by 13% since 1993. However, the difference between productive and
non-productive developments groups has widened from 4:1 in 1990, to 600:1
in 1995. Some organizations are making progress, most are falling farther
behind.

Reuse - The key to increased productivity is achieving 80% reuse of prebuilt
objects. The average reuse in the industry is 20% for Smalltalk, less for
other object-oriented languages. This is because most developers are using
antiquated hand coding methods. Enhancing productivity requires that coding
be automated.

Automation - A good object-oriented design tool can generate 80% of the
code for an application and reengineer existing code back into design.
Less than 10% of object-oriented developers were using these tools in 1995.

Plug and Play Components - The only widely used plug and play components
in recent years are VBX components for Visual Basic. Plug and play components
cannot exist without industry standards for component design. The two standards
that exist today are OLE 2.0 (a defacto standard) and OMG CORBA 2.0 (inadequate
for specification of design of interoperable components). IBM's DSOM is
a CORBA implementation that could become an Object Management Group (OMG)
standard. OMG BOMSIG and ANSI X3H7 Object Information Management are two
committees working on standardization of a Business Object infrastructure
based on OLE/CORBA integration.

Component Market - Since component standards do not exist, no component
market exists today. With the release of Windows 95, VBX vendors are converting
products into OCX components which comply with Microsoft's OLE 2.0 specification.
In 1996, a component market for OLE components will begin to emerge.

"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.

This page was built by Jeff Sutherland using
Dreamweaver. Your feedback is appreciated!