Blueprints for the Electronic Store Interactive electronic sales will call for new IT architectures and infrastructuresTo reach new customers and open new markets, participating in electronic marketplaces (EMs) is tremendously more cost-effective than building new stores and hiring more salespeople. During the next few years, as more goods and services are purchased through EMs, customers will begin to expect immediate answers to their questions regarding a product's price, availability and shipping dates. If customers are unhappy with the answers, they will expect to be presented with immediate alternatives.
None of today's interactive EC systems is swift enough to supply these instant choices - and senior managers soon will demand systems that can. Unfortunately, many early attempts by enterprises to develop them will provide only inflexible and unfriendly "front ends" to enterprise applications that were not designed to meet the needs of electronic commerce. Companies will deploy three styles of Internet-compatible on line transaction processing (OLTP) application architectures - distributed presentation, remote presentation and distributed function - to meet the demands of interactive EC.
The best example of distributed presentation is "screen scraping", the process by which the information that was once presented on a dumb terminal screen is captured and reformatted for presentation on a browser, where it can be manipulated. The application that generated the screen remains behind an enterprise's firewall, except for the presentation veneer, the GUI. Tools such as Sterling Software's STAR: Flashpoint for the PC, Century Analysis' CL/7 for Unix systems and Platinum Technology's Integrator for mainframe-based systems screen-scrape dumb terminal transmissions over the Web, convert the screen image (the terminal map) on a dumb terminal into hypertext markup language (HTML) pages and pass them to Web browsers. While limited in functionality, distributed presentation is quick and inexpensive to implement.
With remote presentation architecture, all user-interface functionality, such as user interaction, local validation, form navigation and workflow, remains on the Web. Transaction processing, however, remains within the enterprise behind the firewall. Some 80 per cent of an enterprise's Internet-capable OLTP applications likely will use a remote presentation configuration because of the improved functionality Web browsers provide. This configuration provides public access to certain enterprise functions without exposing internal systems to the public.
With distributed function architecture, business functions other than the user interface logic can be performed on the Internet or in the EM, and EM applications can interact directly with the enterprise's applications. The programs that perform the public side of the distributed function may be downloaded to the client machine (as Java programs are) or they may be common gateway interface applications invoked by the target Web server. The data access for a transaction remains within the enterprise behind a firewall.
Application programs on the public Internet side are limited to editing, simple calculations, formula-based business rules, and message marshalling and communications. Much of this is a form of remote-presentation architecture, though only when the application business rules are performed on both sides of the firewall is the architecture a true distributed function.
Gartner Group estimates that 10 per cent of all Internet transaction processing applications will use distributed function partitioning by the year 2000.
Businesses and consumers will have the desired immediate response because local transaction components will be close by on the Web. By then, the applications often will have been developed specially for distribution across the Internet.
Message queuing may be used in the distributed function mode to achieve high client responsiveness for the applications that do not require synchronous integrity.
Of those three application architectures, the distributed function mode provides the most flexibility. Unfortunately, at this time it is also the most difficult to implement. OLTP applications must change substantially to allow public and private applications to be synchronised via mutually agreeable business rules deployed in the EM and the enterprise - challenges much like those that accompanied the earliest implementations of EDI.
To reach the customer
OLTP applications were not designed to interface directly with consumers who don't have an in-depth understanding of the enterprise's business processes, data and coding structures. To reach new customers and open new markets with EC, large companies will have to invest millions of dollars in adequate hardware and network capacity, develop new applications, and transform their sales, marketing and distribution processes to accommodate usable and appealing front-end systems. Most enterprises will be reluctant to do so because of the cost and the time required for implementation.
Nevertheless, enterprises should equip their OLTP applications and databases to handle EC by adding the required functionality, beginning with an EC clearinghouse system that can support messaging, interfaced with applications via object request brokers (ORBs) and is therefore significantly faster than today's EDI systems.
Most of today's enterprise applications can't support interactive EC because they comprise a variety of incompatible hardware, software and data descriptions. Because they were intended to link application systems across enterprise boundaries - not to present information or process interactive transactions - many EC infrastructures are designed to support only business-to-business EDI batch exchanges and data translation. Such enterprise applications cannot be used as a foundation for an EC infrastructure that must link Web-based EC and traditional transaction-processing systems. The challenge is to design systems that support the following:* distributed-function Internet-capable OLTP; * concurrent interactive users; and * a robust application programming interface to application systems.
In a large, multidivisional enterprise, the information needed to interact with an EM user is often spread across several databases managed by several applications. Responding quickly to an EM user's request requires the high-speed transformation of the EM user's information and interfaces with applications on different platforms. One solution is to implement message brokers, which allow communication between multiple parties on disparate application systems. Because of techniques and enabling tools such as IBM's MQSeries, Gartner Group expects this approach to become common in large enterprises during the next five years.
Message brokers recognise that messages from one source system may be relevant to many consuming systems, multiple sources may be of interest to each application system and messaging among heterogeneous applications is "many to many". For example, if an address change is fed into one system, that system must notify 10 other systems of the event. Ordinarily, that requires 10 different messages or file transfers, but with a message broker the source application sends one message in one format, and the broker translates it and relays it to all 10 applications.
Message brokers can be set within different configurations, and they may use elementary, one-to-one forms of middleware - for example, most remote procedure calls, message-oriented middleware, ORBs or transaction processing monitors - to handle message delivery. But message brokers still need more features to translate messages and other features to support the "many to many" demands of electronic commerce.
Gartner expects rapid, continued development, roll-out and adoption of Internet-based technologies and applications for EC. The pace of development and demand will drive vendors to find solutions to technical problems much faster than they have for other networking and computing platforms.
Today, no EC clearinghouse systems support interactive EC - and Gartner Group does not expect that they will before the first half of 1998. Until then, enterprises that want to support interactive EC must develop their own EC clearinghouses using a variety of middleware tools.
(Barbara Reilly, is a product manager in Gartner Group's Electronic Commerce Strategies service in Stamford, Connecticut the US)
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.