ENGR. MUHAMMAD ANWAR USMAN
M. ANWAR USMAN
is the Managing Director of Universal Board and Industries.
He is an industrialist and an entrepreneur. Anwar completed his
Bachelors in Electronic and Communication Engineering from the
University of Liverpool, UK in 1997 and joined Perfect
Engineering Works as Operations and Technical Support Manager.
He has also worked for Siemens Pakistan Engineering and Philips
Electrical Industries of Pakistan. After few years of work
experience, he decided to get professional degree in computer
sciences and did MSc in Business Information Technology from
another prestigious University of Manchester Institute of
Science and Technology (UMIST), UK in 2001. Later, he joined
Metropolitan Bank as a Systems Analyst and Systems Designer. And
also started Lecturing, Software Engineering Projects Consulting
and writing/supervising research papers for MS/PhD level program
at SZABIST. Also actively participating in activities carried
out by Association for Computing Machinery (ACM) Karachi chapter
and IEEE Karachi chapter. He is a professionally designated MIEE
and MIEEE. Also member of ACM, Member of Pakistan Engineering
Council (PEC) and Member of Committee for Telecommunication and
Software Development at the Federation of Pakistan Chambers of
Commerce and Industry (FPCCI) as well.
HUBBED MARKETPLACE INTEGRATION
Each e-marketplace places a primary role of "marketmaker"
to match buyers and sellers, brokers deals, and facilitate transactions
[Kobielus 2001]. Today's dominant "e-marketecture" is the
hubbed marketplace, a central Web site at which buyers and sellers focus
on transacting business activates. Hubbed e-marketectures go by many
names, which often reflect the type of the business models developed by
particular marketmakers. Indeed, any given marketmaker may combine
elements of several business models into its hub-based service. So we
cannot expect the real world to shake down into clean marketplace
models. Most common names for hubbed marketectures are as follows:
Auction, Bot, Aggregator, Broker, Community, Exchange, Mall,
Marketplace, Hub, Listing Matchmaker, and Portal. There is no specified
rule about any of these labels mentioned above, and many marketmakers
use them interchangeably. Hubbed e-marketplaces are evolving very fast
to divide them into any but the most flexible of taxonomies.
FEATURES OF E-MARKETPLACE
Marketmakers can effect policy changes with the click
of a mouse where as economists spend their lives contributing to the
formulation of macro and micro-economic policies. Changing the business
rules at the marketplace hub means you re-engineer supply chains far and
One can describe any e-marketplace as a
"stack" of these seven functional models: Hosting, membership,
aggregation, Transaction, Pricing, Payment, and Facilitation. Figure 4
below shows the hubbed marketplace's layered architecture. We will
discuss only few of these functional layers with respect to the
architecture of a particular e-marketplace we are proposing. The
e-marketplaces, as fundamental technical specifications that support
online environments where buyers and sellers meet to do business, places
B2B interoperability frameworks in their full economic context. What
distinguishes one e-marketplace from another is not so much that it uses
cXML, XML/EDI or some other set of technical interfaces but it is the
business rule, the process model, that drives the transactional
workflows that these e-marketplaces are set up to host.
For an e-commerce glue layer, a full-featured
e-marketplace hubsite should implements an intermediate layer of
software adapters between communicating Trading Partner (TP)
applications, exposes the functionality of possibly incompatible TP
applications to each other, manages the transfer of data between TP
applications over appropriate protocols, translates data exchanged
between TP applications, enforces appropriate business rules in
interactions between TP applications. There is a "superglue"
on top of e-commerce glue, where Server is basic glue for interoperable
e-commerce, and also host of other new-generation B2B "interchange
servers" which manages document mapping, translation, and
message-based routing between dissimilar applications. We can call
trading hub as the superglue in the e-commerce equation. This is a niche
where software products such as Ariba Technologies' Trading Dynamics
Market Suite are more appropriate solutions. Such products enable
marketmakers to configure the hosting, membership, aggregation,
transaction, pricing, payment, and facilitation options appropriate to
their trading environments.
Hosting a privately managed marketplace is a bit like
running an economy, but on a narrower scale. But hosting a B2B hubbed
e-marketplace is a complicated and costly undertaking. If one is a
dominant buyer in the market, he can turn his existing supply chain into
an e-marketplace. A marketplace's defines who owns, controls and manages
the trading environment. We can group B2B e-marketplaces in four basic
Such environments is managed by
an entity that is neither a buyer or seller of the traded good or
service but instead, the marketmaker simply brokers deals between others
who bear the associated financial risks and rewards.
These are environments managed by
one of the sellers in the marketplace, often a dominant seller or by a
consortium of sellers.
These are environments managed by
one of the buyers in the marketplace, often a dominant buyer; or
consortium of buyers.
These are environments managed by an organization owned and controlled
by a broad range of buyers and sellers in an industry.
The marketspace is the online parallel to the
physical marketplace. In an online marketspace, buyers and sellers
exchange information about the goods and services, reaching agreements
through information alone. Information-based goods and some services may
be delivered through the marketspace; physical goods and some services
may be delivered to the customer later on, outside of the marketspace.
Some interactive marketspaces offer rudimentary negotiation, usually of
the price for items which are relatively well-defined, such as credit
cards and cars. These items are ones for which the ontology problem is
relatively simple, and can usually be solved by displaying either a few
critical pieces of information or a picture of the item.
Every trading community is a culture with its own
specific formats rules, and procedures for doing business. An
e-marketplace's transaction model defines how traders are introduced,
offers floated, contracts negotiated, orders submitted, and deals
executed in that community. We are describing e-marketplaces'
transaction in terms of their commercial contracts, bargaining
mechanisms, and transactional workflows. But we will further only going
to discuss the bargaining/ negotiation mechanism.
Business transactions are generally viewed as
processes to exchange goods and services for some form of compensation.
Being at the core of all economic activity, transactions are the object
of much research in business and economics. "A transaction occurs
when a good or service is transferred across a technologically separable
interface. One stage of activity terminates and another one
begins". Of the many features that can be used to characterize and
analyze transactions, we concentrate on participants and transaction
Transactions usually involve three categories of
participants: buyers, sellers, and intermediaries. Buyers and sellers
are the active groups in terms of exchanging goods and services
(sellers) for some form of compensation (buyer). The third group,
intermediaries, offers a variety of services to support and facilitate
transactions. It includes financial institutions such as banks,
credit-card companies, and insurance brokers; providers of shipping,
logistics, and warehousing services; and consultants, industry
associations, and market researchers offering advice, product data, or
Business transactions consist of a number of
sub-processes. While there is generally consensus on what a business
transaction is all about and whom it involves, the approaches to
delineate their sequence show some variety. As with any definition, the
task largely depends on the research objective and perspective that is
taken. Comparatively simple models distinguish between three stages:
information, negotiation, and settlement. In their empirical work to
determine the impact of electronic networks on an organization's degree
of virtualization, identify six separable stages of a transaction.
(Refer to figure 5 below). Schmid discusses the characteristics,
organizational structures, and potentials of electronic markets. He uses
a four-step approach to outline transaction processes as the core
activities that take place in (electronic) marketplaces. In the
following, each of the phases is summarized (Figure 5 below provides an
overview and contrasts of all approach)
In the information phase of a transaction, both
buyers and sellers reach out to the world in search of information.
Buyers locate information sources such as product catalogs, use them to
scan product listings, obtain offerings from prospective suppliers by
issuing Requests for Information (RFI), and gather additional
information about products, vendors, or transaction-specific
requirements. A variety of Web-based information systems and other
applications are available to provide support for the information phase
of a transaction. Electronic catalogs, for example, feature
comprehensive product descriptions and search tools, configuration
support for complex purchases, workflow routing for approval processes,
and access to additional information such as market research data and
Of all transaction phases, the negotiation phase
shows the broadest range of variations ranging from simple processes to
very complex arrangements. Negotiations are often perceived as processes
where a small number of prospective customers and sellers (often only
one participant on each side) bargain on product prices and other terms
of a deal. The parties jointly identify possible solutions with the goal
of reaching a consensus, usually in the form of a contract.
As prospective buyers and sellers start communicating
directly with each other, interaction is at the centre of attention. In
this phase, influence is the primary object of exchange between the
transaction partners. In fact, the negotiation phase is very often quite
simple or even non-existent, such as in the case of retail buys and
pre-negotiated contracts. Traditionally, auctions form a well-defined
form of negotiations, confined to price alone and relatively easy to
automate. Recently, multi-attributive auctions have been developed that
account for a broader set of variables. Negotiations can be
distinguished according to their validity, ranging from a single
transaction to multiple-year contracts. The longer the time span that is
covered, the more complex the bargaining process tends to be structured.
ECONOMIC MECHANISM DESIGN: THE ONLINE AUCTION
Economic mechanism design looks at how to design the
"rules of the game" so that each independent agent, acting
only self interestedly, will behave in a certain manner. The mechanism
of interest here is the auction, in which the buyers bid for an item
following a predetermined set of rules. While the outcome of the auction
is unknown beforehand, the rules are well laid out, and both the buyer
and seller can formulate optimal strategy and program it into a software
agent ahead of time. The auction mechanism's biggest limitation is that
it only allows negotiation for price, not for colour, delivery schedule,
or any other variable; however, despite this shortcoming, the auction
mechanism has had success on the Internet and is well worth studying.
Auction theory is a complex economic subject, and space does not permit
a treatment here.
CURRENT APPROACHES TO BROKERAGE
In this section we present various approaches to
brokerage. The diversity of functional features of brokerage services in
the electronic marketplace makes it useful to define several criteria in
order to classify them. In terms of functionality, brokers support
different phases during an electronic market transaction. (See section
on Transactions). Most brokers on the Internet support the information
and partially the agreement phase. Guttman propose a slightly different
model. In their work they analyse seven brokerage services (called
"mediating agents") and show, which phases they support. The
functionality ranges from looking for the right product and comparing
different product alternatives to negotiating the terms of the deal.
Besides their functionality, there are several other dimensions that
play a role in the implementation of a brokerage service:
• Provisioning describes the nature of the content
of the trading entity (on-line information, physical goods, or virtual
• Information gathering describes the way, in which
a broker is given access to information of market participants. The
broker either gathers the information to create a catalogue before the
user requests it, or dynamically after receiving the user request.
• The payment dimension determines, how the broker
itself is paid. The broker can be paid per usage or per transaction.
• Ownership dimension determines if the mediator is
the owner of the content or not. The distinguishing factor between a
broker and a seller is the ownership relationship with the mediated
• Finally, the technology dimension determines the
underlying techniques used to provide the brokerage services. Many
approaches have their roots in distributed systems research. Research
projects around ISO's RM-ODP or OMG's CORBA provide many valuable ideas.
A second major category of technologies is focusing on establishing
brokerage services on the Internet.
BROKERAGE ON THE INTERNET
Most brokers on the Internet concentrate on the
aggregation of information from underlying electronic catalogs. However,
a growing number of brokers allows dynamic aggregation, where the
gathering of information is made after receiving the user request. As
most markets are extremely volatile, it is important to have this
flexible way to adapt to the frequent changes of information sources.
Andersen Consulting's Bargainfinder and Netbot's Jango are some of the
most well known examples for brokers supporting dynamic gathering.
The lack of interoperability standards between
e-commerce applications leads to high costs for the broker. Brokers face
the challenge of combining all the information within a single coherent
structure through which buyers can navigate readily. New approaches that
define high-level interoperability protocols for product listings,
offers or orders (e. g. XML/EDI) could make it much easier to automate
these tasks. These standards are a critical enabler for a whole new
generation of electronic commerce systems. However, so far there are no
widely adopted interoperability standards for Internet commerce.
BROKERAGE BASED ON DISTRIBUTED OBJECT SYSTEMS
Another large class of projects tries to develop
brokers on top of distributed object systems like OMG's CORBA. Object
Web technologies got a lot of attention during the past few years.
Especially the combination of CORBA and Web standards lead to a flood of
research projects and new products. Several projects like ABS, OSM,
COBRA, GAIA, and ABROSE are conducted by European consortia. However,
for e. g., ABS (Architecture for Information Brokerage Service) tries to
define an information brokerage service architecture based on ODP-RM and
TINA concepts. The project designs and implements prototypes of an open
brokerage system using CORBA and Java.
The alleviation of the challenges faced by enterprise
in making the strategic move to e-business is a cause worthy of
exploration, mainly due to the economic consequences of such research.
In generic software architectures, the N-tier architecture appears to
lend itself best to a flexible e-business set-up. Similarly, in terms of
flexible data interchange, XML is cited as the obvious choice in the
context of business document exchange, with independent business rules
are put forward as enabling the flexibility into such a system.
Hence, the investigation is set to the goal of demonstrating an
approach that provides a flexible architecture for e-business. Thus this
approach basically combines the contemporary technologies and
methodologies. The demonstration of the approach will be achieved
through the implementation and evaluation of a prototype.