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.
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.
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.
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.
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.
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.
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).
Business Object programmers focus their efforts on building business components, or large-grained Business Objects, which can be easily distributed on the network.
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.
· Engineering from design (not hacking code)
· Standard OOAD methodologies
· Automated generation of code for standardized languages and interfaces
· 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 promise of object-technology has not been achieved during the last decade due the following factors:
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.
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.