Electronic commerce has emerged as a critical aspect of doing business. For many firms there is no separating electronic commerce from regular commerce; the two have become increasingly intertwined. For Cisco, orders over the web have increased from less than 10% in 1996 to roughly 85% in 1999. As a result of these dramatic shifts, there has been an equally dramatic set of changes in the way business is done using electronic commerce. Increasingly, firms such as Cisco are using electronic commerce to simplify their business processes and improve customer relationships (Riggs 1999).

The electronic commerce phenomenon has occurred at roughly the same time as the ERP phenomenon. Further, both are highly dependent on changes in processes to accommodate the new technology, which leads us to ask: “What are some of the relationships between the two?” This chapter explores that question by first establishing ERP as one of the primary building blocks of electronic commerce and then eliciting the role of ERP in each of a number of major electronic commerce initiatives: order tracing, order configuration, order placing, vendor-managed inventories, build to order, and merge in transit.

Building Blocks for Electronic Commerce

What are some of the building blocks for electronic commerce? ERP provides a repository for the information. Communication networks facilitate access to the information. Wide availability and easy-to-use access make it possible to get ERP information over the Internet.

Access to ERP information was at first limited to the reports that could be generated from the system or through database queries of the underlying database model. Recently, however, organizations have begun to employ intranets and data warehouses to further distribute ERP-generated information. In addition, ERP vendors have begun to develop “portals” that are designed to provide users specific access to a range of information. This has led to improvements in ease of use and hence to new opportunities in electronic commerce for ERP vendors.

ERP Reporting and Query Capabilities

With ERP systems, information is made available to particular users in the form of specific reports. In addition, there are other approaches to generating data from the system, including database queries. Recently, ERP reporting capabilities have begun to evolve as ERP vendors have tried to increase the accessibility and ease of use of the ERP software.

ERP Reports

Enterprise resource planning systems can generate a wide range of standard reports that are designed to meet standard decision-making concerns. The reports that are available depend on the particular module of interest. For example, financial modules produce classic financial reports, including income statements and balance sheets.

However, ERP reports do not always meet the users' needs, as will be seen in a number of examples in this chapter.

The primary tools for capturing and implementing best practices are enterprise resource planning (ERP) systems. As noted by Hammer (1997), “SAP implementation equals forced reengineering.” A vice-president of Cap Gemini remarked that, regarding SAP implementations, “it's rare when you don't have to do some kind of reengineering” (Gendron 1996). Gendron goes on to call ERP “the electronic embodiment of reengineering.” Because reengineering is so tightly tied to ERP implementation, firms must address the issue of using clean slate versus technology enabled reengineering.

The purpose of this chapter is to investigate the relationship between these two types of reengineering. In particular, this chapter elicits some of the advantages and disadvantages of each approach, focusing on why some firms have chosen one or the other approach as part of their reengineering efforts. In addition, this chapter investigates some of the firm characteristics that are likely to lead to using a particular reengineering approach.

Reengineering Tools and Technologies

Hammer's (1990) ideas for reengineering were initiated before there were tools to facilitate reengineering. Many early reengineering efforts were designed to “obliterate” existing processes, but there were few tools to guide firms as to how the processes should be reengineered. As a result, one of the primary reasons that many reengineering efforts failed was the lack of a sufficient tool set to facilitate reengineering. An early analysis (CSC Index 1994) of tools that were used in reengineering focused on process value analysis, benchmarking, competitive analysis, and activity-based costing.

One of the most important issues in the ERP engagement is training. According to the CIO of Brother Industries, “[t]he easiest mistake to make is underestimating the time and cost of training end users” (Fortune 1998, p. 151). An implementation will be a failure if the software runs perfectly, but employees don't know how to use it. Despite the importance associated with the need for ERP training, a Benchmarking Partners survey of 150 sites found that 43% indicated that the amount of training was the biggest surprise encountered (Stedman 1998b).

However, training encompasses more than just users; the training concerns of implementors must also be addressed. Moreover, training is not simply one step in the life cycle just before or just after implementation. Rather, training is embedded in each part of the life cycle. We therefore discuss training within its own chapter.

Frequently Asked Questions about User Training

• How should user training be timed?

• How much training should users get?

• How do you make up time lost on training?

• When should you train?

• How can employees be encouraged to train?

• How much should training cost?

• What is in the training materials: information technology or rather business information?

• Should you use script-based or general support materials?

• How should training be structured?

• Can faster training be developed?

“Phased” and “big bang” are the two primary (and contrasting) approaches used to implement ERP systems. This chapter investigates what these terms mean, some properties of each approach, and some of the advantages and disadvantages of each. This chapter also analyzes the choice of the implementation methodology in light of organization size, complexity, and structure and in terms of the overall extent of the implementation. Finally, some additional terms and approaches used to implement ERP systems are discussed briefly.

What Is a Big-Bang Implementation?

In a full big-bang implementation, an entire suite of ERP applications is implemented at all locations at the same time. Using big bang, the system goes from being a test version to being the actual system used to capture transactions in only a matter of days (hence the name “big bang”). Big bang requires simultaneous implementation of multiple modules. In the case of Quantum (see the appendices of this chapter), this meant implementing 17 modules of Oracle applications at 23 sites around the world over a period of about one week. Under this scenario, big bang requires a large amount of testing before cutting over from legacy systems to the new system. In the case of Quantum, this meant six to eight months of system testing prior to going “live” and actually using it to process transactions.

This chapter analyzes some of the different rationales associated with deciding to go with ERP. In particular, this chapter examines four questions.

1. (1) What are the business case rationales used for determining whether or not to go ERP, and which are most frequently used?

2. (2) How can business case rationales be used to facilitate design or measure success?

3. (3) How do firms measure rationales: in monetary or nonmonetary terms?

4. (4) How does a firm ultimately decide to go ERP?

Business Case Rationales

Business case rationales for ERP systems can be grouped into four different sets of categories: technology, business process, strategic, and competitive. Each of those rationales has different strengths and limitations. This chapter illustrates rationales from each category.

The choice of business case rationale is important for at least three reasons. First, critical analysis is necessary to ensure that the firm makes the correct decision regarding ERP. Ultimately, that analysis can generate a number of different rationales or arguments used to substantiate ERP adaptation. Second, in some cases, the basis of choice can facilitate ERP design, providing design specificity. For example, if the goal is to improve a specific process then the extent of that improvement can be measured. Third, the basis of choice can facilitate evaluation of the success of the implementation, based on whether the business case rationale was successfully met. Different measurement approaches can provide a basis for determining success.

Building a system based of distributed objects is not the same as constructing a single object-oriented program. We need to take into account the effects of the network, the fact that we can have tasks interacting while running in parallel, and the possibility of partial failure. Implementing mechanisms to handle failure and coordination of concurrent processes (which will be covered later in the book) may be extremely important; however, the choices we make when designing distributed objects profoundly impacts the performance and flexibility of the system.

It's not enough to take an object model and just distribute arbitrarily, placing objects throughout the network without further consideration. Once we have decided on how to distribute the functionality of the system, we need to spend time and energy defining the interfaces to the distributed objects. Additionally, new users to distributed objects and CORBA commonly encounter problems in identifying the best level of granularity for their distributed objects. Incorrect identification can make the resultant system performance far from satisfactory. Finding alternatives may be too late when you no longer have the time or resources for improvements.

When you initially design your system's distributed objects, you will be concerned with each object's interface, the object model's granularity, and how the complete system is partitioned. The granularity of the object model refers to the scale of abstraction and tasks embodied by the objects and their associated methods.

Over the past few years, I have been giving presentations on distributed systems and CORBA. My focus has been on the design and architecture of such systems. In each presentation I refined my ideas and thoughts. It seemed the next logical step to produce a book on the same subject. If the audiences I have seen are indicative, there is a definite need to share information on the construction of distributed systems. Our field improves with the flow of information: the ability to learn and build upon each other's experience. This book is a contribution from my coauthors and me to the codification of the principles of distributed object architecture.

Software architecture, by its nature, is rather ephemeral and not easy to write about. There are various ad hoc approaches to architecture, and it has only been in recent years that we have seen increase in work to codify architectural principles. Part of this codification is the adoption of design patterns from the work done in real-world architecture by Christopher Alexander. There is a growing literature on design patterns, and the use of patterns goes some way to helping with the construction of complex distributed systems. We will now take a quick look at what architecture means for the world of software and lay the groundwork for the rest of the book.

What Architecture Is

If you were to look up the definition of architecture in a standard dictionary, you would find that architecture is the “art and science of designing and constructing buildings.”

Why would you want to implement a system using distributed objects? Maybe you have written a client/server system using other technologies (such as TCP based sockets, RPC or DCE). You may wonder what the motivation is to move to “distributed objects”? To answer that question, we will first review the benefits of object-oriented technology; then we will see how these benefits are utilized when object-oriented technology is taken to the network.

Object-oriented concepts, tools, and techniques have been with us for the best part of three decades. During that time the technologies based on object-oriented principles have matured: languages, development environments, case tools, and databases. Applications have become more distributed in nature. Development tools have matured to support the construction of distributed systems.

Quick Review of Object-Oriented Concepts

This book doesn't aim to teach you object-oriented concepts. In this section we will merely review some of the salient aspects. For further information, I recommend that you read one of the many books on object-oriented design such as “Object-Oriented Software Engineering” by Jacobson et al. (See References at the end of this chapter.)

Over time, systems have increased in complexity. Software construction had to match that complexity. The object-oriented paradigm enables us to manage the complexity of modern systems. Complexity is handled through classes, inheritance, polymorphism, and objects.

Use of the Internet has exploded since the first Web servers and browsers were introduced to the public in 1993. Everyone is producing Webenabled versions of their applications. Companies are using the Web to provide services to their clients and employees. Almost every new project ends up having some Web component. Applications that make use of distributed objects are not unique in this respect; in fact, technologies like CORBA that provide the “universal object bus” are a good marriage with Web technologies that provide the “universal user interface.”

In this chapter, we take a look at distributed object architectures for the Internet. How to integrate CORBA with Web technologies and the interaction of CORBA with Internet security mechanisms. We will then also look at upcoming standards and how these can be integrated with CORBA—specifically, the use of Extensible Markup Language (XML) and the next generation of HTTP (HTTP-NG).

Architectures

Two types of CORBA-based architectures exist for the Web. The first is when your applications speak IIOP over the Internet: the client application can communicate directly with your CORBA objects. The second is an architecture in which a gateway is built that translates from the standard Web protocols to CORBA: an indirect communication exists between the client application and the CORBA objects.

Your decision on which architecture to implement will depend on various factors. How much influence do you have over the end user's environment?

When we started the Object Management Group a decade ago, we could only hope that writers of the caliber of Henry Balen would take up the cause. I can remember those early days where we spent most of our time trying to explain to anyone that would listen why object technology was important. In the last ten years it has become an ever increasingly complex world, one where homogeneity of platforms is almost unheard of, and where legacy applications continue to be an integral part of the mix. It has become apparent that the old does not always make room for the new when it comes to enterprise applications. It has also become apparent that understanding the architectural issues involved in designing and structuring systems based on distributed objects is one of the major keys for successful deployment. The industry consolidation behind such standards as Common Object Request Broker Architecture (CORBA), the Unified Modeling Language (UML), and the Meta Object Facility (MOF) have immensely helped to make analysis and design easier. Moreover, there are better tools out in the market than ever before, but we have yet to automate architecture—which provides good job security for those who understand the issues!

Henry Balen's efforts in this book should provide a jump-start to those who are planning on building distributed systems using object technology. The importance of architecture cannot be overemphasized.

Every day we perform transactions. A transaction is an interaction that involves an exchange; this could be monetary, information, service requests or other information. In addition, all the steps in a transaction have to happen or none at all. Quite often the first thing that comes to mind when transactions are mentioned are monetary exchanges, like the transfer of funds from one account to another or the use of automatic teller machines. The one thing that all transactional systems have in common is the requirement to maintain the integrity of the information. You do not want to transfer funds from your bank account to another bank only to find that the money has been lost in the ether.

Information regarding business transactions used to be kept in written ledgers; this provided a form of indelible record which could be audited and easily (though painfully) accounted for. It also used to take some time to perform the transfer of funds—on the order of days. This was fine for relatively small volumes of transactions. Nowadays in the hectic bustle of the modern capitalist world, we can easily see millions of transactions taking place on a daily basis within just one institution. The information for these transactions is stored within databases and passed between systems electronically over networks. While this is more efficient than the written method, it is also more volatile.

Like people, real systems suffer from the vicissitudes of a whimsical reality. An architecture built according to the basic precepts discussed thus far would doubtless be flexible, scaleable, and able to handle the desired business functions with panache—but when actually deployed, it would probably fail in some way. Like people, real systems suffer. Your system might freeze at 12:17 AM every Saturday, slow to a crawl during a critical usage period, crash only when the project sponsor's boss logs in, or simply be hit by a power failure during a critical transaction. Above and beyond the dictates of good theoretical system design, systems architectures in the real world must be designed (and constructed) with an eye for the uncertain world of deployment.

Required Characteristics

Distributed systems must possess certain characteristics to function reliably after deployment. Several of these characteristics pertain to maintenance of quality of service, which is essential in the face of unforeseen interruptions in the flow of operations.

• Stability. When one part of a system fails, it can cause other parts of the system to fail. Even if a failed subsystem restarts, it may not be able to initialize itself properly if it depends upon other system elements that have also failed. Thus, the system may thrash as the failure cascades through the system in a chaotic manner. Dependable systems must be stable.

• […]

Any system you build can become a potential target for misuse and attack by either the curious or the malicious. Regardless of the reason for the intruders' invasion, you will want to provide some measures to protect the system. To be realistic, rather than paranoid, your security policy and implementation will depend very much on the nature of your business and its associated risks. For this very reason, security is a term whose meaning changes dependent to whom you are speaking.

As well as security for business reasons, there is also the need for security for social reasons. Most respectable business will want to protect the privacy of their customers; it is difficult to give privacy assurances to potential customers if you have not implemented any security mechanisms. This goes beyond securing a transaction for an online purchase. For example, you may want to run an ethical online business and assure that information collected about your customers will not be used for nefarious marketing purposes.

In this chapter, we will be looking at what it means for a system of distributed objects to be secure. First, we look at what security is and what you need to consider when determining your security policy. Next we will review the salient features of the CORBA security service; this will help you gain an understanding of how the security service works.

A key part of object-oriented software development is mapping design model entities to implementation model classes. Although we are used to thinking of object instances as the primary players in a runtime system, it is in fact the conceptual entities that they embody, not the instances themselves, that are truly important. Objects come and go, but what they represent lives on in the “minds” of clients. For example, a client invocation may require activating a service and instantiating a new object; or a single entity might be represented by objects in multiple processes in a system with load balancing; or a business entity can exist in a persistent data store and then be incarnated as objects in multiple services. Thus, what appears to be a single perpetual entity to clients may not currently exist as a physical runtime object, or may exist as multiple objects.

This difference between conceptual entities and the objects that serve as their vessels lies at the heart of the areas of life cycle and persistence. Questions raised by the entity/object duality that must be applied to every entity include:

• How is the entity identified so that objects know what they are implementing?

• What process or processes should the implementation objects live in?

• Does the entity exist only when an implementation object is created?

• Where and how is an entity's state stored if it exists beyond the implementation object?

• Can an implementation move?