OOPSLA'96Business Object Workshop III


Business Object Management Architecture

Chris Marshall (chris_marshall@sesh.com)


Abstract

This paper describes a set of concepts by which an enterprise may be modeled. The purpose of the enterprise is defined by its vision, missions, goals and objectives. Business processes define the way in which this purpose is achieved. Resources are the things created and used to perform business processes, and organizations provide the framework within which business processes and resources are managed. This approach ensures that processes focus on achieving purpose through optimal management of available resources. The concepts have been implemented in Java to illustrate the feasibility of the approach.

Keywords

Business engineering, enterprise engineering, business object, business process, object technology, Java, OMG, BPR, ERP, SCM


Boma is the Swahili word for an armed enclosure in which livestock, the African store of wealth, is held. A boma may also enclose huts, grain, weapons, and other items that need protection and controlled use. It is a metaphor for the business object management architecture, or BOMA, by which to manage the wealth of information, rules, knowledge and other intellectual capital of an enterprise.

The first part describes the BOMA business object model with reference to work by I Jacobson, E Jaques, PM Senge, O Sims, D Taylor and other writers in the field of enterprise engineering. The BOMA model identifies distinct concepts by which businesses can be modeled, each of which is well understood by business people.

Competitive pressure is forcing companies to rethink the way in which they do business, and even the business that they do. The need for a coherent business strategy has never been greater, but the future has never been less certain. However, the company that focuses on adding value to its customers is likely to succeed, and its strategy must be to identify and implement processes that maximize that value. Modern application packages seek to deliver software to support these processes using a number of approaches, most of which are implemented by large monolithic modules which may be used with varying degrees of flexibility. A particular enterprise will typically use less than 30% of the features offered by such a product, but will still only achieve an 80% fit to its needs. Unfortunately, gap of 20% is often in those processes by which it differentiates itself from its competitors in order to gain competitive advantage. It is difficult to see how one can use information technology to differentiate if one implements the same software package as one's competitors.

An alternative approach is to develop or extend customized software using the sophisticated development tools available today. These tools tend to focus on solving the technical problems of analysis and design, database definition, and layout of user interfaces and reports, with little or no support for the business requirements. This is particularly true for businesses that are migrating from a traditional functional to a process centered organization, and for requirements that span between enterprises. Unfortunately, there are insufficient people who have the business knowledge and the technical skills to analyze, design and implement large scale information systems that exploit modern distributed technologies.

A third approach is to create a model of the enterprise from which a suitable information system is automatically generated and maintained. This is the ambitious goal of BOMA, Dave Taylor's Enterprise Engine, Oracle's Sedona project, and a number of other initiatives. The advantage of such an approach is that people who know the business are able to create systems without having to understand the underlying technologies, and without having to use technologists. Each has a somewhat different approach as the underlying concepts are not yet fully defined or standardized, although some work done in this direction by the OMG's Business Object Domain Task Force (BODTF). Modern business concepts are based on systems thinking, which requires the ability to envision, create and use sophisticated mental models of the world. BOMA creates and uses models of business purpose, process, resources and organization.

The purpose of the enterprise is defined by its vision, missions, goals and objectives. High level vision and missions are abstract, of long duration, and difficult to quantify. They are supported by lower level objectives which tend to be well defined, of short duration, and precisely measurable. Each purpose may have one or more measures by which it is planned, simulated and tracked. Each measure typically has internal standard values and references to industry and competitive norms or benchmarks. Operations simulate different purpose scenarios, perform sensitivity, ratio and other forms of what if? analysis, and visualize and evaluate alternatives. A business defines its purpose in order to do the right things.

Business processes define the way in which the purpose is (to be) achieved. Processes may be informal with little or no system support, rigorously structured with a high degree of automation, or anywhere in between. Business process engineering improves processes using formal modeling techniques and notations, and identifies how technology may be used to enable the redesigned processes. Process design typically requires a top down decomposition of high level processes into sub-processes down to atomic process steps. The relationship between these process steps may be more complex than the simple precedence of project networks, or the and/or split and join of conventional workflow systems. Process branching and synchronization is driven by business requirements, and is increasingly required between as well as within organizations.

Each process step typically requires one or more resources. Administrative processes require human resources while production processes require machines, materials, tools and specifications. A process defines these requirements in terms of capabilities rather than individual resources. For example, an invoice requires the invoicing capability (or role), a print operation requires a printing capability rather that a particular printer, and so on. A business designs its processes in order to do things right.

Resources are the things created and used by an organization to perform business processes. Most resources are physical things such as people, machines, vehicles, materials and products. Less tangible resources such as designs, specifications, and licenses and contracts with suppliers and customers are also of value to the organization. The behavior of resources may be sophisticated but is typically stable, so may be reused once it is understood and defined. A resource is best modeled in terms of the roles which it is required to play, which are defined by its properties. Resource properties include business partner, product, financial ledger, address, unit of measure, currency, price and cost, and so on, many of which may be standardized within and between organizations.

Organizations provide the framework within which business purpose, processes and resources are managed. An organization unit may manage other units in a hierarchy in order to control complexity and achieve shared purpose. Organizations are often structured according to geographic location so they provide a useful context for distributing work and associated systems. Each unit is able and authorized to initiate and manage certain business processes, and to take part in processes managed by other units. A unit also schedules its resources to perform these processes according to the capability, capacity and cost of each. For example, it might manage administrative workflow to minimize wait times, and schedule its production capacity to minimize overall cost.

The somewhat facile diagram shows an organization which adds value via its processes, resources and a subsidiary branch network. A purpose hierarchy, which could be implemented by a financial ledger or a data warehouse, is used to set budgets or targets and to measure results.

The second part describes relevant aspects of object technology with reference to work by G Booch, I Graham, I Jacobson, H Kilov and J Ross, D Kroenke, B Meyer, J Rumbaugh and other writers in the field of object oriented software engineering. Reference is made to the OMG, IBM's SanFrancisco project, and Oracle's Network Computing Architecture.

In the past much effort has been on the technical aspects of database design, process flow, user interface issues, and so on. While important, this work is meaningless unless directed towards the needs of the business. Object technology has been used to simulate complex engineering systems for many decades, and has recently been applied to model business systems. It is used to extend traditional information engineering and data modeling concepts to create semantic object models of business concepts and things. These business objects are used to create distributed business information systems.

Object concepts summarize the relationship between sets, types, classes and interfaces. An interface is a contract between the supplier and user of an object which enables software to be industrialized. Open standards are essential to realize this potential. A brief overview of Java, CORBA and DCOM object standards, and of UML and OPEN notations, is useful for the business reader.

Java has gained rapid and wide acceptance as the language for business objects because of its simplicity, portability, power, and the familiarity and safety of its C syntax without the dangers of pointers and application level memory management. Much of its power derives from standardized packages of related classes that provide many high level services via simple, consistent and documented interfaces. These continue to evolve at an incredible rate, but the core functionality of JDK, JDBC and other such packages is sufficiently stable for production use. Improved user interface classes and Java Beans promise to match the capabilities of alternative GUI technology in the near future. Java objects may be distributed across a network via remote method invocation (RMI).

Other system services for persistence, transactions, security and so on are becoming available, typically conforming to the CORBAServices standards promulgated by the OMG. If not yet available, it is relatively simple to wrap existing services in a Java interface that complies with these standards. This trend is expected to continue as more companies adopt the OMG standards, which will allow an enterprise to select "best of breed" object services from alternate suppliers. Objects implemented in Java, C++, Smalltalk and other languages may be distributed across a network via a CORBA compliant object request broker (ORB).

The IBM San Francisco project provides a base set of object oriented infrastructure written in Java which may be extended in a number of ways to deliver enterprise software. It uses RMI for its communication infrastructure, a base layer for object management and services, a common business object layer for standard application components, and a set of core business processes which may be further refined to suit specific industry and enterprise needs. The common business objects may be offered to the OMG for standardization.

The Oracle Network Computing Architecture provides a set of Java tools and components to build systems across database, application and client tiers. Oracle calls these components "cartridges" which plug into a CORBA compliant ORB and make use of database, application and client services. Database access is via standard JDBC, or JSQL, which provides a preprocessor to translate high level SQL into Java with equivalent calls to JDBC. The SQL syntax in Oracle 8 has been extended for objects having globally unique IDs to be defined as types within the database, and to be activated as Java objects.

The third part describes how BOMA business objects are implemented in Java. This includes a description of the standard components and tools, and of specific types of business object.

The BOMA approach is to provide business engineering tools and components in 100% pure Java. The goal is to maximize portability, reusability and interoperability of BOMA business objects in any modern distributed computing environment, and with other Java or CORBA compliant software. Particular care has been taken to the classification and design of objects to make best use of the features, and to minimize the disadvantages, of Java/CORBA systems. BOMA objects specify only the structure and behavior of the business requirements, not of the technology.

A BOMA business object is a pure Java class with particular emphasis on the documentation of its interface. Javadoc conventions are used throughout to produce HTML technical specifications in the standard Java format. The standard Javadoc keywords have been extended for other purposes such as version control, user help definition, formatting pictures, access specification, and so on. The information is optional, but it allows integration of data that would otherwise have to be maintained elsewhere.

The BOMA Business Architect is a software tool designed to support formal business engineering in order to define the purpose of the business, design supporting processes, and model resources and organizations. It creates diagrams using the UML notation of purpose and organization hierarchies, process flow, object structure and interaction , and other views directly from the Java classes by which they are implemented. Introspection and reflection enable the tool to query the class interfaces, and Javadoc conventions provide the additional information (eg version) that is required. This has removed the need for a separate repository of design information, or any other form of metadata such as a workflow scripting language.

The Business Architect pre-processor automatically creates SQL DDL statements and inserts the appropriate JDBC calls for persistent BOMA objects. These have optimistic attribute level locking to minimize contention in large systems. Other code is created to enforce security for each attribute and method, to expand class names, and to add routine exception handling (eg RMI exceptions). All affected classes are compiled using javac, and those that are to be invoked over the network are post-processed for RMI or IDL under the control of the Business Architect. This entirely relieves the business programmer of all the complex programming and configuration issues of a distributed object system.

BOMA business objects created in this way are supported by a package of Java service objects which support large scale semantic objects in a multi tier distributed object framework. Attributes may be elementary values, references to other objects, or multi-values representing lists, lookups and collections of other values or objects. New versions of classes and instances are managed within baselines until committed to the live system, which allows fail safe testing of change deltas without significant replication of objects. A facility automatically removes persistent objects that are no longer referenced, and other such routine maintenance is done by service objects.

The BOMA HyperClient is a product that regards a human user as a type of object that needs a number of specialized interfaces and documents. It automatically and dynamically creates user interfaces, online help, specifications, documents and reports from Java objects. For transaction and inquiry purposes, it creates a window to display the public attributes of a Java class using standard visual controls. String and numeric attributes are mapped to text controls of an appropriate size. Boolean attributes are represented by check boxes, lists by drop-down combo boxes, and so on.

A multi-valued property is displayed in a table that has a column for each attribute, and that has a subsidiary form by which they are accessed. More complex attributes are automatically mapped to suitable visual controls, for example, a hierarchical object is represented by a tree control by default.

The public methods of a class are listed in a pop-up menu invoked by clicking the right mouse button over the relevant object or attribute. The interface created in this way is extremely consistent and simple to use as it is created according to the policy specified in the HyperClient, not by the individual preference of a programmer. It also ensures consistency between the interface used by other objects and by human users, particularly with respect to security. The interface is dynamic so that it can change according to each object instance and to the role(s) that the user is assigned.

The HyperClient interacts with remote clients using standard Web browsers via the Internet. A proxy server is used for each user to create dynamic documents in which an HTML template provides the static content, and the dynamic content is supplied by Java objects. Hyperlinks define the relationship between the template and the method or attribute that supplies dynamic content. Templates may be created and modified using standard Web authoring tools. Responses from the remote user, if any, are translated into requests to the appropriate Java object by the proxy server.

The HyperClient also creates an HTML document directly from a Java object in much the same way as it creates a user interface. Each attribute is mapped into the appropriate HTML format, including tables, pictures and other attributes. If the layout and appearance of the default document is not acceptable, a template may be generated and edited to suit requirements. Hyperlinks in the template are again used to indicate the dynamic content to be supplied by a Java object.

This approach is used to create classes that model each of the concepts described in the first section. BOMA purpose objects model a hierarchy of purpose, detailing their description, measures, standards, benchmarks and dependencies. This information is used for forecasting, budgeting, evaluating scenarios, and other forms of strategic and tactical planning. It also forms one axis (or dimension) of a data warehouse to measure the state of the enterprise. Other axes for process, resource, organization and time periods are used to organize data posted from business processes for management information and decision support systems. A financial ledger is a specialized form of data warehouse in which the segments of an account code serve the same purpose as the values on the axes of a data warehouse.

Business processes are defined in BOMA by Java classes which inherit from an abstract generic process class which implements behavior common to all processes. This includes the creation of process instances, their assignment to appropriate workflow roles, management of their status, monitoring of their progress, and so on. The generic process class also enforces role based security and ensures that values posted to financial ledgers are in balance. It is further specialized to support order, folder, document and other process archetypes. These in turn are further refined into the specific processes required by an enterprise.

Resource objects are models of the real world concepts and things that are used by business processes. A BOMA resource is a collection of properties which may extend and contract over time depending on its responsibilities. For example, the first contact with a company might be registered by a sales lead property. Subsequent negotiations might add the customer property, an account receivable property, and so on. Should the company also supply goods or services, it would need supplier and accounts payable properties. BOMA has a substantial library of reusable resource properties written in Java for many business situations. Legacy systems are treated as resource objects in BOMA. A number of techniques are used to wrap applications and databases in Java object interfaces in such a way that they may be used in business processes like any other resource.

BOMA organization objects manage processes, resources and subsidiary units. Each unit has a list of processes that it can initiate, and a collection of resources with which they are performed. A unit is responsible for scheduling its resources to process instances according to the organization roles required. This ranges from the simple "in-tray" management of workflow systems, to the allocation of machine capacity according to complex production rules. Organization units also provide the context for partitioning objects between computers in distributed systems because purpose, process and resource objects are each associated with a single organization unit. BOMA uses hierarchical trees as well as ordered lists to manage these objects.

A BOMA system typically comprises a number of domains, each of which has a repository of Java classes, and one or more persistent object stores. Object persistence is normally provided by one or more standard SQL databases via JDBC drivers, which need not be on the same computer as the Java classes. Clients may be PCs or NCs and must use the HyperClient or an Internet browser via the proxy server. A user of the system logs into an object having his work list, a collection of processes that he may initiate, and a list of hyperlinks to his "favorite" objects, which typically includes the data warehouse(s) for queries and reports.

Conclusion

Java has proven to be an effective means by which to create business objects using the BOMA approach. Certain liberties have been taken with the Javadoc conventions in order to avoid a separate repository of metadata, and to facilitate user interface, help, report and other documents. This is desirable if one is to retain independence from any particular vendor, at least until such time as "plug and play" standards for business objects have been defined and agreed. By automating many of the technical programming tasks, and by using semantic object modeling, the definition of business objects is very simple and results in robust underlying object models and data schemas. This is well within the capability of most business analysts, particularly when using tools such as the Business Architect and HyperClient. Detailed attention to interface specifications using an extended Javadoc syntax has encouraged designers to think in terms of the responsibilities of classes, which has facilitated communication with users.

The performance of a BOMA system is still marginal for certain very high volume OLTP applications unless good client hardware is used. Careful thought must be given to partitioning of objects in a distributed system in order to minimize network latency, and indiscriminate use of RMI is inadvisable. Activation, access and update of persistent Java objects using SQL tables are fast and reliable, and do not suffer from "impedance mismatch" if semantic object modeling techniques are used. It is both feasible and desirable to create user interfaces, documents and reports, help and specifications, and other views directly from Java classes. Should these defaults not be acceptable, templates may be created and then edited to suit requirements. By using HTML and Java, standard low cost authoring and layout tools can be used, often by end users themselves.

Author: Chris Marshall (chris_marshall@sesh.com)

Chris Marshall is a director of a number of software companies that have been active and successful for many years in delivering mission critical, enterprise wide information systems using object technology. He has been responsible for managing the development of large scale manufacturing, engineering and accounting systems in C for UNIX, and more recently in Java, for companies throughout Southern Africa. He was previously a general manager of a number of divisions of the largest manufacturing company in South Africa, and before that developed power systems software and managed projects on the Zambezi. He has an MBA from the University of Cape Town, and MA Mechanical Sciences from Cambridge in England. He is a member of a number of professional bodies, and has contributed to the business object domain task force of the Object Management Group.

Bibliography

[BOMSIG 1995] Object Management Group BOMSIG, Business Applications Architecture, 1995

[Booch 1994] Grady Booch, Object-Oriented Analysis and Design with Applications, Benjamin Cummins, 1994.

[Brockschmidt 1994] Kraig Brockschmidt, Inside OLE2, Microsoft Press, 1994

[Chen 1976] Peter Chen, The Entity-Relationship Model: Towards a Unified View of Data, ACM Transactions on Database Systems, March 1976.

[CMU/SEI-92-TR-7] Watts S Humphrey, Introduction to Software Process Improvement, Carnegie-Mellon University: Software Engineering Institute, June 1992.

[CMU/SEI-93-TR-23] Alan Brown et al, Reference Model for Project Support Environments (Version 2.0), Carnegie-Mellon University: Software Engineering Institute, November 1993.

[Cox 1986] Brad J Cox, Object Oriented Programming: An Evolutionary Approach, Addison-Wesley, 1986

[Crosby 1979] Philip B Crosby, Quality is Free: The Art of Making Quality Certain, McGraw-Hill, 1979

[Enterprise 1995] The Enterprise Project, Ontology ENTERPRISE-V0.1, AIAI, 1995

[Finkelstein et al 1994] Anthony Finkelstein et al, Software Process Modelling and Technology, Research Studies Press, 1994

[Graham 1995] Ian Graham, Migrating to Object Technology, Addison-Wesley, 1995

[Hammer and Champy 1993] Michael Hammer and James Champy, Reengineering the Corporation: A Manifesto for Business Revolution, Nicholas Brealey, 1993.

[IEEE 1991] IEEE Software, Software Process Improvement at Hughes Aircraft, IEEE, July 1991

[ISO 9000-1 1994] International Standards Instition, Quality management and quality assuranse standards, ISO 9000-1:1994

[Jacobson 1995] Ivar Jacobson et al, The Object Advantage: Business Process Reengineering with Object Technology, Addison Wesley, 1995

[Jaques 1989] E Jaques, Requisite Organisation - the CEO's Guide to Creative Structure and Leadership, Cason Hall and Co, 1989

[Kilov and Ross 1994] Haim Kilov and James Ross, Information Modeling: An Object Oriented Approach, Prentice Hall, 1994

[Kroenke 1992] David M Kroenke, Database Processing: Fundamentals, Design, Implementation, MacMillan, 1992

[Martin 1992] James Martin, Rapid Application Development, Prentice Hall, 1992.

[Meyer 1988] Bertrand Meyer, Object-oriented Software Construction, Prentice-Hall, 1988

[Microsoft 1992] Microsoft Press, The Windows Interface, Microsoft Press, 1992

[Mowbray and Zahavi] Thomas J Mowbray and Ron Zahavi, The Essential CORBA: Systems Integration Using Distributed Objects, John Wiley & Sons, 1995

[OMG 1991] Object Management Group, The Common Object Request Broker: Architecture and Specification, Object Management Group, 1991

[OMG 1992] Object Management Group, Object Management Architecture Guide, Object Management Group, 1992

[OMG 1995] Object Management Group, CORBAservices: Comon Object Services Specification, Object Management Group, 1995

[OMG Mfg] Object Management Group, Manufacturing Domain Task Force Glossary, Object Management Group, 1997

[Rumbaugh et al 1991] James Rumbaugh et al, Object-Oriented Modeling and Design, Prentice-Hall, 1991

[Schonberger 1982] Richard J Schonberger, Japanese Manufacturing Techniques, Free Press, 1982

[Senge 1990] Peter M Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, Doubleday Currency, 1990

[Sims 1994] Oliver Sims, Business Objects: Delivering Cooperative Objects for Client-Server, McGraw-Hill, 1994

[Taylor 1995] David A Taylor, Business Engineering with Object Technology, John Wiley & Sons, 1995

[Booch, Rumbaugh and Jacobson 1996] Grady Booch, James Rumbaugh and Ivar Jacobson, The Unified Modeling Language for Object Oriented Development, Rational Software Corporation, 1996

[White and Fischer 1994] Thomas E White and Layna Fischer, New Tools for New Times: The Workflow Paradigm, Future Strategies, 1994.

[WfMC 1995] Workflow Management Coalition, The Workflow Reference Model, Workflow Management Coalition, March 1995.


OOPSLA'96Business Object Workshop III