A Strategic Approach to Electronic Transaction Conversion [HRBC reference in middle]
telecommagazine.com
To profit fully from the efficiencies of the electronic marketplace, companies
must adopt a strategic approach to the problem of data interoperability.
Derek Leebaert, Ph.D.
Digital commerce is accompanied by tremendous technical strain. As
companies exchange more and more information electronically with
subsidiaries, suppliers, customers, and even regulators, the challenge
to corporate back offices grows. Before information is used in a
computer system, an interface manipulates the raw, incoming data into
a format understood by an application, such as accounts receivable or
credit validation. As each business application passes data to another
stage of processing, a new interface manipulates the data to fit. Since
there is no standard for compatible information exchange between
computer systems, data interoperability problems increase
exponentially each time the existing system has to accommodate a
new data stream or connect to a new computer.
Don't expect a data interoperability standard to emerge. In today's
market, organizations use different business applications and define
information in different ways. Custom data structures are often
created to support a company's unique services. For example,
telecom carriers are reluctant to reveal voice system records because
these records define the competitive features of their services.
Moreover, different types of equipment--not just computers but, for
example, switches and access nodes--produce different types of
record formats even within the same corporate back office.
The telephone provides a useful analogy. Phones offer a nearly
universal means of communication, with the speech they carry being
the common method of understanding between the parties involved.
But if one caller is speaking English and the person on the other end
understands only Japanese, no information will be shared. Computers
are similar. The network provides the infrastructure while the
hardware and software define the common mode of exchange. When
computers use different information formats (the speech in this
analogy), they cannot communicate unless the languages they use are
somehow interpreted.
So how should we confront the increasing costs and delays of sending
and receiving incompatible information? Not through today's
case-by-case conversion programming to build a new interface for
each new connection. The price is unsustainable. When Sprint
introduced its PCS services in 1996, for example, it had to do so
without adequate billing systems. Market share had to be captured
immediately even though back office interoperability meant that
Sprint's billing systems could not catch up until a year or so later.
The Interoperability Quagmire
Traditionally, conversions have involved the expensive and
time-consuming development of custom software. By definition, such
tailoring cannot be applied generically and does not lend itself to
reuse. Another unique interface requirement is always on the horizon.
Meanwhile, corporations can spend hundreds of millions of dollars
building and rebuilding their billing systems, constantly wrestling with
the interface dilemma that gets worse as each new service or alliance
is added. This piecemeal approach to interoperability demands a
21st-century response.
Virtually all of today's hot technologies--Java, CORBA and DCOM,
the Internet itself--address the infrastructure or mode issues that
underlie the inability to communicate directly. Instead, why not
confront the issues of language or information content, especially since
data interoperability delays will not be resolved by any overarching
technical fix? Why not manipulate the data languages themselves in
real time, rather than dangerously meddling with the systems that are
doing the talking?
In theory, the use of distributed objects would let processes talk with
each other seamlessly because everyone in the communications
universe would start speaking the same language (i.e., the same set of
interchange definitions). But that won't happen for years, if ever, in no
small part because companies keep finding as much competitive
advantage in the uniqueness of their internal processing as they do in
accepting open systems. Standards might be welcome in some
business cases, but be threatening in others. Moreover, who will
decree the common language? Microsoft (DCOM)? Or almost
everyone else (CORBA)?
The telecom carriers are feeling the pain of data incompatibility and
are beginning to reach for answers. How else can they confront even
the following four challenges?
New technologies: Subscribers create billions of call detail
records (CDRs) that define the services sold by the carrier. The CDR
format depends on the type of equipment and the manufacturer from
which it originates, as well as on variables such as the version of the
switch. As a result, CDRs arrive in many formats even though they all
contain essentially the same information. As a carrier introduces new
technology to improve or expand its services, the CDR format
changes.
New services: Companies want to provide one-stop shopping for
their subscribers, with local, long-distance, and wireless services. But
it typically requires two years to build the back office support systems
for a new service, and a massive opportunity cost is paid for being
late to market or for being unable to bill accurately for services.
Mergers and acquisitions: To profit from the larger customer
bases, expanded services, and operational synergies that are
supposed to flow from economies of scale, merging companies must
quickly consolidate and upgrade their previously separate information
systems.
Expanding wholesale/resale strategies: The Telecom Act of
1996 was the starting gun for plunging into new markets. One of the
quickest ways to enter is to resell the services of an existing provider.
Reselling has its limits, since the reseller must use the wholesaler's
billing information to invoice customers, and it arrives in unfamiliar
formats requiring conversion.
These demands spotlight only the most dramatic data interoperability
obstacles to increased marketplace efficiency. There are many other
examples, such as order entry, fraud detection, and electronic
payment. One international carrier maintains 180 separate, parallel
billing systems due to the difficulty of handling disparate information
flows.
Other industries are equally bedeviled, especially the electric utilities,
which are proceeding down the same path of deregulation. Their data
problems will be similar in size and complexity. Moreover, as the
utilities themselves begin to provide communications capabilities,
they'll encounter an ever thornier thicket of incompatibilities.
Band-Aids Are Not a Strategy
Current approaches to all this chaos are tactical and reactive. The
quest for standards is a good example. Ironically, standards routinely
offer such a breadth of flexibility in their implementation that critics
remark, “There are more than enough standards to go around.” For
example, Bellcore publishes a standard for customer billing, The
Exchange Message Interface (EMI). It allows users to tailor it for
specific requirements. It comes as no surprise then that the EMI
implementations of different carriers rarely work together.
We are left with four less than ideal means to achieve data
interoperability. One is for a company's IS programmers to write
software that permits disparate forms of data to communicate. These
increasingly valuable employees then squander their time writing
interface software to solve a particular application requirement. When
a new application comes along that has to be integrated with the
existing system, they write a second, and then a third, and then a
fourth. After each effort, they must examine the entire breadth of their
legacy systems to assure that their latest work has not distorted the
overall communications process.
Along the way, the in-house programmers wrestle with interfaces that
were developed by their predecessors, not all of whom are still
on-site. They find themselves diverted from crafting new profitable
services to laboring on conversion code.
An alternative to using in-house staff is to turn to the systems
integration firms such as EDS and Andersen. The integrators take
responsibility for developing discrete components of a system and
often augment the corporate IS staff. In neither case does the
integrator have much incentive to adopt a strategy to solve the
interoperability problems of its clients. Its own profits often depend on
the complexity of the new solution it delivers and on the hours
accumulated on the engagement.
A third approach is the use of niche technologies, such as mediation
devices or EDI converters, to build conversion capabilities for specific
types of interfaces. For example, Premenos Technology Corp. and
Harbinger Corp. focus on the exchange of transactions based on the
EDI format. But this is a solution to only part of the problem.
Although both companies offer helpful interface software that allows
organizations to transition from their existing record formats to an EDI
format, they do not address the host of other conversion dilemmas
afflicting businesses.
A final approach is packaged solutions for applications such as billing,
order entry, or customer care. Vendors like Saville for billing and
SAP for financial systems provide off-the-shelf software for specific
customer requirements. As useful as such approaches are, they too
solve only part of the interoperability problem and, once installed,
they are often found to be inflexible.
The electronic marketplace demands a strategy that transcends the
unachievable and undesirable notion of standards while making
real-time interoperability possible, regardless of the data's complexity.
Nor can so serious an obstacle be overcome by piecemeal
approaches. An interesting solution is now emerging.
MCI, which had its own origins in an ability to think outside the box,
now uses what it describes as a “data transaction converter” or an
“interface management engine.” This is a software solution created to
work in various milieus--from traditional back office, batch-based
billing applications to real-time operational environments. It gives
MCI the ability to send and receive the electronic records--embracing
a range of incompatible systems and formats--that beset telco
operations, not to mention other industries. (See the sidebar, MCI:
An Early Adopter for more information about MCI's approach.)
Enabling a company's existing data-processing networks to read
otherwise incompatible electronic records is becoming the
prerequisite for bringing full commercial potential to the electronic
marketplace. Businesses are then able to retain, protect, and leverage
their immense back office investments. They become more
independent from their IT vendors, more flexible and responsive, and
more in line with the real-time, worldwide interconnectivity that is
supposed to be the promise of the early 21st century.
Derek Leebaert teaches the economics of innovation at
Georgetown University. He is co-author of The Future of the
Electronic Marketplace (The MIT Press, 1998). He also advises
corporations on technology management and on adopting new
information products and services to leverage computerized
infrastructures. Contact him at (202) 333-5458.
MCI: An Early Adopter
I became involved in a project with MCI and Linguateq, Inc. to
explore a new solution to the data interoperability problem. MCI
decided to confront this chaos by deploying a general purpose
interface technology that supports information conversion and
uses a scalable architecture to support reuse. At the strategy's
core is a network device that converges insights drawn from the
communications and computer industries (by no means as
synonymous as often thought) to create an interface management
system (IMS). With this system, MCI effectively breaks the
runaway growth of its increasingly costly interface requirements.
The solution to automate interfacing might sound mundane. But it
introduces a more predictable and precise solution in place of
those typically characterized by open-ended budgets and man
years. It usually offers a short (e.g., 30-day) horizon instead of
the six-to-12-month (or longer) back office conversion routine.
Aside from saving time, the dollar costs are so far proving to be
20 percent to 50 percent less than the prevailing approaches.
The initial challenge at MCI was to be able to receive, process,
and audit invoices from other service providers that were using
complex formats such as EDI 811. With an IMS, MCI was able
to read the record formats and convert the data streams into a
single output feed accepted by its legacy systems in real time.
This process took only three months to install, compared to
approximately three times that for the custom-development of
interfaces necessary to deal with the service providers.
Moreover, the management system approach lets MCI add new
data streams in days, quickly and relatively cheaply translating
other formats, such as CABs, SECABS, and proprietary record
types. Future changes and modifications, which are inevitable in
the real world, also benefit from the next generation of interface
technology. Transaction conversion becomes an automated task
that permits conversion, mapping, switching, and networking. The
user is able to enter new business fast, add partners and suppliers
easily, introduce new systems and applications with minimal
delay, and reduce the diversion of key personnel.
MCI used the IMS developed by Linguateq, Inc., a
venture-backed company formed by engineers from Sprint,
AT&T, and MCI. Linguateq confronted the data interoperability
dilemma strategically by building a widely applicable technology
that works on individual records as they traverse the network. To
provide a flexible, scalable solution, it had to operate
independently of existing systems. It posits a message interface
(MI) that defines exterior records to the internal engine. Once
defined, the engine allows all MIs to exchange information.
With this approach, automated interface management meets
several requirements: format (integers, dates, time, computer
codes), content (information values, ranges), structure (fixed,
variable, field definition), and context (hierarchies, segments,
transmissions). Functionality also involves switching--routing or
filtering records between multiple sources and destinations based
on the content of the information. Moreover, network handling
(e.g., TCP/IP, SNA) allows rapid integration into existing system
environments. Transaction conversion therefore takes advantage
of the network and leverages its reliability, as a library of MIs can
be built and maintained.
Reader Poll
What's your reaction to this article? The responses of our readers are
important to us. Please send your comments and observations to
editorial@telecoms-mag.com
|
