OBJECT MODELS FOR BUSINESS TRANSACTION PROCESSING SYSTEMS

Transactions are at the heart of the telecommunications industry. The goal of a network operator is to deliver communications transactions of various types (voice, data, fax, telex, etc.), and to bill these transactions to the appropriate subscriber. This basic goal requires many business transactions, which fall into the following categories:

• Subscriber Management consists of create, read, update and delete (CRUD) activities on customer data, along with audit information for the changed data and source of the change. Subscriber is one of the many roles that can be played by an organization with respect to the Enterprise. An organization role can have many data views, each requiring ongoing maintenance. These views include: contact, location, network address, telecom service, agreement, and account. Each of these views tends to be compositional in nature, and thus is often implemented with a tree structure.
• Work Flow, in general, is a transaction control application. It can be thought of as a state machine handling long transactions consisting of component transactions that are the responsibility of different parts of the Enterprise. As each transaction changes state, a request must be routed to the appropriate actor, and monitored for achieving expected service levels. A customer order requires that a number of activities take place after the basic subscriber maintenance. These include service provisioning in the network, credit approval, and notification of order fulfillment.
• Inventory Management is the inverse of Subscriber Management, i.e. the reversal of the Customer / Supplier role from the point of view of the Enterprise. However, there is more likely to be an automated interface between the Enterprise and its suppliers for the ordering of equipment. Again, Work Flow is the vehicle by which the ordering process is carried out.
• Provisioning handles the transactions between the Subscriber Management and the network for the establishment of service. Its implementation depends on the role the Enterprise plays with respect to the network. If playing the Network Operator role, it is likely that the interface will be message-based, and the provisioning performed real time, but asynchronously. If playing the Service Provider role, the interface may well be via batch notification of changes in service from the partnering Network Operator. Provisioning involves the change of state of a number of logical (network) or physical (equipment) components. A one time (non-recurring) charge to the subscriber is frequently associated with the provisioning of service.
• Call Processing receives subscriber transactions from the network, translates coding formats, ensures validity, authorizes to the appropriate subscriber, rates based on the subscriber’s agreed price plans, and posts to the appropriate account. Innoverse is internally architected to rate network events in real time, but in practice it receives periodic batches of calls from the switch. Financial integrity is crucial, both in balancing back to ensure that all transactions from the network are rated correctly, and for the sourcing of monies to be closed to the General Ledger.
• Trouble Ticketing is another work flow application, ensuring that service is restored in a timely manner. The approach can be used to handle any type of customer complaint. This provides a major source of process and quality indicators, critical to the improvement of customer satisfaction.
• Agreement Period Closing is a predominantly monthly that calculates subscription fees (monthly recurring charges) and discounts. The terms of the agreement specify those amounts that contribute to the qualification for discounts, and those amounts to which the discount rates are to be applied.
• Invoicing is again predominantly monthly in nature, and usually occurs in conjunction with Account Period Closing. The invoice is the request by the Enterprise to the customer for the payment due on the outstanding accounts receivable.
• Account Period Closing generates the journal transaction to the General Ledger. The single entry accounts receivable transactions generate summary level double entry transactions based on the Enterprise’s Chart of Accounts.
• Infrastructure Maintenance is required for such reference data as the LERG feed from Bellcore defining the regional components of the North American Dial Plan and associated network operators. Also regional in nature, are the maintenance tax rates for the federal, state and local jurisdictions.
• Decision Support is not usually considered transactional in nature, but has a number of interesting aspects: when should the information environment be updated from the operational?; how (complete refresh or deltas) should the data warehouse be updated?; are there common queries that should be stored rather than ad-hoc?; if so, could the analysis be performed by the computer, so that interesting situations (rather than just everything) be reported?; finally, how should the feedback loop into the business rule maintenance be achieved? · Business Rule Development not only populates and tests the Enterprise’s product catalog and price plans, but should also maintain a range of rules to dynamicaly specify business objects.

Transaction Processing Environments

The above set of transactions can be generalized into the four following processing environments, organized around the Deming Cycle.

• The "Planning" environment supports Business Rule Development. This is a CASE-like (or CAD) environment. The transactions are low volume, but long, and lend themselves to the check in / check out of rule objects to graphics workstations. Simulation of operational transactions must be supported to enable the testing of price plans, and forecasting of product revenues. Once the new business rule configuration is satisfactory, its release into the operational environment poses interesting questions.
• There are two "Doing" environments to support the operational transactions, both of which require read-only access to the business rule objects. Online Transaction Processing (OLTP) is a client / server environment that supports the customer care activities, including Subscriber Management. The transactions are short, requiring fast response time, since the customer is probably on the phone. The Batch environment mostly treats the subscriber data as read-only, and handles the high volume Call Processing and Period Closing transactions. Checkpoint commits are common, and parallel processing is often required to handle the high volumes in a timely manner.
• The "Checking" environment supports the informational requirements, and requires read-only access to the (usually summarized) operational data. The ad-hoc queries are usually unpredictable, but there should be no locking required. Queries must be repeatable in their results, so currency of data is not as important as it being in a known stable state. Traditionally, this has been the domain of relational (as opposed to object) databases, due to the unpredictability of access paths.
• "Acting" is not so much a technical environment, as a business one. The lessons learned from the informational environment must be fed back into Business Rule Development to enable the Enterprise to react to changing market conditions.

Innoverse Architecture

ClearSystems has adopted a "divide and conquer" approach to develop the Innoverse Architecture, whose goal is to provide a holistic executable model of the Enterprise. As seems to be standard in the development of an Information Architecture (e.g., the Zachman Grid, OSI Protocol stacks), these divisions are represented as layers. Each layer is of either essential complexity - the expression of the fundamental problem to be solved - or accidental complexity - required for implementation, but dependent upon current technology constraints.

We contend that only the Business Model layer is of purely essential complexity, and, as such, can, through natural maturation, is the only layer that can really achieve stability. We believe that a Business Object Architecture (see below) is the optimal expression of this essential complexity.

There is, of course, "many a slip ‘twixt the cup and the lip", i.e., everything is uncertain until you possess it. In that respect, all the following layers are essential to an effective implementation - the only real measure of success - but the leverage obtained from a correct, stable Business Model is immense.

• The Business Process layer defines the operational, control, tactical and strategic processes of the Enterprise (the organization that is the subject of the model), and their implementation within the organizational structure. There are numerous essential techniques for both business process development (e.g. Business Process Reengineering [BPR]), and improvement (e.g. Total Quality Management [TQM]). The motivation behind the development of business transaction processing systems should be to improve the efficiency and / or effectiveness of these business processes.
• The User Conceptual Model layer maps the business processes to the roles of the individuals within the Enterprise that perform them. There is a many-to-many mapping between roles and business activities, the operational characteristics (e.g., response time, commit strategy) of which are altered by the context of the role performing them.
• The External Interfaces layer are the mechanisms by which the business objects communicate with their environment. It consists of a number of frameworks, each of which solves one aspect of accidental complexity (e.g., Graphical User Interface, File Interface). These frameworks are applied to the business objects that require them, resulting in another set of layered artifacts.
• The Business Model layer concentrates on the essential complexity of the business problem domain. It answers two major questions: what is the required set of business objects, and what are their responsibilities? The ClearSystems answers to these questions are documented in the Innoverse Business Object Architecture (see below).
• The Schema layer addresses the underlying structure of the business objects. Although encapsulated by the business objects, the problem of structure does not go away. Its relationship to behavior is one of the basic philosophical questions (mind over matter). The Innoverse Schema framework provides data typing, for both initialization and storage transformation, referential integrity constraints, and definition of indexing, namespace and binding. A very important, but not yet implemented, responsibility of this layer is data distribution.
• The Persistence layer consists of the data base management systems (DBMS) used for actual data storage. The definitions for the DBMS are obtained from the Schema layer, but it is important to retain the distinction between the two. The Schema layer provides the definition of the essential data structures; the Persistence layer provides the physical implementation mechanisms for the storage of these structures.
• The Technical Infrastructure layer consists of the operating system, networking, and printing services.

One of the main purposes of an architecture is to provide a place for everything. We believe the above layers provide this within the universe of discourse of information systems. There are, of course, on-going debates as to whether everything is in its place. This is most common in the two layers surrounding the Business Model. Should the External Interfaces layer only address the man / machine interface, moving such interfaces as flat-file, relational, and IDL to the Schema? The main thing is that if we wanted to, we could do this and not materially change anything. That is the beauty of an Information Architecture, it is the container for the ideas, not the ideas themselves.

The Innoverse Architecture and Transaction Processing

How does this architecture help us conceptualize business transaction processing? At its most essential, a transaction is just a series of messages between objects, with a well defined start state, and a desirable end state. From the database point of view, if the desired end state is achieved, the transaction should be committed; if not, the transaction should be rolled back, leaving us at the start state.

The layered architecture approach raises object-orientation to a much higher level of abstraction. The Business Model (see below) consists of Business Objects that aggregate implementation classes. The External Interfaces, Schema, and System Management layers consist of Frameworks. We refer to Business Objects and frameworks as Architectural Components. Each layer has its own type of architectural components: the Business Process has Business Functions and Organizational Units; the User Conceptual Model has Roles. The architectural layer is then just the aggregation of its components.

The messaging between the layers then identifies the different types of transaction as follows:

• Work flow transactions consist of messages that cross the Business Process / User Conceptual Model interface, as instances of business activities required by a customer are assigned to an employee playing a certain role.
• OLTP is the messaging between the User Conceptual Model and the GUI architectural component in the External Interfaces layer. The User Conceptual Model is responsible for defining the actual strategy, since the same window may be used within multiple contexts. The semantics of the cancel button (rollback) on a particular window will vary depending on the context.
• Batch transactions are also messages between the User Conceptual Model and the External Interfaces. In this case the File Interface architectural component will usually be the controller.
• The Business Model interface is expressed in terms of use cases that consist of system operations. Each use case is the responsibility of one Business Object, frequently requiring collaboration with other Business Objects. The system operation itself is implemented as a message send to a controller object. The ClearSystems Use Case Framework simulates these messages through the implementation of the Fusion Time Line Diagram (Event Trace in UML). Regression testing of the business model is achieved by the specification, for each system operation, of precondition states and their expected postcondition state after the completion of system operation.