Methodologies and Technologies for Rapid Enterprise Architecture Delivery

Google
 
Web www.ies.aust.com

| Home | Courses | Projects | Papers | Contact Us |

THE ENTERPRISE NEWSLETTER

Issue No 10:
THE ROLE OF E-BUSINESS IN THE INFORMATION ECONOMY

 e-Commerce Vs e-Business, XML for Enterprise Application Integration and Growth of Trading Communities through EAI

Printable PDF Version

Contents

The Role of e-Business in the Information Economy


THE ROLE OF e-BUSINESS IN THE INFORMATION ECONOMY

PERTH, AUSTRALIA - June 22, 2000: We discussed the role of Enterprise Portals (Corporate Portals) as a central gateway to the enterprise, and the concept of Business-to-Business (B2B) Trading Communities in previous issues of TEN (see http://www.ies.aust.com/~ieinfo/articles.htm#TEN). This issue continues the theme. It discusses the role of XML for Enterprise Application Integration (EAI) within and across enterprises and its role in e-Business. It  also announces upcoming conferences and seminars that will assist you.

Clive Finkelstein
TEN - The Enterprise Newsletter

Back to Contents.


We are witnessing far-reaching changes to business as the world moves into the new Information economy. The catalyst is the Internet and the rapid advances in technology. We are seeing the growth of regional and global trading communities of buyers, suppliers and business partners in most industries. For example, GM, Ford and Daimler/Chrysler in the USA - normally vigorous competitors - are nevertheless working closely together to build a trading network with their suppliers. This network uses the Internet for procurement of automobile parts and materials. Its size is enormous: over 60,000 suppliers and around $US240 Billion of purchases each year! Similar activity is happening in most other industries. At last count the total number of trading networks already established, or in the process of being formed, exceeded 600!

Two Internet technologies are contributing to this rapid change: the Extensible Markup Language (XML); and Corporate Portals (also called Enterprise Portals). This issue briefly introduces each and discusses the impact they will have on the future of e-Commerce and e-Business.

Back to Contents.


THE DIFFERENCE BETWEEN E-COMMERCE AND E-BUSINESS

E-Commerce - the sale of products and services to customers over the Internet - is now relatively easy to implement. There are many software products and solutions that enable catalogues to be incorporated into web sites for purchase of products over the Internet by consumers. Yet e-Commerce is not e-Business. An e-Business not only sells products online (e-Commerce), but also links those sales tightly to its back-end systems for order processing and delivery fulfillment. If online sales are not seamlessly integrated with the back-end systems of an enterprise, those orders must be separately entered into the normal processing and fulfillment systems. Such enterprises are only doing e-commerce; not e-business.

Perhaps the best-known example of e-business is that of Amazon.com, the world's largest online bookstore with over a million titles. Amazon has succeeded by building a closely linked e-business value chain for acceptance of orders online and delivery to its customers wherever they are located, worldwide. As an e-business, it has also added CDs, videos, toys, electronics and auctions. It leveraged its infrastructure to move easily into these new sales markets, as it handles all aspects of sales and delivery with no reentry of details. Different to established businesses, Amazon had no legacy systems that first had to be changed for this Business - to - Consumer (B2C) sales environment. While Amazon still makes a loss at present, its infrastructure is now so well integrated and its brand is so well known that it is widely expected to become profitable in time.

By far the greater market, however, is the Business - to - Business (B2B) market. The B2B market potential exceeds the B2C potential - perhaps by an order of magnitude. The Gartner Group in Feb 2000 projected that the B2B market will grow from $US145 Billion in 1999 to $US403B in 2000; to $US953B in 2001; and then to $US2,180B (2002); $US3,950B (2003); and $US7,300B in 2004. Other research firms predict comparable growth in the B2B market with similar orders of magnitude market potential. 

Most businesses are not like Amazon. They do have existing processes and systems for order entry, credit control, invoicing, inventory and delivery. Many of these systems are old but still functioning well for the sales environment they were designed for. But even the latest systems may be considered "legacy" if they cannot easily be changed to encompass e-commerce and e-business via the Internet. This is where XML and Corporate Portals offer great benefit. 

Many application systems and databases in an enterprise may be used to carry out different business processes. XML permits relatively easy integration of business processes and application systems both within and also across enterprises. This is called Enterprise Application Integration (EAI).

Back to Contents.


THE ROLE OF XML IN ENTERPRISE APPLICATION INTEGRATION

Each legacy system was built to operate in a specific application environment, using the processes and terminology relevant to each separate application. Consider a hypothetical organization, XYZ Corporation. The Order Entry System was built for its Order Entry Department to support its processes and terminology and accept orders from customers. The Credit Control System was built for the Credit Control Department for its processes and terminology. But distinct from the Order Entry group, Credit Control assesses credit-worthiness of its "clients"; they are not called "customers". So the Credit Control System uses this different terminology. And the Finance Department calls them "debtors"; so the Invoicing and Accounts Receivable Systems all use that different terminology. Similar terminology problems arise in the Shipping Department with the Shipping and Distribution Systems and (to a lesser extent) with the Warehouse Inventory Systems.

This is one reason why it has been so difficult to change legacy systems so that they can be integrated for use in e-business. Each was built for different terminology; for different language. Like people from different countries, they don't understand each other. In the past, the only solution was to throw them away and start again to build fully integrated systems for order entry, credit control, inventory and invoicing. Yet that was impractical. XYZ could not throw its legacy systems away; it had to continue to use these systems also for their original design purpose.

Enter XML, which provides a solution to this dilemma. Released as a recommended standard in Feb 1998 by the W3C (one of the standards bodies of the Internet), XML is a language that takes the metadata (or terminology) used by different applications and systems and uses it to describe the relevant data.

In our example, XYZ must manage all sales orders, credit control, invoicing, inventory and receivables activity by each of its customers (clients, debtors etc). Now consider the case of two enterprises that buy products and services from XYZ. These are ABC, Inc and DEF Enterprises.

XYZ manages its business with ABC and DEF by allocating unique account numbers. But for reference to ABC in XYZ Corporation, for example, XML shows sales orders as <Customer>ABC, Inc</Customer>, where <Customer> is called an XML start tag and </Customer> is an end tag. As XML tags, they surround and identify the relevant data; clearly ABC, Inc is a customer. But Credit Control sees this as <Client>ABC, Inc</Client>. And similarly Finance sees <Debtor>ABC, Inc</Debtor>.

The ability of XML to identify relevant data according to its meaning to each part of the business enables the previously non-integrated (disintegrated?) systems of XYZ - its Order Entry, Credit Control, Invoicing and Accounts Receivable systems - to be integrated throughout the enterprise.  Of course, this is a gross over-simplification of what is indeed a very complex undertaking - application integration. Yet it illustrates the power and potential of XML. Each application system (legacy or otherwise) can continue to perform the processing for which it was originally designed. But the terminology - the metadata - used by application systems and databases of XYZ can also be used with XML for application integration.

XYZ Corporation thus has the best of both worlds: it can realize enormous benefits from e-business if it can achieve application integration. And by using XML it does not have to throw out still-valuable legacy systems. XML enables it to add a transformation front-end to each system for application integration. Many software tools and products to assist this integration using XML are becoming available.

But consider the problem now from the perspective of ABC. We saw that ABC is a customer of XYZ. So XYZ is a supplier to ABC. The ABC Procurement System in its Purchasing Department produces Purchase Orders to send to XYZ - which are in turn received by XYZ as Sales Orders. Mailing, faxing or emailing Purchase Orders as documents from ABC to XYZ is presently used for this inter-enterprise communication. XYZ sends back an Order Acknowledgement document, then a Delivery Advice and finally a Supplier Invoice.

For each document sent and received, the receiving organization presently must reenter the relevant details into its own systems. It can then progress the order through its relevant procurement or order entry process. But XML also allows this reentry step to be bypassed. The data in each physical document is transformed using XML into self-describing electronic documents, sent automatically as messages between systems.

Using XML in this way also overcomes the terminology problems that exist between different enterprises. The ABC Procurement System can thus communicate automatically and seamlessly with the XYZ Order Entry System. Relevant XYZ systems can then respond and send appropriate acknowledgement, delivery and invoice documents in XML as messages back to ABC. Thus XML permits relatively easy integration of business processes and application systems within and across enterprises. This is Enterprise Application Integration (EAI).

EAI is more complex than the application integration described above within each enterprise. But when EAI can be realized, its benefits and cost-saving opportunities far surpass those of application integration within a single enterprise. Typical cost reductions per transaction from $100 - down to less than $10 - are common.

Back to Contents.


THE GROWTH OF TRADING COMMUNITIES THROUGH EAI

It is through XML and Enterprise Application Integration (EAI), as discussed above, that B2B e-business has the greatest potential. EAI can save enormous processing costs in most enterprises and industries. It bypasses many error-prone and costly manual steps; it replaces them with XML document messages for automated B2B streamlined processes within and across enterprises. These cost savings go straight to the bottom-line of most enterprises. This is a compelling reason for the growth of B2B e-business. We discussed the use of XML for EAI using Commerce One, RosettaNet and Microsoft BizTalk in TEN #9 (see http://www.ies.aust.com/~ieinfo/ten09.htm). We earlier saw the impact of XML in the B2B Market Potential from 1999 - 2004, as released by the Gartner Group.

The example we discussed above of XYZ and ABC is repeated also between XYZ and DEF. Each pair of businesses can agree on the relevant XML metadata tags for document messaging. In turn, each of these enterprises can also use XML for document messaging between them and their respective customers and suppliers. But then another problem arises. Each enterprise has its own terminology - its own metadata - and each pair of enterprises must use XML to translate to and from the unique metadata used by each trading partner. Great complexity arises from these multiple enterprise interactions.

To address this problem, buyers and suppliers in each industry are coming together in trading communities with agreed XML document tags for intercommunication and B2B e-business. For example, in TEN #9 (http://www.ies.aust.com/~ieinfo/ten09.htm) we saw that RosettaNet defines XML messaging and Partner Interface Processes (PIPs) between enterprises in the Information Technology and Electronic Components industries. Commerce One uses its Common Business Language (CBL) to define interaction within many different industries through its Market Site trading communities. Microsoft is developing BizTalk as an XML document messaging protocol. There is increasing activity in the growth of trading communities, and products and services, to support them.

Back to Contents.


THE PURPOSE OF CORPORATE PORTALS

This now brings us to the topic of Corporate Portals (or Enterprise Portals). A Corporate Portal provides a single gateway via corporate Intranet to relevant workflows, application systems and databases - integrated using XML and tailored to the specific job responsibilities of each employee. In this form, the Corporate Portal is called an "Employee Portal". With appropriate security and firewall protection, it also can allow employees to access relevant processes, systems and databases via the Internet from anywhere in the world.

A Corporate Portal can also provide a single gateway across the Internet, or via a secure Extranet, to details about products and services, catalogues, and order and invoice status for customers. This is a "Customer Portal" - integrated using XML and tailored to the unique requirements of each customer. This offers opportunities for one-to-one customer personalization and management that is the intent of most Customer Relationship Management (CRM) systems.

A Corporate Portal can provide a single gateway to purchase orders and related status information for the suppliers of an enterprise. This is a "Supplier Portal". Or it can provide a gateway for business partners or shareholders in a "Partner / Shareholder Portal".

A Corporate Portal is all of these. It represents a single point of access to an enterprise, with systems and databases integrated using XML and tailored to the specific interests of each individual. This is how we can expect the e-businesses of the future will interact with each of their internal and external stakeholders (employees, customers, suppliers, partners and shareholders). 

Back to Contents.
 

 

Home
Courses

Projects
Papers
TEN Archive
Contact Us

Search

 

 


AUTHOR

Clive Finkelstein is the "Father" of Information Engineering (IE), developed by him from 1976. He is an International Consultant and Instructor, and was the Managing Director of Information Engineering Services Pty Ltd (IES) in Australia. 

Clive Finkelstein's books, online interviews, courses and details are available at http://www.ies.aust.com/cbfindex.htm.

For More Information, Contact:

  Clive Finkelstein
59B Valentine Ave
Dianella, Perth WA 6059 Australia
 
  Details:
Web Site:
Phone:
Fax:
Email:
http://www.ies.aust.com/cbfindex.htm
http://www.ies.aust.com/
+61-8-9275-3459
+61-8-6210-1579
clive.finkelstein@ies.aust.com

(c) Copyright 1995-2015 Clive Finkelstein. All Rights Reserved.


| Home | Courses | Projects | Papers | TEN Archive | Contact Us | [Search |

(c) Copyright 2004-2009 Information Engineering Services Pty Ltd. All Rights Reserved.