OOPSLA'96Business Object Workshop III


Business Objects for Front-Office Applications:
Making Domain Experts Full Partners

Jeffrey Bonar, Bonar Associates
jbonar@mindspring.com


Abstract

"Front office" applications are support tools for people interacting with customers. They include applications like Help Desks, Customer Call Centers, and Sales Force Automation. Front office applications are distinguished from other applications commonly treated in the business object literature in requiring 1) much higher levels of flexibility after they are installed, 2) administration by domain experts rather than MIS personnel, and 3) more extensive runtime browsing capabilities. This paper discusses the use of business objects for implementing front office systems. It concludes that business object architectures are well suited to front office applications, particularly if the domain experts designing and administering the business logic details can do so directly, without requiring programmers. The paper discusses what compromises could be made in a business object specification that was simple enough for non-programmer domain experts but still useful. The paper concludes with a strawman description of Easy Business Objects (EBOs) with examples of how they would work in a front office application.


1. What are front office applications?

"Front office" is a fast growing software application area focused on the creating support tools for people interacting with customers. Front-office applications include Help Desks, Customer Service Desks, Customer Call Centers, Asset Managers, and Sales Force Automation tools. Front office applications are distinguished from more traditional MIS "back-office" applications like General Ledger, Accounts Payable, Payroll, etc. in that they are require much higher levels of flexibility and are not administered by MIS personnel. Furthermore, they are also distinguished from "mission critical" applications, e.g. Credit Card processing and Order Entry, by being lower volume and less transactional in nature.

Front office applications are distinguished by the following characteristics:

2. Why are business objects relevant to front office applications?

Business objects make enormous sense in the development of front office systems. Consider the distinguishing traits listed above:

3. A simplified business object facility for domain experts

So far, I've discussed a new domain where business objects seem particularly relevant. As I began work on a full scale implementation of business objects for a next generation customer care system, the requirement for significant domain expert involvement seemed most pressing. That led to the highly simplified business object facility described here. It is explicitly designed for use by non-programmer domain experts like help desk supervisors, sales administration team leaders, and LAN operation managers.

When designing application development tools, the question is usually "How can this be designed to do everything?". My goal here is to respond to a different question, "What is the minimum functionality I can give a non-programmer domain expert to 1) define most business logic themselves and 2) interact smoothly with a programmer for the rest?" In working on that question, I developed the following guidelines for my "easy business objects" or EBOs:

Such an approach is only practical assuming access to programmers who can add to the palette presented to the domain experts. New base business object operations will need to added regularly. New patterns and composition operations much less regularly. Nonetheless, letting domain experts describe and maintain most of the business logic yields big pay-offs in customer satisfaction and rapid response to changing business conditions. Though programmers are still required for the infrastructure, the investment in that infrastructure is broadly horizontally applicable and therefore cost effective. For example, properly encapsulating a master-detail pattern that works in a disconnected scenario is hard work that must be done with a full set of programming abstractions and highly skilled programmers. Once created, however, if that pattern can be reused widely by domain experts, the infrastructure investment is easily justified.

4. Proposal for Easy Business Objects (EBOs)

The following proposal is a strawman sketch of a business object facility that follows the guidelines listed above. It is considerably simpler then those widely proposed -- compared to, for example, the submissions to the OMG Business Object Facility RFP. The simplicity is focused on making development of business logic accessible to non-programmer domain experts. This proposal makes infrastructure and personnel assumptions:

Infrastructure: This proposal assumes a sophisticated, programmer-oriented business object facility and architecture. The CORBA BOF effort, Microsoft's Visual Basic product directions (leveraging ActiveX, DCOM, MTS, etc.), or even C++ with a standard client-server/SQL environment all could serve as that infrastructure. The system described here should be viewed as a high-level tool that provides domain expert access to architectures heretofore only accessible to skilled programmers.

Personnel: This proposal requires two kinds of programmers available to assist the domain expert. Framework implementing programmers are the very sophisticated programmers needed to implement the facility in terms of a framework on top of an underlying CORBA, DCOM, or standard client-server/SQL environment. A less sophisticated set of programmers, the framework using programmers, can extend that framework using its implementation programming language. These framework users provide the base business object actions composed and organized by domain experts.

In this proposal, I expect non-programmer domain experts to work in a visual environment. While I use a notation below, I do not expect domain experts to see notation but instead to see visual browsers that allow them to browse and compose EBOs using the constructs described. The palettes of that visual environment are populated based on the concrete implementations of certain abstract classes (or interfaces in Java) in the business object facility framework. The abstract classes must be supplied by framework implementing programmers. The concrete classes are supplied by framework using programmers.

Finally, the description below includes no provision for description of clients and user interfaces. My assumption is that the output from the EBO system is a set of components meeting standard server component specifications for common client development tools. For example, the EBO environment could emit ActiveX DCOM servers for use by Visual Basic or server-side Java Beans with CORBA interfaces for use by Café or VisualAge for Java, etc. Coding the client user interface would simply mean linking visual components to emitted server components. In particular, EBO attributes are linked to GUI controls. As the controls are manipulated on the client the EBO attributes are changed. Similarly, as attributes change in the business object instance on the server, the client user interface tracks those changes. This is the standard paradigm for a wide variety of client oriented application development tools (e.g. Visual Basic, Powerbuilder, etc.). Notifications from client controls to and from server business object instance attributes drive the constructs described below.

I propose the following constructs for EBOs:

  1. An SBO can define arbitrary attributes. Each attribute must be typed using a pallete of types. The type palette can be extended by framework users. So, for example:

    Define Customer SBO
    Customer has a Name attribute of type Text(30)
    Customer has a Phone attribute of type Phone
    Customer has a CustomerID attribute of type XYZCorpCustID
  2. (Remember, don't worry about the notation. A practical implementation of this proposal would be entirely visual.)

  3. An SBO can define attributes in terms of other attributes. In particular, an attribute can be an aggregate of all values for a particular attribute in a collection (e.g. Sum, Average, etc.):

    Customer has a CatalogCode attribute of type Text(50)
    defined as LastName + Zip

    Customer has a OutstandingBalance attribute of type Currency
    defined as CurrentCharges + PastDueCharges

    Customer has a TotalDue attribute of type Currency
    defined as Sum(CurrentCharges)
  4. An EBO can be composed of other EBOs, optionally allowing 1-n relationships or subpart relationships (including recursion):

    Define TroubleTicket EBO
    composing Customer, HelpDeskTechnician, ProblemReport

    Define Invoice EBO
    composing Customer, many OrderItem

    Define SalesTerritory EBO
    as hierarchy of SalesTerritory
    bottoming by composing many Customer, SalesPerson

    Note that there are implicit join-like operations and use of unique keys implied by these definitions. These could be supplied by a framework using programmer creating the base objects or by special definitions available to domain experts.
  5. An EBO can be defined using restriction and sorting. The SBO can be parameterized to generalize the restriction and sorting operations.

    Define 1997Invoice EBO as Invoices
    where Year = 1997 sorted by Month, Day

    Define YearlyInvoice(Y) EBO as Invoices
    where Year = Y sorted by Month, Day

    Define SalesPersonInvoice(Y,S) EBO
    as many Invoices, SalesPerson
    where Invoices.Year = Y
    and S = SalesPerson.ID

    Define OpenTicket as TroubleTicket
    where Status = Open

    Define UrgentTicket as TroubleTicket
    where ServiceAgreement = A and MinutesOpen > 60

    Remember that the specification is high-level: defining these derivative EBOs makes no specific commitment to the details of an implementation. Also note that the parameterized EBOs essentially are exposing attributes to the client environment that must be set at runtime before the EBO instances can be used. If those attributes are reset while an application is running, the set of available instances is changed.
  6. Every EBO implicitly supplies an enumeration of the instances that meet its specification. That enumeration always has a current instance explicitly accessible as the attribute Current. The run-time values of the attributes are set by the current instance. The current instance can be moved with standard First, Last, Next, and Previous operations. The count of instances can be determined with the standard attribute Count.
  7. Similarly the Hierarchy of Parts pattern can be captured with implicit enumeration of child instances. This is done by augmenting the enumeration operations with FirstChild, LastChild -- stepping into the beginning and end of an enumeration of child instances -- and BackToParent -- returns to current instance when last FirstChild or LastChild was executed. Also a new standard attribute ChildCount is needed.
  8. Every EBO can define actions based on watching attribute values:

    When Invoice.Paid
    perform SalesPerson.NotifyPaid(Invoice)

    When TroubleTicket.MinutesOpen >240
    perform TroubleTicket.NotifySupervisor

    The first specification defines an action that will be taken when any Invoice instance is paid. The operation will be performed on any instance of Invoice whose Paid attribute become True. Operations like NotifyPaid and NotifySupervisor must be supplied by a framework using programmer.
  9. EBOs can also act like workflow queues of instances with the following conventions. Define each of the workflow queues as a restriction EBO based on some status flag. As the status flag is changed, the instances are implicitly moved among the restriction EBOs. Actions are performed on the current instance, and the current instance is the first unless explicit positioning has been done. Because the business logic is implicitly fired based on the attribute values of the current instance, a complete (but admittedly lightweight) workflow environment is enabled.

Of course these constructs all assume that framework creating programmer has built three elements. First, there must be a visual environment to define EBOs. Second, there must be a compiler that creates infrastructure: design and runtime components for use in real world client side tools, middleware, and deployment environments. Third, there must be a set of utilities that perform initialization, backup, translation from one version of business objects to the next, etc.

5. Conclusions

Business object designs usually focus on application development for large-scale mission critical transaction software systems. Front office applications are one of the fastest growing segments of corporate software, and have different requirements. Most significantly, front office applications are more browsing oriented, they are changed more often, and they are administered by end users rather than MIS personnel. This paper discussed those requirements and how they might be addressed with business objects.

In the second part of the paper I discuss how to make the maintenance of front office application logic, expressed as business objects, maintainable by domain expert non-programmers. Current business object facility proposals are too hard for domain experts, requiring their knowledge be interpreted by programmers.  I provided a high level sketch of a set of business object constructs called Easy Business Objects or EBOs. These constructs are simple enough to be used directly by domain experts, yet still minimize the work required from programmers. Activities like the OMG Business Object Facility standardization are focused on sophisticated programmer oriented specifications. The EBO facilities described in this paper are meant to be defined on top of such standards.


OOPSLA'96Business Object Workshop III