Today, B-to-C business models seem to command more attention and generate more interest than do B-to-B business models. This is because relationships between consumers and e-Tailers are by nature less involved and customized than those between enterprises in B-to-B relationships. B-to-B commerce is dominated by long-term, symbiotic buyer-supplier-business partner relationships where stakeholders collectively work for common interests such as lower costs and improved product and service offerings.

The astounding success on Wall Street of Amazon.com, eBay, and Priceline.com provides strong evidence that B-to-C commerce has already arrived. We've just begun, however, to explore and exploit B-to-B business models. Due to the enormous volume of spending in the B-to-B sector (companies such as General Electric and General Motors each spend over a couple billion dollars per year), the next generation of.com success stories will be dominated by B-to-B product and service providers.

Adam Brandenburger and Barry Nalebuff explore this symbiosis in their popular book Co-opetition. In the book, they introduce the concept of the “Value Net” in which customers and suppliers are both symmetrical, equal partners in creating value for the firm while competitors and “complementors” act as mirror images of one another. The Internet and its capacity for connecting organizations provides exciting new opportunities to explore and exploit the symmetries between customers and suppliers.

NET FOR BUSINESS?

Let's start out by taking a moment to ask—and answer—the most obvious of “e” questions: why do companies that are already successful at selling their products via the more traditional distribution channels (retail locations, catalogs, television, and even the telephone) feel the need to sell their wares online? In short, what is the appeal of the Net?

First and foremost, the Net enables businesses to interact personally and directly with customers without incurring the overhead costs of building a larger sales force, opening new retail locations, or hiring and training new customer service representatives.

At first glance, this seems a bit absurd. How does the World Wide Web—largely just a repository of text and images—increase personal interaction? The answer lies in the capability of computers to gather, store, and transmit mountains of data in the blink of an eye. By always utilizing this information in real time, enterprises can focus on building personalized, long-term relationships with each and every customer, such as was done before the days of strip malls, superstores, and direct-mail catalogs. In many ways, this is a better way to do business. Let's pick a simple example to illustrate.

Say you want to read A Tale of Two Cities. Today, you'd probably just head down to the local branch of a national bookselling chain and buy a copy.

If you listen to Scott and Bill, all you have to do is to choose between Sun and Microsoft to define your e-Enterprise software infrastructure. I wish the answer was that simple. Au contraire, thanks to the IT industry, choices are unlimited and go far beyond Sun, Microsoft, and Oracle. As a matter of fact, choosing the right implementation strategy from the vast architectural and vendor options is becoming increasingly difficult.

In Chapter 6, I have outlined a high-level, logical technology architecture that contains high levels of abstractions such as e-Application Rules, e-Application Distribution/Integration, e-Data, and e-Networks. In Chapter 7, you learned the driving business components that primarily define the reusable e-Application Rules. In this final chapter, I will introduce some of the emerging technology components that should be utilized to implement these higher-level abstraction layers from a pure technology perspective.

Although this chapter discusses a few selected emerging technologies, it is not intended to be a recipe for physical implementation. Rather, it is intended to explore important standard technologies that should be understood, considered, independently verified, and validated for each e-Initiative.

When Jack Welch makes the Net his top business priority you can be sure that the Internet and Net-based business have taken the critical step from possibility into reality. In fact, General Electric and countless other Global 2000 companies are quickly investigating and applying the newest Internet technologies. These companies seek to gain and retain competitive advantages in new and evolving markets through highly adaptive Net-based enterprises. Everywhere you turn, both the mainstream and business news media are focused on the Net Revolution. Both alluring and critical reports about the Web, the Information Superhighway, and Internet ventures abound.

The Net is the backbone for the new digital economy that is radically changing business models around the globe. These new business models have become differentiators that redefine market winners and losers. No one is safe from the changing tide. Past critics of the Internet have said that it's a gadget for hobbyists and computer geeks—not a valuable tool for business. It's all hype, they said. As evidence they pointed to the astronomic market capitalization of so-called Internet stocks. They said that conventional enterprises are safe from these over-publicized startups. Put simply, they were wrong then, and they're wrong now. As Business Week says “You are Merrill Lynch when Schwab.com comes along.

Whoever invented the button didn't need much of a business architecture model to cope with the change he unleashed. The button, a thirteenth-century invention, took 400 years to achieve widespread use. The bicycle appeared in 1818 and took 50 years to catch on. The telephone, invented in 1876, needed 35 years to find the beginnings of a mass market. Television took 26 years; the personal computer, 16 years.

Those adoption rates seem pretty leisurely by today's standards. The unyielding environment of speed in technology-induced business change is so pervasive that a CEO (or any C*O, responsible for operations, finance, human resources, technology, marketing, or any other function) who doesn't occasionally get a sense of panic perhaps doesn't get a lot of other things either.

And speed is only one element of the profound paradigm shift that is happening in how business is transacted as a result of the Internet. The e-Revolution is on and—as is the tendency of revolutions—things can be a bit confusing while the participants sort themselves out.

Maybe it was acceptable that your company created its first Web site to “keep up with the Joneses”—whoever they are in your industry. You didn't need much of a model or architecture for that decision; the Joneses, after all, were equally unsure about what they were doing and why. Maybe you made your first forays into electronic commerce and electronic business in the same fashion.

In an era of e-Everything, there is no shortage of books proselytizing the benefits of participating in the e-Universe and warning that the failure to develop and execute a Net commerce strategy threatens your company's survival. There's no shortage of vendors and consultants offering to sell you Net commerce solutions and presenting themselves as experts with broad strategic scope and knowledge of “how to do it right.” While most of these purveyors talk a good game at the information and strategy level, they lack a rigorous approach in putting it all together.

The reason there are so many claims is because the underlying value proposition and the opportunities are enormous. Enterprises that develop a business strategy that perfectly integrates traditional real world operations with a great Net business model, and that are able to simulate its implementation and test its assumptions before investing millions, will have a major competitive advantage. A rigorous, continuously fine-tuned approach to execution will also be on the critical path.

It's not an easy thing to do. Furthermore, it has to be done fast the first time, the second time, the third, and the nth time. Your markets—everybody's markets—are changing that quickly. But major winners will determine how to innovate, sustain, remain, and then re-innovate.

Faisal Hoque has developed a robust methodology that enables an enterprise to develop its electronic commerce vision and strategy; to architect and simulate the business processes and technology applications that operationalize the strategy; and to create the repository so that every architectural component can be reused in the next iteration (and the next, and the next).

The goal of business software design is to create information tools that support the organization's business activities. The software developer has to work closely with the end users and be able to communicate in business language as well as computer language. At the same time, the end users have to become educated to understand the computer's capabilities and limitations. Business needs change quickly, so an effective design methodology must be flexible and adapt easily to changing business requirements.

N-tier computing complicates the design process even more. While traditional two-tiered client/server emphasized applications and user interfaces, n-tier design requires both application-oriented software design as well as process-oriented business object design. The pressure is on to produce applications in shorter timeframes while creating more robust, reusable business objects. The days of the coding cowboy are over.

Fortunately, there are methodologies and tools to support these requirements. The joint application development GAD) team approach brings software developers and end users together to design software jointly. Iterative, incremental development provides shorter design and programming cycles to ensure that the project stays on track and meets the end user's needs. The Unified Modeling Language (UML) can be used by both software developers and end users to communicate design ideas. Computer-aided software engineering (CASE) tools such as Rational Rose can streamline this process by creating UML diagrams, generate skeleton code and then update the UML models as the design progresses.

Creating business objects is a straightforward process in any object-oriented language. Just declare a class, list the attributes and methods, then fill in the business logic. This is basic object-oriented programming. The difficulty lies in linking these objects across a distributed network and getting them to perform useful work. This chapter will use the Java programming language to illustrate how business objects can be created and distributed across a network.

The Java programming language, released by Sun Microsystems in the mid-1990s, was originally intended to be used in consumer electronic devices such as personal digital assistants, cable access boxes, television sets, and other devices that required simple user interfaces. The language was designed to be hardware-independent by compiling to an artificial byte-code instruction set that could be easily implemented in an interpreter on almost any microprocessor device.

As the Internet and World Wide Web gained momentum, Web page authors wanted to add features like animation and interaction to their Websites. Since the Internet browsers had to run on a large variety of different computer platforms, the browser manufacturers found that the Java programming language, with its platform-neutral instruction set, was a good fit. The software could be compiled once, placed on a Web server, then run on any Java-enabled browser on a PC, Mac, UNIX, or other machine. Besides being platform-independent, the compiled files were small and moved quickly over the Internet.

Legacy software—the words conjure up images of glass-walled rooms, guys with crew cuts, lab coats, and horned-rimmed glasses, COBOL, FORTRAN, RPG, ISAM, line printers, tape drives, and maybe even punch cards: everything that's ancient and evil, old and obsolete. This is the image that vendors want their customers to see as they show off their latest client/server tools. But in reality, legacy software is a core resource. Those ancient COBOL programs are the tools that keep the business running smoothly. If this were not true, the Y2K problem would never have been an issue and all of this ancient software would have been replaced long ago. It is a tribute to those old COBOL programmers that the code still plays an important part in their organizations 15 or 25 years later.

This chapter will examine how to integrate application server technology into the existing information system environment. Topics will include:

• Design issues for application integration

• Application mining

• Turning subroutines into services

• Input and output streams

• Accessing application databases

• Synchronizing transactions

Design Issues for Application Integration

When approaching application integration, remember that there is no one best solution. Integration tasks will vary depending on the hardware and software platforms, system architecture, communication links, data models, and a host of other factors. The level of integration may also vary based on the amount of information needed and the directions of data flow. A task may require a simple data transfer, or it may need to share procedural code. What worked when linking to the general ledger system may not work when accessing inventory.

Setting up a development environment for distributed processing does not have to be complex or expensive. Much of the program code written for this book was developed on a single Pentium 200 MMX machine. Additional testing was done by networking it with a Pentium 133 running NT Server. This machine was built from spare parts, and I think that NT and SQL Server probably cost more than the computer. I also used the Java SDK, Borland's JBuilder, and Microsoft Access.

This appendix will describe the two configurations, as well as how to use them to compile and run the program examples. The topics covered will include:

• Development using a single computer

• Development on a network

• Compiling and testing Java and RMI

• Setting up JDBC

Development Using a Single Computer

Experimenting and testing Java, RMI, and JDBC only requires a single computer. Windows 95 and 98 do a good job of multi-tasking, so there is no reason to go through the trial or expense of networking a second computer. Working on a single computer also saves wear and tear on the chairs and carpet moving back and forth between computers.

Figure A-l shows the processes that must be running to make RMI work on a single computer. Before the application server and the applet can communicate, you must have the RMI registry running on top of an Internet server. For you to use JDBC, you must also have the appropriate drivers and database server running. All of these processes take quite a bit of memory, so the more memory in the machine, the better.