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
- 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
- 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
- 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.
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.
User Conceptual Model
Figure 1: Innoverse Architectural Layers
- 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
- 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
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.
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.