Re: E-mmerce

["Steven J. Owens" <puff -at- NETCOM -dot- COM>]

AlQuin writes:

> Electronic Commerce (e-commerce or EC for short) is the end-to-end
> digital exchange of all information needed to conduct business and is a
> way of doing business better, faster and more effectively. Examples

     True;  cool URLs, will definitely go on my must-read list. However,
I suspect that the context the original question arose in is much more
limited.

     "e-commerce" is a word which means doing business by electronic
means instead of face-to-face, and in broad practice has a huge array
of possible meanings.  The emerging buzzword/meme of "e-commerce" on
the web seams to refer to attempts to package and productize a set of
solutions (see below) to various parts of the job of providing
retailing or business-to-business web sites.

     A year or two ago you could have simply said that e-commerce was
having CGI/forms to take customer orders, an SSL server to protect the
payment information, and a set of web pages with products.

     Then databases of products became essential, with search
capabilities.  Still later, you needed shopping cart systems to allow
customers to pick out items more conveniently before sending in the
purchase order.  Online credit card verification and processing are
now commonly available, either via hardware/software combinations or
by relaying transactions to other sites for final processing.

     What's the next step?  Greater intregation with and development
of fulfillment systems.  What are "fulfillment systems"?  Unless
you're operating a company where you provide marketing, etc and wholly
outsource fulfillment(*), then the fulfillment system needs to be a
vertical application similar to a point-of-sale system and/or an
inventory-management system.

(* An example would be where you're hosting a site full of book
   reviews with the option to purchase, and outsource the fulfillment to
   amazon.com.  Or another example, you operate a travel agency site with
   cross-selling to various related services, with each service
   maintained by a separate company with their own web-based ordering
   system;  your system provides options to order the related service,
   then goes out to the related site and posts for the user.)

     A major corporation would be expected to maintain their own
connectivity (T1, T3, even their own company backbone), server
hardware, software, and develop and maintian back-end databases for
point-of-sale, inventory management, shipping, accounting, etc.  Most
smaller vertical systems are heavily proprietary, usually running on
some arcane OS or maybe even DOS.  The few UNIX-based vertical systems
I've come across (I don't consider myself widely experienced in this
area) were in odd, cryptic, specialized versions of BASIC or FORTRAN,
with bit-field coded databases.

     Perhaps that points out a need to break it down a bit more:

     By type:
          Retail
          Business-to-Business

     By size:
          Billboard web site with single-product, single-click ordering
          small-to-medium sized company
          large company

     For type, we can assume that vertical backoffice (inventory / POS /
shipping / order processing / accounting) solutions fill a separate but
related niche (or set of niches).  Otherwise the discussion gets far too
large and is about software design in general, instead of web software
design and e-commerce design.  For size, use the fairly conventional
definitions based on orders of magnitude; a small company employs tens of
people, medium hundreds, large thousands, with accompanying budgets.

     Obviously, in some cases, mainly large companies and companies
that specialize in web business (like Amazon, Egghead, etc) the back
office will be completely custom-built (as described above) and
integrated with the e-commerce technology, put together by huge
projects involving hundreds of thousands to millions of dollars of
hardware investment and as much in development costs.

     Billboard sites, at the other end of the extreme, are fairly
straightforward. While they could be said to provide "e-commerce",
there's not much more to building and running them than a conventional
form and making sure you have SSL so payment data isn't exposed.

     That leaves the small-to-medium businesses, where the site is hosted
on a third party server or on a server dedicated to supporting a
particular e-commerce solution. (or, rarely, on a colocated small scale
server, like a Linux box, or behind a company's office T1), and
interoperability with the backoffice systems is minimal or non-existent,
so far (*).

(* and likely to stay that way.  I'm not familiar with any
   market-dominating, low-cost, generic backoffice technology. Until
   the custom developers in this arena start working with more
   mainstream interoperable technologies, connections to their systems
   will have to be custom developed to fit.  The best that can be done
   now is to make sure the systems you're developing are ready to play
   nicely with others; ODBC compliant, maybe someday CORBA support for
   the big players, etc.)

     So for the moment, when you hear "e-commerce" you're probably
going to be looking at a collection of programs and utilities, web
pages and forms.  In most cases they'll be designed to be used with a
separate web server and SSL server, and with a separate (though
possibly bundled) database.  They'll provide forms and scripts as the
interface to database tables.  Collectively these will comprise an
"e-commerce" application.

     In the average case the capabilities they will provide will include:

     Putting the business's catalog of products in an online, searchable
          database.
     Providing a "shopping cart" so users can browse or search through
          the catalog, click on products they want to add the cart, then
          finally click on a link to buy them all.
     Take payment and shipping information securely.
     Track the orders in an online database.
     Handle forwarding the payment information to a merchanting account
          (Credit cards, ACH, new forms of electronic payment).

     In the ideal case, the package would provide integration with the
business's other systems, to make it easy for information to flow from
the business to the web site (updating the database, changing static
content to keep it fresh, etc), and from the web site to the business
(orders to the business's order processing & inventory, shipping
information to the shipping system, payment info to the accounting
system).

     However, I suspect that you will almost never see this, at least
not in less-than-major-corporation systemns, for reasons given above.
Probably the best you'll see will be forms & CGI scripts to provide
the business with basic tools to manipulate the order database (review
orders, move them to a "fulfilled" table after shipping the product,
etc).

     In fact, I'd guess it's probably safe to say that most
"e-commerce" solutions offered under that buzzword are simply combined
catalog/shopping cart systems, mostly sans actual RDBMS and web server
software, with integrated credit card payment systems.

     For somebody else's point of view, there was a decent article
surveying some of the bigger players in the "e-commerce" application
market at:
     www.performancecomputing.com/columns/web/9811.shtml

Steven J. Owens
puff -at- netcom -dot- com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=