"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.
"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:
Business objects make enormous sense in the development of front office systems. Consider the distinguishing traits listed above:
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.
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:
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
(Remember, don't worry about the notation. A practical implementation of this proposal would be entirely visual.)
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)
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.
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
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
. 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.When Invoice.Paid
perform SalesPerson.NotifyPaid(Invoice)
When TroubleTicket.MinutesOpen >240
perform TroubleTicket.NotifySupervisor
Invoice
whose Paid
attribute become True
. Operations like NotifyPaid
and NotifySupervisor
must be supplied by a framework using programmer.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.
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.