The Importance of Architecture

The Brooklyn Bridge took thirteen years to build. An architecture was used to guide the work breakdown whereby separate components were constructed in various locations and assembled into the growing superstructure called a bridge. The architecture - the overarching design - provided the cohesion and coherence of the components so that their assembly would result in a complete, whole bridge. 

Like the Brooklyn Bridge, an overarching design is needed to guide the construction and assembly of e-Commerce initiatives into the growing superstructure called a digital enterprise. Unlike the Brooklyn Bridge where traffic could not commence until the entire structure was constructed, the digital enterprise need not be fully built before a company can implement its digital business initiatives. Business goals, objectives and constraints will determine which initiatives and how much infrastructure will be implemented at each step along the way. Developing a solid business and technology architecture is hard work but results provide the cohesion and coherence needed so that as a company's e-Commerce initiatives grow, they fit in and interact with the growing superstructure of the fully digital enterprise.

Corporations and their value-chains are large, dynamic and complex systems. Further, they must evolve within even larger systems including the industries in which they participate and the overall economy. Large, complex and rapidly changing are three facts of life for the corporation and its business ecosystem. Given these fundamental characteristics, how does a company manage its business and its technology? Business and technology leaders have grappled with the complexity of enterprise-class information systems for some years. They have learned that an architectural approach is essential to conceiving, designing, building and maintaining these large and complex business systems. The design goal of an enterprise architecture, containing robust and interchangeable business and technology elements, is to provide a coherent framework for managing complexity and change. 

An enterprise architecture provides the blueprints, the structural abstractions, and style that rationalize, arrange and connect business and technology components to achieve a corporation's purpose - now and in the future. All businesses have an architecture, albeit implicit. The components usually include past, present, and next generations of business policies and processes as well as past, present, and next generations of technologies. For example, adding new electronic sales channels with their unique policies and processes requires that a company continue supporting present sales channels while incorporating the new processes and systems of the new channels. 

Without explicit enterprise architecture, chaos will reign. Business and technology changes are certain, and thus an enterprise architecture must provide a framework for change. The changes that result from designing new business models or from adopting new technologies should not hinder the other. Thus change itself is one of the strategic goals of enterprise architecture and enterprise architectures must be living documents. 

While a complete discussion of best-practice enterprise architecture is beyond the scope of this book, the suggested readings will be useful to those readers who are new to architecture-centric business and technology processes and methods. The focus here moves beyond enterprise architecture to inter-enterprise architecture. The first principles of enterprise architecture are extended to form an overarching structure for the business and technology components needed at the boundaries between and among enterprises: customers, suppliers and trading partners. 

In addition to the elements of enterprise-scale architecture, inter-enterprise architecture adds new dimensions, challenges, and complexity. At the boundaries, technologies and business models are not only disparate, they are beyond the control of any one participant. Thus rules of engagement must accommodate collaborative integration that maintains the integrity of the participants' business policies and processes. These rules of engagement, because they are in the nether land between participants, must be explicit, unambiguous and universally agreed to - in short, they must be based on standards. 

Standards are essential to inter-enterprise architecture and those standards must include both technology standards (e.g.. XML, EJB, COM+, and CORBA) and business standards (e.g. OFX for payments, OBI for open MRO procurement, ICE for information content exchange, and SWAP for Simple Workflow Access Protocol). Third wave companies have learned that e-Commerce has so many facets that reach into the core of the business that its architecture should mirror that of not only the enterprise, but of the business ecosystem in which it lives. Thus, standards-based inter-enterprise architecture is the linchpin of third wave e-Commerce. 

The problem with standards, of course, is that there are so many de facto and de jour standards from which to choose. The best strategy is to pay close attention to standards most relevant to a company's industry and to adopt open standards, where possible, or to migrate to open standards when they become available. Open standards provide the greatest opportunity to achieve the critical goals of portability and interoperability. Standards are integral components in a sound inter-enterprise architecture. The well designed architecture should be able to accommodate change in its standards related components. 

The task of transitioning to a digital enterprise is, of course, not a single event. It will not happen overnight or be implemented as a "project" to be handled by the IS staff. Companies are not changing their information systems, they are changing the very way they conduct business, the way they operate. E-Commerce is first and foremost the extension of business, not technology. The nature, size and sheer complexity of building the ultimate digital enterprise demands that companies develop an overall inter-enterprise architecture, and implement the architecture's components in a step-wise fashion. Because of the absolute need for quality in each component in these mission critical systems, business and software engineering disciplines are essential. Architecture and these engineering disciplines are the keys to building the ubiquitous business. 

Inter-enterprise Architecture

Jim Champy, known for helping to launch the business process reengineering (BPR) revolution, describes this new age of logistics. "Re-engineering has been mostly about breakthroughs in getting the right stuff out the door. But there are huge productivity gains left in processes that link companies to their suppliers and customers. It goes well beyond the outsourcing of a single function, and it will be driven by the need to deliver a higher level of customer service than a single company can. To make all this work, a company's technology architecture now will have to encompass what's external as well as internal to its operation."

People, process and technology are the ingredients of business architecture. As shown in Figure 8.1, inter-enterprise architecture addresses "process" from three key perspectives: existing business processes (and the systems that implement them), value-chain processes, and customer-facing processes. For companies that have changed from product-centric to customer-centric, customer-facing processes serve as the capstone, binding together all other elements of the architecture. By focusing first and foremost on customer-facing processes, context is provided for the other components of the architecture: technology and people.

Figure 8.1. Inter-Enterprise Architecture

At the center of the architecture, emphasis is given to value-chain processes which are the essence of business-to-business e-Commerce. Having determined the requirements, goals and constraints of customer-facing processes, architecting value-chain processes is a matter of reconciling and optimizing the value delivered by a company's trading partners and its existing business processes. Value-chain processes will likely be subject to new forms of electronic mediation and aggregation different to those in the physical, paper-based world. An early effort aimed at these notions is Hewlett-Packard's e-Services. Industry analyst Patricia Seybold explains, "We're about to embark on a new era in which most companies will begin to focus on a few very strategic business processes. Innovative companies will package up their strategic processes as services that can be provided and/or launched via the Internet. Soon, many business-to-business activities will be handled by a series of e-services locating one another, negotiating with one another, and handling each other's requests." Service-oriented, inter-enterprise architectures are essential to value-chain innovation. The foundation for a company to participate in new value chain structures and processes is a company's existing business processes and systems. They must be adapted to participate in the new service-based systems. 

Together, these three process architectures identify how the people and technology pillars need to be realigned to support successful e-Commerce transitions and programs. Corporations will have to adopt new technologies and transition staff to new roles and new skills. An overall inter-enterprise architecture allows change to be carefully managed by explicitly identifying those facets (architectural elements) that need to be monitored and controlled as a company transitions to and manages e-Commerce as a new platform for business. 

The Inter-enterprise Process Engineering Process

E-Commerce is not an end state. It is a new business platform that will grow and evolve. The secret to sustainable e-Commerce success is to think and plan in terms of overall architecture, but act in incremental steps. To manage risk, a company's very first e-Commerce initiative might well be a simple "paper replacement" project to demonstrate the proof-of-concept in a well controlled, internal environment. Processes are untouched, just the user interface is modified. Then the scope of the project can be expanded to include easily managed process changes. With experience gained, the program can move on to engineering processes that cross corporate boundaries.

Figure 8.2 shows the major steps in transitioning to e-Commerce as a way of business. Companies cannot go it alone. Before inter-enterprise teams can be effective they need to build shared vision. This can be accomplished through educating all participants about e-Commerce and its many business dimensions. With an initial working knowledge in hand, inter-enterprise assessments are needed to identify the capabilities and readiness of participants in new e-Commerce ecosystems, which in turn will lead to an initial inter-enterprise architecture describing the levels of e-Commerce integration: simple hand-offs, process alignment, or joint execution of business processes. A combination of these process arrangements may need to be supported in a given ecosystem. Assessment provides the foundation for developing the initial inter-enterprise architecture and development plans. Such plans must be validated before opening e-Commerce systems to the world. It is, therefore, essential that a proof-of-concept pilot be carried out in order to manage risk. Because e-Commerce introduces change in virtually all facets of business operations and technology development, a proof-of-concept project provides a controlled environment. A proof-of-concept project must incorporate the dimensions relevant to any other e-Commerce project, but its scope, duration and pace of development allow for climbing the learning curve.

After successful completion of one or more proof-of-concept pilots, the development of e-Commerce initiatives should proceed in a sustainable manner. By implementing a program management organization, the architecture can be refined and infrastructure resources added as projects come on stream. As shown in the figure, parallel initiatives can be undertaken, sharing a common architecture and management organization. Each project or initiative should adopt an incremental delivery approach. Deliverables should be time-boxed to six months or less. By providing deliverables frequently, changes in business priorities and direction can be accommodated. Frequent deliveries build credibility with customers and enhance developer morale. The multi-year monolithic development cycles of the past cannot be tolerated in the world of e-Commerce. 

Figure 8.2. Transitioning to e-Commerce

Key Processes of E-Commerce Program Management

Both program and project management are needed to oversee the development and growth of e-Commerce initiatives. Program management involves three critical processes: building shared vision, conducting gap analysis and building inter-enterprise work teams.

1. Build Inter-enterprise Shared Vision through Education. A picture of the future is required if a company is to know where it is going and what it is trying to build. Corporations cannot possibly arrive at their destinations if they do not have a clear vision of where that is. Few concepts are more mysterious than corporate vision: shared visions are not pearls of wisdom handed down from an enlightened CEO. Instead, shared vision bubbles up from individual vision - from customers, suppliers and individual employees. Shared vision brings about common directions, focus, and the motivation for personal, team and organizational learning. With genuine shared vision, not imposed corporate vision statements, all workers across the organizations of inter-enterprise endeavors are able to keep their eyes on the prize. 

2. Conduct Inter-enterprise Architectural Assessments and Gap Analysis. Peter Senge is Director of the Systems Thinking and Organizational Learning Program at MIT's Sloan School of Management. Senge calls systems thinking the "5th discipline" and the cornerstone of the learning organization. To be successful, e-Commerce teams must be masters of general systems thinking. 

Systems thinking provides a new perspective to business process analysis and redesign. For example, can you imagine holding up your hand a foot before your face and blocking your view of the earth, the entire earth? Astronauts have been able to do that. The world looks drastically different from their perspective. They see the whole earth. Unfortunately, we only see bits and pieces of our company and industry in our earthly day-to-day work. Today's businesses need an astronaut's perspective of whole, end-to-end, value-chain processes. Systems thinking is a formal discipline of management science that deals with whole systems and with the interconnections and interactions of the individual parts. Systems thinking is also a learning method. Business team members can make assumptions about improved business processes and test those assumptions with the systems model. Feedback closes the loop and causes learning.

If it ain't broke, break it. One of the key principles of systems thinking and architecture is to envision what could be in a perfect world. Then, the real world is assessed against the desired state. The resulting gap analysis is used to plan the resources and tasks needed to reach the desired state in the desired timeframe. Innovative business processes are not extensions of existing processes, they are discovered by new ways of thinking, unencumbered by entrenched mental models and ways of conducting work.

Applying the first principles of systems thinking, e-Commerce teams can analyze the entire business ecosystem and discover opportunities for breakthrough value propositions made possible by the e-Commerce business platform. The analysis will focus on the new business capabilities afforded by the Net:
 

These questions guide the assessment of inter-enterprise architecture from two perspectives. First, a green field or "could be" architecture is envisioned and documented. Then current architectural elements can be documented, providing a description of the "as is" architecture. Gap analysis then ensues, revealing the people, processes and technology needed to implement elements of the new architecture. The result of assessment and gap analysis forms the basis for developing an initial strategic (strategy) plan for e-Commerce. 

3. Build Inter-enterprise Organizations and Work Teams. Peter Senge asserts it is possible to create learning organizations. In addition to the cornerstone, systems thinking, he describes four other core disciplines required to build such an organization.6 The core disciplines include personal mastery, working with mental models, building shared vision, and team learning. These disciplines are not necessarily in the policy manuals of personnel departments of today's corporations nor in the realm of our individual thinking. They are, however, central to the success of e-Commerce in the new business ecosystem. 

With the focus on general systems thinking and an architecture-centric approach to systems development, the tasks, knowledge and skills inherent in e-Commerce environments can be packaged into new roles and organizations for handling the work responsibilities. A few of the new roles are highlighted below, although a much longer list can be associated with architecture-based development of e-Commerce systems: reuse managers, quality assurance managers, configuration management specialists, business object modelers, object-oriented programmers and Internet technology specialists. If a company already has adopted object-oriented development approaches, many of the needed roles are probably already in place. After exploring some of the new roles we can then look at how e-Commerce affects organizational design. 

E-Commerce Program Managers have line authority over enterprise-wide e-Commerce initiatives and projects. They are tasked with e-Commerce integration and managing an overall business and technology architecture and infrastructure. They are senior-level line managers who are effective at bridging the divides between business and technology units within an organization and across the extended enterprise. 

Enterprise Architects define, align and refine the overall inter-enterprise architecture. They carry out many of the tasks of program management and provide guidance so individual projects can make optimum use of infrastructure resources for e-Commerce. They do the balancing act between business requirements and technological capabilities. On individual projects, enterprise architects help identify the requirements, goals and constraints of the project. They allocate responsibilities for each of the architectural elements and coordinate the modeling and design activities for the overall enterprise architecture. They are the chief architects of e-Commerce and coordinate the work information, infrastructure and application architects. 

All architects and modelers should be completely versed in design patterns common to the many facets of business and technology. The design pattern movement has affected all aspects of analysis, design, and implementation of component-based systems. Design patterns are the reusable material of architecture and represent a watershed in the way complex, distributed information systems are conceived and developed. Much of the activity in software design patterns reflects the work of Christopher Alexander who developed the first principles of the discipline in relation to building architecture. 

Business and Information Architects are steeped in business domain knowledge including business processes and logical information structures. They coordinate the work of business and technology analysts and modelers who develop abstract representations or business object models of the subjects, rules, roles, events, tasks, activities and policies of the business domain. Business object models describe a logical domain irrespective of applications. Such application-neutral models enable the reuse of business engineering analysis and design patterns and artifacts. 

Infrastructure Architects identify the technical services required of the technology infrastructure to empower and support the logical business and information architecture. They evaluate existing infrastructure services, select those appropriate to a given project and acquire (via build or buy) new components needed in the infrastructure. They oversee the work of technical specialists in modeling the services architecture of the technical infrastructure. They maintain the technical components of the development repository. 

Application Architects coordinate the business process modeling activities across multiple projects and business domains. They coordinate the work of domain modelers and maintain the repository of business and component models. They evaluate existing business component services, select those appropriate to a given project and acquire (via build or buy) new components needed in the evolving business model. They maintain the business application components of the development repository. Most importantly, they guide solution developers in blending the business object model with the infrastructure services needed to implement the models in an e-Commerce platform.

Solution Developers are application developers. They develop the use cases for the specific application at hand, compose solutions through extensive use of business object models and use case repositories They assemble application components to implement e-Commerce applications. Unlike conventional programmers or programmer/analysts, they do not build or program components. Instead they assemble or glue together business solutions from prefabricated components. They use highly integrated development environments (IDEs) such as IBM's VisualAge, Symantech's Visual Café, Sybase's PowerJ and Inprise's Jbuilder. Emerging Computer Assisted Software Engineering (CASE) tools and related methods will likely appear that tighten the link between business modeling and software development. Tools for understanding and managing business processes, such as Intellicorp's LiveModel™, will likely evolve to the e-Commerce development space. Today, LiveModel™ allows solutions developers to build logical business models that can automate the configuration and management of the SAP/R3 ERP system. 

Solution developers likely come from the ranks of experienced object-oriented developers since the component paradigm is the next step beyond objects, not a replacement. Their knowledge and experience can be levered and built upon for component-based development. 

Component Developers build components. They are masters of component technology and know the intricacies of composition, delegation, and object-oriented systems analysis and design. They are proficient in component development languages (such as Java and C++), modeling standards (such as UML and XMI), and distributed computing platforms (such as CORBA, DCOM, and EJB). They understand and think in terms of architectural design patterns. 

As high quality business components and application frameworks become commercially available, component developers working directly in business enterprises will be fewer and fewer as they will likely work for software development companies. In the meantime they will close the gap between business requirements and available components. Component developers must be highly qualified software engineers since quality components do not just happen. They are carefully constructed using quality software engineering disciplines. Component developers, therefore, must be highly trained specialists and masters of software quality processes such as CMM and ISO as well as masters of component-based development methods. 

Human Factors engineers are needed to design the next generation of user interfaces. While the graphical user interface (GUI) is recognized as the enabler of wide-spread personal computing, task-centered user interfaces provide assistance to end-users and can be a boon to productivity in the world of e-Commerce. E-commerce transactions can involve a multitude of complex steps and processes. Well designed user interfaces can help navigate and guide the user through these tasks, keeping track of progress, and picking up where users leave off when transactions span multiple sessions of work. 

Human factors engineering has never been of such importance to applications development. In the race to engineer customer processes that delight, the differentiating factor among e-Commerce systems is helpfulness, not just the prettiness of the GUI. Researchers in the field of Human Computer Interaction (HCI) are very active in researching and developing task-centered user interfaces. Whether through hiring experts or engaging them as consultants, winning e-Commerce development teams will have a human factors specialist at the planning table and at the development workbench. All participants in any e-Commerce development effort should read Donald Norman's Design of Everyday Things before even thinking about designing customer-facing processes. 

The new business models of e-Commerce require new organizations. In today's interconnected economy, companies discover that they cannot innovate alone. James Moore explains that organizational form follows function. "The old multidivisional firm (the M-form) is giving way to the ecosystem form (E-form) where networks of complimentary functions are established to deliver end-to-end business processes to existing and potential markets." It is the degree of integration made possible by the Internet that allows this new business form. In the future, connections in the E-form will occur dynamically, on the fly. The value-grid will replace the value-chain in business-to-business ecosystems.

Transitioning a company to the E-form is certainly no short term proposition. Building and maintaining trading partner relationships is a lot of work requiring a lot of time, energy and insight. Even for the short term, where initial e-Commerce initiatives are launched to go after low-hanging fruit or in response to competitive pressure, new organizations are needed. As a new channel of business, the embarking on an e-Commerce path can be likened to starting a new business, whether from scratch or through merger or acquisition. As with any business endeavor, e-Commerce initiatives require human, financial and technology resources. In addition, it is reasonable to assume that the employees and organizations conducting today's business are fully occupied, if not overworked as a result of downsizing. Furthermore, e-Commerce initiatives introduce radical change in the ways work is done to a workforce already entrenched in the current ways of working and thinking. Changing the mental models of an established workforce is often costly and painful. As a result, it is not uncommon for corporations to spin off separate e-Commerce companies to gain agility and the benefits of green-field development - to wit, barnesandnoble.com, Inc., owned equally by "bricks-and-mortar" retailer Barnes & Noble and German media giant Bertelsmann. In both the short term and long, organizational design is a critical issue of e-Commerce strategy. 
 
 

Key Processes of E-Commerce Project Management

With an overall function of program management established, multiple e-Commerce projects may be undertaken simultaneously, in parallel. Four key processes are involved in project management: engineer customer processes; engineer value-chain processes; engineer internal business processes; and incrementally develop e-Commerce applications.

1. Engineer Customer Processes. The task of engineering customer processes is paramount, and can only be done with the full and direct participation of customers themselves. After all, in business engineering terms, the customer is the process owner. Through a process of outside-in design, customer processes become the requirements specifications for value-chain process engineering. Customer processes are expressed in terms of the services they require. Each customer will want to customize those services and subsets of them to optimize their information and buying activities.

In business-to-consumer applications, customers will increasingly seek total solutions to their buying needs. For example, buying a car involves financial, legal and insurance services. Customer processes must have access to all the information and all the services needed to form a total solution. In business-to-business applications the customer's internal business processes must interact with those on the e-Commerce boundary. For example, a typical purchasing application will require internal requisitioning workflows, approvals and processes as well as those related to the external e-Commerce transaction. 

2. Engineer Value-chain Processes. Process integration between and among actors in the value chain is the essence of inter-enterprise process engineering and business-to-business e-Commerce. As shown in Figure 8.3, e-Commerce process integration can be measured at three levels: data handoffs, process handoffs and shared real-time processes. 

Figure 8.3. Inter-enterprise Process Integration Levels

Without process integration, simple data handoffs occur between participants in e-Commerce transactions. At this level of integration, e-Commerce is simply a media replacement for paper. At the next level, e-Commerce transactions trigger the processes in the systems of other participants. For example, an order processing system of a retailer may trigger inventory status processes within a supplier's system - the processes in the e-Commerce transaction are aligned via process handoffs. At the highest level of inter-enterprise process integration, processes in the e-Commerce space are jointly owned and interoperate in real-time. The user of such systems cannot tell which sub processes are running on whose internal systems - the user is interacting with and consuming ubiquitous e-Services. Full process integration gives each player in a value-chain full access to information and services, both up and downstream in the value-chain. For example customer information is available throughout the value-chain, not just to the "seller." Such information sharing can allow each participant in the value-chain to optimize its performance. These fundamentals are essential in value-chain to value-chain competition.

As open markets continue to emerge, a combination of these three process arrangements need to be supported simultaneously in a given ecosystem. Players in a value-chain will have differing technological capabilities and readiness for process sharing. For example, a mom-n-pop specialty manufacturer of components may not have a computer but can participate in an e-Commerce a value chain by fax, just like in the traditional world of commerce. Others in the same value-chain may participate only by email, while yet other participants are connected in real-time, 7x24. New Web standards for data and document sharing, such as the eXtensible Markup Language (XML) will ease the interoperation challenges and bring the benefits of traditional EDI systems to all businesses, big or small. 

In addition to the internal business processes that are the object of traditional business engineering of a company, inter-enterprise processes add new dimensions of functionality and new players that must be addressed. Some of the key new processes that come into play beyond the boundary of a given company are shown in Figure 8.4. One of the challenges of inter-enterprise process engineering is the mapping of the processes to trading partners whose processes are integrated at various levels, from data handoffs to fully integrated processes. Inter-enterprise process engineering adds new dimensions to traditional business engineering because we are modeling business ecosystems, not just a single company. 

Figure 8.4. Key Inter-Enterprise Processes 

3. Engineer Internal Business Processes. Internal business processes must be adapted in order to participate in e-Commerce. With a component-based development approach "wrappers" are developed for legacy information systems that implement internal business processes. In addition, new e-Commerce processes for which there are no legacy implementations will require data to be integrated from legacy systems directly into the e-Commerce applications. 

4. Pilot, Deploy and Iterate. Building ultimate, all encompassing e-Commerce systems does not happen in one big step or one big project. These systems are too large and complex and, when doing business at Internet-time, time is short. The goal is to deliver fast and often. Using a minimalist approach, incremental delivery is the key to sustainable development. The minimal functional business requirements should be developed, piloted to manage risk, and deployed as "Release 1." Business requirements determine the functionality to be delivered in Releases 2 to ...n. Release 1 embodies the key business process innovation, Releases 2 to ... n represent continuous process improvement. In the battle for competitive advantage in the digital economy, e-Commerce development never ends. Each iteration of development must raise the bar for competitors. 

Technology Issues and Strategies

Issue 1: E-Commerce Integration and Program Management

Leading companies recognize e-Commerce as a complete business platform than can span business-to-consumer activities all the way back through business-to-business collaboration: product conceptualization, engineering manufacturing and distribution across an inter-enterprise value chain. They likely have multiple e-Commerce initiatives underway on both the buy and sell-sides of the business. These companies now have their eye on a prize much larger than the sum of all the individual initiatives: customer self-selling and self-service. Putting the customer in complete control of the value-chain, is the ultimate outcome of the customer-driven business. 

Companies that are taking the path toward becoming a fully digital, customer-driven business realize that no e-Commerce application is an island. Rather than creating islands of e-Commerce, they design enterprise and inter-enterprise architectures whose centerpiece is e-Commerce integration. The process of integration begins with identifying the patterns of business logic and data common to e-Commerce applications. Those patterns are translated into specifications for core e-Commerce application components and often include user access and role-based profiles, event management and notification, data and business object integration, trading services, business policies and rules, process management and workflow. Establishing and managing these "e-Commerce engines " as a shared business asset is the singular defining step toward e-Commerce integration and the brave new world of e-Services. These assets may be jointly designed, managed and shared across the enterprise and across trading partners, suppliers and customers. 

Having an infrastructure in place that fosters e-Commerce integration does not guarantee success. Those assets must be well managed through a program management organization that is empowered to coordinate people, projects and business resources. While governance of each e-Commerce initiative remains with business units, the shared commerce infrastructure should grow in synchronization with the evolution of the overall business architecture. Successful program and project management are the keys to an orderly transition to becoming a digital business. Well managed corporations are experienced with program management and will extend their management processes to the needs of inter-enterprise program management, coordinating multiple projects in multiple organizations. The program management organization should be chartered as a business unit to ensure that e-Commerce is totally business-driven, now and throughout the greater transition to becoming a virtual corporation. 

Issue 2: Security is Prerequisite

The Internet allows a company to open its business to the world. The potential benefits of giving customers, suppliers and trading partners direct access to the business are compelling - increased revenues and decreased costs. The Internet proposition has, however, one very serious implication - security concerns are often cited as the greatest barrier to electronic commerce. A business does not want the outside world to have unrestricted or unauthorized access to company information and business processes. Likewise for customers.

Security is concerned primarily with managing risk. The degree of security needed will depend on the importance of what is being secured, how much money is available to implement and maintain the system and the number of weaker links. It is more expensive to add security after the fact than to design security into the system from the beginning. 

Security must be built-in at both the technical and business process levels. At the technical level, data vulnerabilities while in transit are usually dealt with though a combination of encryption schema and transmission protocols such as Secure Sockets Layer (SSL). The Secure Sockets Layer security approach adds a layer (that negotiates a secure transmission connection) on top of the existing network transport protocol and beneath the application layer. Secure Hypertext Transfer Protocol (HTTP-S) adds a set of security headers used to negotiate what type of scheme (such as bulk encryption) and which specific algorithm (such as RSA public key encryption) to apply to information transfers. In addition, corporate firewalls, consisting of hardware and software combinations, control and limit access to a private e-Commerce network from the public Internet. Firewalls function as Internet Protocol (IP) packet filters, application relays, monitors and logging devices. They provide proxy masquerading of information and concentration of security administration. IP packet filters enforce rule sets as to what types of packets can enter or leave through the gateway.

At the business process level, what is needed is authentication so that no one else can pretend that he or she is an authorized user, and access control so that a particular user can gain access to only those portions of the business for which he or she is authorized. On the stateless and session-less World Wide Web, the user needs to know he is communicating with the right server, called server authentication, and the server needs to know it is communicating with the right user, client authentication. Prior to the advent of e-Commerce, methods of identifying an individual's position, role or authority were accomplished via phone calls, meetings, correspondence and contracts. In retail industries, driver's licenses, photo IDs, Pin numbers, passports and birth certificates are used to vouch for identity. These means of identification now have their counterparts in the digital world. 

Authentication procedures must provide convenience as well as security. For example, in a business-to-business context, authentication should provide a single, universal user logon to multiple applications running on multiple servers while controlling access to resources on the system: files, directories and server universal resource locators (URLs). In fact, a single sign-on is a requirement in many business-to-business e-Commerce environments. Authentication procedures typically involve something known, something possessed or something a user is. High-level security applications often demand a combination of factors such as something possessed, like a smart card with a private key, in conjunction with something known, such as a PIN number. Parties to an e-Commerce transaction must feel comfortable in their belief that they are in fact doing business with who they believe they are. Doubt as to the identity of other parties must be done away with by a security system that authenticates by verifying information that the user provides against what the system already knows about the user.

E-Commerce access management requires an authentication and profiling capability that enables the access control processes to be managed electronically, and extended globally to suppliers, trading partners and customers. Authorization involves the control of access to a particular information space once the user has been authenticated and, accordingly, identified to the server's satisfaction. Authorization is intended to limit the actions or operations based on their security clearances that various authenticated users are able to perform in an internetworked space. Corporations already have internal business and technical controls over the use of information systems by their employees, but business-to-business e-Commerce requires extending this controlled access to outside companies, outside employees, and outside computer systems. Information boundaries must be designed to control access and manage sessions as well as assign rights and privileges to trusted partners and new customers or suppliers. Information boundary management (e.g., who is allowed to view what and when) addresses the security, directory services, and access control aspects of content and application functionality necessary to support inter-enterprise business processes, collaboration and application-to-application integration.

Access control mechanisms are based on access rights, or permissions, that define the conditions under which the user can access network resources. Access controls delineate the user's privileges or permissions such as 1) creating and destroying information, 2) reading, writing and executing files and programs, 3) adding, deleting and modifying content, and 4) exporting and importing abilities. The site administrator controls the permissions using an access control list that itemizes the privileges of authenticated users on a resource-by-resource basis. Integrity is concerned with protecting data from unauthorized modification both while in transit over the network and while stored on the system servers or in accessible databases. Changes that the integrity services component of access management must protect against include data additions, deletions and reordering as well as modifications. Security management services support the integrity of e-Commerce

Secure it, or forget it! Security is a non-functional and absolute requirement of all e-Commerce applications. As with all business controls, the cost of the controls must be in line with the assets they protect. The security, control and auditability of e-Commerce applications require the same first principles that are needed in the physical world of management control. The first principles of business controls cover the nine major risk exposures of any corporation whether it is using pencil-and-paper or digital media in its operations. A corporation's auditing team, therefore, is a vital part of the e-Commerce team.

Issue 3: Nonrepudiation: Signing the Contract

In the physical world, business contracts are not legally executed and binding until they are signed. The same must hold true for e-Commerce if nonrepudiation is to be achieved in cyberspace - the document must be signed. What is needed is a digital infrastructure for handling signatures.

The public key infrastructure (PKI) is a comprehensive set of functionalities for encryption and digital services that consists of several components, including a directory, certification authority (CA) and certification revocation lists. PKI's most popular feature is its two sets of keys - a public key and a private key. PKI simultaneously addresses the four issues of authentication (a user is who he says he is), authorization (the user is authorized to be where he is on the network), nonrepudiation (the user is the one who really sent the message) and privacy (no one has read or tampered with a user's message).

Secure Sockets Layer (SSL) protocols, now supported by all popular browsers, are capable of presenting client public key certificates to any Web server configured to require client authentication. To create a client certificate, the user goes to the Web site of a certificate authority and fills-out a form with personal identification information needed to create a public key pair. The public half of the key pair is then submitted along with the personal identification data to the certificate-issuing Web server which then uses its certificate authority root key to digitally sign the user's public key. The signed certificate is then returned to the browser for storage together with the corresponding private key. 

A certification authority is the trusted third-party who issues certificates for public keys. Individuals can also generate their own private and public keys and send the latter to the CA for validation. Public keys may be kept in white pages-like directories. Typically, two key-pairs are generated - one pair for encryption and one for digitally signing documents. The term "asymmetric keys" means the use of separate public and private keys. Suppose "Alice" wants to send "Bob" a digitally signed and encrypted document. "Alice" will sign it using her private key and use "Bob's" encryption key to encrypt the message. "Alice" will go to the directory to obtain "Bob's" public key. When "Bob" receives the message, he will use "Alice's" public signing key to see if "Alice" is indeed the originator of the document and that the content has not been tampered with in transit. "Bob" will use his own private key to decrypt the message.

In addition, certificate revocation lists are repositories of invalid certificates and key histories that are for decrypting old information. Cross certification means two separate certificate authorities recognize each others certificates. Nonrepudiation involves digital signatures and time stamping, so senders cannot deny they sent a message in question. Client software is used for certificate validation, storage of the private key and applications that use secure PKI. Directories are essential to implementing PKI and function as a repository for cryptographic information. Support for the Lightweight Directory Access Protocol (LDAP) is important. E-Commerce applications must reside on a solid PKI infrastructure. Nonrepudiation is as essential in cyberspace as it is in the traditional world of commerce. 

Issue 4: Trust and Privacy in Cyberspace

In both business-to-consumer and business-to-business e-Commerce, trust and privacy are critical issues that must be dealt with electronically. Trust is a measure of confidence, and TRUSTe, an independent, non-profit privacy organization has taken the initiative. TRUSTe focuses on a company's unaudited, voluntary commitment to meeting certain standards for electronic commerce related to privacy. TRUSTe has developed a third-party oversight "seal" program that alleviates users' concerns about online privacy, while meeting the specific business needs of each of their licensed Web sites. A TRUSTe trustmark is awarded to sites that adhere to established privacy principles and agree to comply with ongoing TRUSTe oversight and resolution procedures, including audits by CPA firms. All Web sites that display the trustmark must disclose their personal information collection and privacy practices - what personal information is being gathered, how the information will be used, who the information will be shared with, choices available to the browser regarding how collected information is used, safeguards in place to protect information from loss, misuse, or alteration, and how a user can update or correct inaccuracies in information.

"Privacy principles embody fair information practices approved by the U.S. Department of Commerce, Federal Trade Commission, and prominent industry-represented organizations and associations. The principles include 1) adoption and implementation of a privacy policy that takes into account consumer anxiety over sharing personal information online, 2) notice and disclosure of information collection and use practices, 3) choice and consent giving users the opportunity to exercise control over their information, and 4) data security, quality and access measures to help protect the security and accuracy of personally identifiable information. To become a TRUSTe licensee, a candidate creates a privacy statement with the help of a TRUSTe online wizard, reads and signs a TRUSTe license agreement, and pays annual fees."

Privacy is a major concern of Internet users and can be divided into concerns about what personal information can be shared with whom, and whether messages can be exchanged without anyone else seeing them. The World Wide Web Consortium's Platform for Personal Privacy Project (P3P) is developing specific recommendations for practices that will let users define, control and share personal information with Web sites. The P3P incorporates a number of industry proposals, including the Open Profiling Standard (OPS). Using software that adheres to the P3P recommendations, users will be able to create a personal profile, all or parts of which can be made accessible to a Web site as the user directs. 

In an open network such as the Internet, message privacy usually requires encryption and decryption. The most common approach is through a public key infrastructure (PKI). Providing a trusted and private presence on the Web is essential to any e-Commerce initiative.
 
 

Issue 5: Agility and Software Components

Because they span multiple unique enterprises and disparate hardware platforms, e-Commerce applications require the services of a robust distributed object computing infrastructure - they require a Web object model. The key requirement of the underlying object platform is that it separates technology and business concerns and that it be service-based. The components of the architecture supply high level business and technology services that can be used without having to know how those complex services are implemented or delivered. This layered architecture is essential to the separation of concerns needed for agile software development. 

Software components throughout the architecture may be changed without affecting the others, and e-Commerce applications can be assembled, disassembled, and reassembled without leaving the semantics of the business to dip into the technology plumbing. It is critical that abstractions used to model e-Commerce application components stay above the distributed object computing infrastructure (DCOM or CORBA). These logical models should be platform independent and conform to Meta Object Facilities such as the XML Metadata Interchange (XMI) format specification so that they may be incorporated into disparate modeling methods and tools. Although UML is the standard for component modeling, differing analysis and design methods and tools are used by corporations. XMI makes it possible for separate enterprises to share UML models and is essential to inter-enterprise development of e-Commerce applications. The whole idea of component-based development is that an application solution to a business problem is an assembly and configuration of defined services. By staying above the technology platform, component models can be distributed and incorporated to gain maximum benefit from technology now and in the future, both at the business modeling and systems deployment phases. 

In A Framework for Business-IT Alignment Using Components, Paul Allen describes the range of activities involved in component-based development. "Traditional software engineering techniques are geared to individual applications. CBD goes far beyond traditional software development in its range of activities:

Architect: Achieve an overall software structure for components adaptable to business needs.

Extend: Specialize component interfaces; a form of black-box reuse.

Assemble/Develop: Plug together components, with the minimum of newly developed code, to produce a business solution as rapidly as possible.

Wrap: Build component interfaces based on legacy systems; a form of black-box reuse.

Acquire: Purchase application components.

Upgrade: Replace or evolve existing software to component status.

Subscribe: Use published services from an external component provider.

Engineer: Build new components.

Modify: Specialize component models; a form of white-box reuse used with frameworks.

Integrate: Ensure the various types of components work consistently and coherently together."
 
 

Component-based development strategies are the key not only to software agility, they also help eliminate the disconnect between business engineering and software engineering. Traditionally, models of innovative business processes are developed by business people and thrown "over the wall" to software developers to transform them into software. One group thinks with business mental models, the other with computer mental models - disconnects are sure to arise. But what if there were another way? What if the business engineering process was carried out with business components as the modeling medium? After all, business application components are the implementation of the business processes and entities being modeled. Assuming that existing sets of business processes have been implemented as business components and registered in a repository, the existing component model represents the "as is" analysis model of business engineering. The "should be" model results from customizing and reconfiguring the components, and conducting gap analysis to discover requirements for additional components. This compositional approach to business engineering can unlock

When the business world operates in Internet-time, the ability to sense and respond to new threats and opportunities is paramount. Rapid business engineering and rapid application development must be fused into a single activity in order to meet the new competitive realities. In short, the Business Object Model and the System Object Model can and must be aligned, integrated and synchronized. 

The notion of aligning business and technology is not new, but tangible progress toward this noble goal has been slow in coming. Object-oriented technologies and methods have made significant contributions to business modeling and business engineering. Methods such as Enterprise Engineering's Object-Oriented Business Engineering (OOBE™) and Jim Odell's Object-Oriented Information Engineering (OOIE) are powerful approaches to alignment. Object-oriented technologies and development methods, however, are new and sometimes complex. As we explored in the chapter 2, O-O technologies and methods require new ways of thinking and present steep learning curves - on to components. Component frameworks are the next step in the progression of object-oriented theory and practice and can overcome the drawbacks and obstacles of O-O to deliver on the promise of O-O. Component frameworks can make the business and technology alignment notion real. An agile business powered by agile software can be built with component frameworks - this is the component breakthrough for competitive advantage. 

The methods and tools of compositional business and software engineering are just emerging. The move beyond the object to the component paradigm has been underway for only a few years. Most methods associated with software engineering are top-down and decompositional, and they are still fully viable approaches. This long entrenched way of thinking will take time to be extended by mature compositional methods and tools. Fortunately, the key players in the software development industry are committed to the component model and early methods and tools have already appeared (CSC's Lynx method, Riverton Software's HOW, ICON Computing's Catalysis, Sterling Software's COOL). An essential corporate software strategy for e-Commerce is to adopt component-based architectures, development methods and tools, and evolve with them - today's methods and tools are quite powerful and will only get better.

Software architectures are generally tiered and divided into two broad categories: information architectures that deal with the business domain and technical architectures that deal with the computing infrastructure services needed by the application domain. While information architecture partitions the business logic across components and arranges the collaborations needed to meet functional requirements, technical architecture includes domain-independent design decisions such as middleware, database management, fail over, event management and persistence. Technical architecture should be developed early as it provides the technical services upon which applications will be built and reinforces the separation of concerns so critical to rapid component-based development. 

Issue 6: Server-side Component Models, Platforms and Frameworks

Software component architectures are service-based: end-user services, business process services and data services. Application components rely on distributed computing infra-structure services, freeing solution developers from the complexity and intricacies of the underlying technologies. Component builders are technologists who use component-based software engineering disciplines to produce components of extreme quality. Solution developers consume these prefabricated components during business process modeling and rapid application assembly.

Component architectures divide software into construction and consumption: once built in compliance with standards, newly constructed software components can register the services they provide, while other components can subscribe to and consume these services. Components do not act alone, they plug into component frameworks that connect participating components and enforce rules of component interaction. Component frameworks mediate and regulate component interaction. Component frameworks are arranged in a tiered architecture. Figure 4 illustrates components and how they plug into an interoperability framework that in turn calls on the services and facilities of a distributed computing platform. 

Two leading component models are Microsoft's' COM+ and Sun Microsystems' Enterprise JavaBeans (EJB). Both are server component models, as opposed to client-side components such as JavaBeans or ActiveX. The chief difference between the two is that the Microsoft model is restricted to Microsoft runtime systems and communication protocols. For example, although COM and DCOM have been ported to Solaris and other Unix platforms, COM containers are not available on these platforms. EJB, on the other hand, adheres to the write once, run anywhere (WORA) philosophy that made Java the overnight success for programming the Internet. 

EJB and the CORBA middleware standard go hand-in-hand. EJB provides software portability (allowing EJB components to run on any operating system) and CORBA provides software interoperability with platform services written in languages other than Java, such as C++ and Smalltalk. Rather than reinvent the wheel, EJB's application programming interfaces (APIs) provides access to underlying enterprise-class, standards-based infrastructure services. For example, the Java Transaction API defines a distributed transaction management service based on CORBA's Object Transaction Service (OTS) standard. In turn, the Java IDL creates a remote interface to CORBA communication and includes a lightweight object request broker (ORB) that supports CORBA's Internet Inter-ORB Protocol (IIOP). 

Business and e-Commerce application components will not be delivered to corporations as a big pile of parts and pieces. Instead the components will be preassembled into industry specific application frameworks as illustrated by the Financial, Manufacturing, and e-Commerce components shown in Figure 8.5. 

Figure 8.5. A Business Component Software Architecture

The e-Commerce components provide essential inter-enterprise functionality for e-Commerce (e.g. negotiation, mediation, inter-enterprise user access management, inter-enterprise workflow management and event notification). These frameworks represent applications that are almost, say 60% - 80%, complete. The task of solutions developers is to customize and extend the frameworks to incorporate the unique business rules and processes of a company. Thus, solution developers concentrate on the unique character and knowledge of the company that provides its competitive advantage. They are insulated from the technology plumbing.

IBM's SanFrancisco(tm) is a leading example of a component-based application framework that includes most of the code needed for developing server-side, mission-critical business applications. SanFrancisco's component architecture is layered and services-based, using an architecture similar to that portrayed in Figure 8.4. It includes four layers. The Foundation layer utilizes the distributed object services of the EJB component platform that, in turn, are based on definitions of the Object Management Group (OMG) (i.e. object transaction services, collections, object communication and persistence). The Foundation layer provides the base classes and utilities needed to support the distributed, mission-critical applications for which SanFrancisco was designed. Built on the Foundation layer is the Common Business Object layer that provides cross-application business objects common to most commercial domains (e.g. Company, Address, Business Partner, Bank Accounts, Unit of Measure and Credit Check). The Core Business Process frameworks layer provides the prefabricated components for applications in a specific business domain (e.g. General Ledger, Accounts Receivable, Accounts Payable, Warehouse Management and Order Management). The final Application layer is built by solution developers who map business requirements to the core business processes, configure their properties to reflect unique business needs, and extend the prebuilt functionality to add specific requirements, the user interface, business rules, competitive differentiators and complimentary application functionality. 

SanFrancisco makes extensive use of design patterns derived from classical architecture. Design patterns are techniques used to solve recurring design problems. As we mentioned, Christopher Alexander defined the concept of patterns in architecture, "Each design pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." In the worlds of objects and software components, design pattern form the cornerstone of software reuse and provide consistency throughout the SanFrancisco frameworks.

The breakthrough of server-side component architecture is the clear separation of business and technology concerns that simplifies the process of building enterprise-class e-Commerce applications. Solution developers can concentrate on business models and logic while the component framework manages the complex middleware services for the applications. For an architectural approach to software development to be practical, enterprise-class e-Commerce systems and their component frameworks must have certain characteristics. These non-functional characteristics include the requirements and constraints shown in Table 8.1 

loosely coupled

self-organizing

self-describing

event-driven

asynchronous

reliable

secure

survivable

intuitive

collaborative

embody business controls

auditable

Table 8.1 Requirements and Constraints

In a DARPA research report by Thompson, Linden and Filman list the architectural properties required of the non-functional, technology-level environment. As shown in Table 8.2, their list is dominated by property names suffixed with "ility," and thus the list is referred to as the ilities of architecture. "Software is designed primarily to meet functional specifications - that is, to achieve particular input and output behavior. However, a well-designed system achieves an appropriate balance of other [non-functional] properties: those that encompass its ability to exist in its environment and evolve as that environment changes. Following evolving practice, we call these ilities. Ilities are architectural properties that often can cut across different levels or components of a system's architecture to be properties of the whole. Unlike simple functionality, ilities can include tradeoffs - for example, enhanced interoperability may have been produced at the cost of lesser security. Although ilities are sometimes invisible properties of the system as a whole, they represent real (though perhaps unspoken or even unrealized) customer requirements. The enterprise architect or system architect is responsible for ensuring such ilities, and a most appropriate task for an architectural framework is to support them." In total, these ilities create the ability to evolve and meet new demands of the business. 

interoperability composability

scalability evolvability

extensibility tailorability

security reliability

adaptability survivability

affordability maintainability

understandability performance

quality of service nomadicity

Table 8.2. Some "Ilities"

Third wave companies embrace component-based architecture and their ultimate strategy is to implement an architected approach to rapid application development. Components accelerate the entire application development life cycle and, when used directly in business process modeling, they eliminate the disconnect between business and technology. This approach is the essence of business and software agility. Although component-based development is an emerging approach, sufficient methods and tools are available to begin using the approach now, and gain even greater benefits as the approach grows to full maturity. 

Issue 7: The XML Factor: Industry Vocabularies

Open markets require the interoperation of e-Commerce applications and consistent protocols and formats for information interchange. The complexity of building such virtual commerce places mandates a common vocabulary based on standards if there is to be any hope of interoperability at the commerce level. The ultimate purpose of e-Commerce interoperability standards is to develop consistent business semantics that can be used by all participants - a common language of digital commerce. These semantics provide commonality to the names of and relationships between processes, workflows, and data across value and supply chains. 

The World Wide Web Consortium (W3C) adopted a new standard for defining and naming data on a Web page in 1998. It is likely that the eXtensible Markup Language (XML) will revolutionize the Web because it allows structured data - with standard names and consistent semantics - to be moved around the Web in a simple, straightforward way, as easily as HTML does today. XML is a native Web approach that enables extensible data-exchange formats, and gives industries the flexibility to create their own data tags to develop a shared Internet file system.

XML is being touted as the next big thing on the Internet since the introduction of Java. XML, however, is not a replacement for Java. In fact, Sun engineer, Jon Bosak chaired the W3C XML Coordination Group and is generally regarded as the father of XML. XML and Java go hand-in-hand. In Bosak's words, "XML and Java technologies are the yin and yang of vendor-neutral programming. Put them together and you have a complete, platform-independent, Web-based computing environment." Java provides a way for software programs to be shuttled around the Internet, XML does the same thing for data, offering a universal data interchange format. With Java and XML working together (XMLbeans), the result is much like the science fiction films where all the information (data, process and control) needed to perform an activity moves seamlessly from computer to computer throughout cyberspace. Java turns the Internet into a single, ubiquitous computer, XML turns the Internet into a single, ubiquitous filing cabinet for data. 

The contents of an XML document, however, need not be only data. In fact the term "smart data" may be more appropriate. Anne Thomas of the Patricia Seybold Group explains, "Combining Java and XML technologies produces portable 'smart' data. XML supplies a universally portable structured data format, and Java technology supplies universally portable code. Since code written in the Java programming language can be embedded into a document written in the XML language, we can create a data structure that includes its own data manipulation applications. It's a great combination." Thus XML can play a role at all three levels of process integration as illustrated in Figure 3: simple data hand-offs, process hand-offs and real-time interoperation. 

XML is a document-centered technology ideally suited for message passing between trading partners in an e-Commerce ecosystem. Document messaging is a way for e-Commerce applications to interoperate in a loosely-coupled, request-for-service, communication process. The document type definition (DTD) alone can identify a given document type in a business-to-business transaction. This is similar to the various document types defined for the EDI community. For example, an ANSI X12 EDI 850 is a Purchase Order transaction set. By sending such a document to an EDI enabled system, the receiving organization knows what processing services to perform on the data. Such data hand-offs trigger business processes in the receiving organization based simply on knowing the document type contained in the message sent to it. 

On the other hand, process tags (<Process) tags can be included in an XML document to indicate the business process or system process to be launched or invoked by the receiving organization as a result of the process hand-off. The Document Object Model (DOM) is a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. DOM allows XML content (including all markup and any Document Type Definitions) to be accessed and manipulated as a collection of objects. The document can be further processed and the results of that processing can be incorporated back into the presented page. Java code thus embedded in an XML document enables real-time process integration. Regardless of the techniques used to add "behavior" to XML documents, the result is a document services architecture that allows trading partners to combine and request services needed to process business documents marked up in XML. 

XML also is being embraced by the Enterprise Application Integration (EAI) community whose central goal is to achieve interoperability between legacy and Enterprise Resource Planning (ERP) systems. ERP integration has been a long-standing problem that has become a burning issue with the advent of e-Commerce. Using the same principles described above, ERP vendors (SAP, Baan, Peoplesoft and Oracle) and the non-profit Open Applications Group (OAG) are turning to XML to solve some of the chronic interoperability problems between and among ERP systems. Today companies have a choice of digging in and dealing with the proprietary application program interfaces (APIs) such as SAP's BAPI, or they can turn to third party companies like Crossworlds, Active Software or Visual Edge to provide adapters for higher-level interfaces to the leading ERP systems. The ERP vendors are developing means to take lower-level function calls to their systems and translate them into standardized XML documents. Thus, XML can be used to greatly simplify and lower the costs of legacy and ERP interoperation just as it can simplify and lower the cost of EDI. 

XML is, however, not a silver bullet, and in some ways it is little more than the reintroduction of the "unit record concept" that was introduced with the punched card in the 1950s, where chunks of data (fields) were tagged with names that gave us attribute/value pairs bound together as a standalone document (a record). After all, XML is simply text (ASCII) data, and it must have links to a powerful, underlying object infrastructure (based on a Web Object Model) to handle the adaptive business processes and workflows that e-Commerce requires. The truly difficult part of this process is gaining global agreement on the semantics - an effort that has eluded information systems designers since the introduction of centralized corporate databases in the 1960s. Ask any experienced data administrator and they will tell you that they cannot even get departments within the same company to agree on data names, much less their meaning. 

Rik Drummond, CommerceNet's XML/EDI project leader, put it this way in his research note, Is XML Dead in the Water?, "Just like the Clinton 1992 presidential race 'It's the economy dummy! - In XML, 'It's the semantics dummy!' Since XML is a Meta language [a language used to define other languages], it is easy to define the structure of the document to describe how things relate to each other. It also allows one to establish data element names, that is, names such as <price, <DiscountPrice or <size. The syntax is not the problem, because the XML parsers can read the syntax. The semantics are the issue. This is especially true with semantic interoperability. For example, how do we agree with what <size means? Is it length, width, depth, or some combination of all three? Is it in feet, yards or meters? These are semantic issues." 

Thus, XML is simply an enabler, not a guarantor, of the consistent business semantics required for e-Commerce. XML can be used within a single company with little debate over vocabulary and semantics. Two trading partners could do the same, although this process could require mapping the DTDs of each company if each had its own definitions. Add more trading partners and the mapping problem grows exponentially. What is really needed for open e-Commerce are standard XML industry vocabularies for DTDs and schema. Then companies that adhere to the standards can all talk to each other digitally in the same tongue, no mapping required. 

Some industries will do better than others at establishing semantic consensus. For example, groups such as the XML/EDI Group and Data Interchange Standards Association (DISA) may have early success because they are dealing with an established body of inter-enterprise business semantics. The task is one of mapping EDI document definitions to XML, and, DISA, which maintains the ANSI ASC X.12 EDI standards, has already undertaken a XML initiatives. 

A number of XML industry vocabularies are being developed by individual companies, vertical industry consortia and software industry groups. Some of these are listed here and a brief description of each appears in Appendix A:

The list of standards and industry vocabulary initiatives will surely grow, probably until it comes close to the number of global standards related to commerce in the physical world. The sheer number of new and evolving industry vocabularies causes obvious problems. What happens when connections are needed between them in a given e-Commerce ecosystem? What is needed is a common repository of XML schema that can be shared by participants globally over the Net. The ideal goal would be to establish a XML portal for industry vocabularies. The portal should serve as a repository and a registry of vocabularies. Within the registries, XML tags must be managed using the Namespaces standard for XML so that names do not overlap and collide in documents containing multiple vocabularies. 

While registries must be organized into a meaningful taxonomy, such taxonomies must be more than a way to classify information. They must encode and represent knowledge to get at the meaning of the information. While XML data and Java processing bring the information needed for e-Commerce, ontologies bring knowledge to the e-Commerce table. Open markets require smart software acting on behalf of all participants.

Knowledge representation is a discipline within the artificial intelligence community and is captured in the form of ontologies. What is an ontology? In its general meaning, ontology is the branch of metaphysics that deals with what kinds of things exist in the universe - the classification and essence of things. Tom Gruber of Stanford University provides the short answer in context of artificial intelligence, "An ontology is an explicit specification of a conceptualization." He explains, "A body of formally represented knowledge is based on conceptualization: the objects, concepts, and other entities that are assumed to exist in some area of interest and the relationships that hold among them." An ontology defines the basic terms and relations comprising the vocabulary of a topic area, as well as the rules for combining terms and relations to define extensions to the vocabulary. All domain models embody an ontology - albeit mostly implicitly. An artificial intelligence approach to defining business objects emphasizes the use of explicit ontologies as implementation-neutral representations of knowledge that can then be mechanically translated into different target modeling tools. 

Ontology.org, sponsored by Computer Science Corporation (CSC), was founded by Howard Smith and Kevin Poulter in 1998. Ontology.org is working with CommerceNet to develop ontologies for e-Commerce and XML vocabularies. Smith and Poulter elaborate on the goals of Ontology.org, "Although taxonomy contributes to the semantics of a term in a vocabulary, ontologies include richer relationships between terms. It is these rich relationships that enable the expression of domain-specific knowledge, without the need to include domain-specific terms." The adoption of a shared ontology allows e-Commerce software (especially software agents) to simultaneously "interoperate without misunderstanding, and retain a high degree of autonomy, flexibility and agility." Without ontologies, the tasks of integrating, or in any way unifying the rapidly growing list of XML vocabularies will be as monumental as building the Tower of Babel.

A neutral, non-profit organization makes the most sense for governance of XML repositories and registries. CommerceNet, the non-profit electronic commerce consortium, has announced that it is developing an e-Commerce Registry service. Another organization, OASIS, the Organization for the Advancement of Structured Information Standards, is a non-profit, international consortium dedicated to accelerating the adoption of product-independent formats based on public standards, including SGML, XML and HTML. XML.ORG is an industry Web portal operated by OASIS. The most important function of XML.ORG is to serve as a trusted, secure, persistent repository and registry for DTDs, namespaces, schemas, and other specifications that must be globally accessible in order to make possible the use of XML for data exchange within particular industries.

Owning and governing XML repository portals means power and influence with software developers, so commercial companies including Microsoft have made moves into this space. Using the ".org" top-level domain name, Microsoft rushed in to fill the registry gap by establishing BizTalk.org. The web site is "free," and Microsoft will be happy to store companies' private XML schema in secure areas on the site as well as public vocabularies. 

In summary, XML by itself is little more than a markup language. When XML is used as a meta language to define industry vocabularies so that trading partners can interoperate, then it will be those very vocabularies that thrust XML center stage as the language of e-Commerce. Reaching this goal will not be as easy as it may sound and many requirements must be met. The XML/EDI Group amply describes these requirements. "What does it take for a document/format to meet the challenges of delivering on the concept of enabling the "Electronic Enterprise" of the future? One can foresee that the requirements would include:

1. Message objects containing all the information (rules and data) necessary to process them without reference to the originator for clarification. [self-describing and introspective business objects]

2. A self-validating and authenticating message. 

3. Displayed as requested by the author or reader, including local styles, and also tailoring itself automatically to the particular device or media available. 

4. Dynamic links from various sources/servers and object components from around the world. 

5. A web presence with common tagged elements. 

6. A legacy interface with the new system without having to redesign expensive business processes. 

7. Extended EDI messages with multimedia-based objects and content. 

8. Searchable via today's and enhanced object-based engines of the future. 

9. Encapsulated internal routing and security elements. 

10. An easily assimilated protocol via today's software. 

11. Manipulated and viewed with your Web browser, word processor or spreadsheet program. 

12. Dynamically updateable industry codes cross-linked to reflect the local language. 

13. Compatible with internal workflow subsystems and external business-to-business pipelines. 

14. Automated on-line E-business. 

15. Intranet access to local databases without the use of complex middleware."

As industry vocabularies mature, XML will bring the benefits of traditional EDI to the masses, ease the legacy and ERP interoperability problems, and level the playing field for small and medium-sized enterprises (SMEs). Although adapting to the new XML-enabled world of e-Commerce will require a lot of transition planning and work (no technology introduction is trivial), XML is in every company's e-Commerce future. 

Issue 8: Open Markets: Standards-based Rules of Engagement

The telephone was the first universal, fully interactive information highway. Standards made it possible for any phone company's proprietary system to interoperate with any other phone company's proprietary systems. As a result, today anyone can phone anyone anywhere at anytime. Without global standards, however, the telephone would not be universal and would not have its impact on society and the economy. 

In the third wave, e-Commerce transforms closed, isolated markets to dynamic open markets. Standards are prerequisite to such dynamic markets and market interoperation. We have discussed the Tower of Babel problem of the growing XML industry vocabularies. Creating standards, open standards, between and among these semantic towers of e-Commerce Babels is essential to digital commerce. Open e-Commerce standards (tying together the XML Towers of Babel) to watch for in include CommerceNet's eCo system architecture and the Object Management Group's Electronic Commerce Reference Architecture Model.

A January 1999 report from CommerceNet documents the status of the eCo system framework and the problem it aims to solve. "Using XML and Objects to construct an Electronic Commerce Framework - CommerceNet announced its eCo Framework workgroup in August 1998. Its purpose is to select and integrate various existing technologies into a framework for all commerce. Many efforts, proprietary, industrial and international in nature, are working to establish electronic commerce standards. Efforts such as OFX (Open Financial Exchange), ICE (Information Content Exchange), or OTP (Open Trading Protocol), while well done, focus on only part of the whole Electronic Commerce process and do not offer a total solution. The eCo Framework Workgroup hopes to solve this problem through the use of new and existing object-oriented technologies, XML, Object-Oriented XML, Agents, EDI and other existing semantic and syntactical technologies. This is a formable undertaking - to accomplish this goal, expertise from many related standards groups is required for constructing the final framework. The work group has two efforts underway. One effort is to establish the architecture of services and how they interact and fit together. The other effort is to research existing technologies and recommend those that should be used to construct the framework."

"Marketware" is the generic name for a class of eCo applications and services that would bring together buyers and sellers. The services are based on a common platform that would be customized by plugging in different application modules. Depending on the modules used, a variety of value-added market services could be implemented CommerceNet's eCo framework is centered on advanced semantic models and technique derived from the world of artificial intelligence such as ontologies developed by the European Enterprise Project." 

"The primary focus of CommerceNet's eCo framework project is to demonstrate the value of the integration of three common component-based electronic commerce services. These services are semantic integration of multiple database types with multiple data constructs and data libraries; trusted open registries; and agent-mediated buying. It is our belief that these three core services will serve as the foundation for next generation, component-based commerce applications and services. These core services will provide interoperability between many commerce services and serve as a foundation to operate Web-based trading communities." The eCo Architecture is presented in Figure 8.6.
 
 

Figure 8.6 CommerceNet's eCo Architecture for Open e-Commerce

To help put the eCo Framework in perspective, Figure 8.7 shows an instance of the eCo framework at work. Using the eCo Architecture specification, the figure illustrates the following e-Commerce scenario, "two companies are represented as eCo Businesses (implementations of the eCo Business Layer.) These Businesses exist together in an eCo Market that provides a venue for the type of e-Commerce that they are conducting. The eCo Market is indexed within a Network of Markets so that it can be located on the Internet. Each of these Businesses offers a set of e-commerce "Services" to each other. Each Service represents an interface to a business process. Example Services might be "Become a VAR", "Order some product", or "Review a catalogue of products." At the highest level, Businesses interact by using the Services of each other." 

"A Service is composed of a set of document exchanges. We call these exchanges 'Interactions'. An Interaction occurs when a request (consisting of one or more Documents) is sent from one Business to another and a response (again consisting of one or more documents) is received."

Figure 8.7. CommerceNet's eCo Framework at Work

Distributed object computing sets the foundation for both enterprise computing and the inter-enterprise computing that is essential to open e-Commerce. In fact, it is the distributed component paradigm that has made it possible for e-Commerce to aspire to open digital markets. 

Like business objects in general, the interoperation of open market processes must rise above technology interoperation ("above the ORB") to a level of abstraction where business information models can interoperate using the vocabulary of e-Commerce. In other words, common business semantics must be available to all participants in an open digital market. 

Yet common business semantics are not enough. Interoperation at the e-Commerce semantic level is the focus of CommerceNet. Interoperation at the information systems level is the focus of the Object Management Group's (Common Object Request Broker Architecture) CORBA specification. In addition to CORBA middleware, and rising above the "orb," the OMG's Electronic Commerce Domain Taskforce (ECDTF) combines e-Commerce interoperation with distributed, heterogeneous systems interoperation. The greater business world will benefit if these two organizations closely collaborate with each other, W3C and DISA. 

The OMG EC Domain Task Force is developing standards for open markets: Negotiation, PKI, Payments, and Brokerage specifications, with more to come within the framework of OMG's overall reference architecture. The Electronic Commerce Reference Model sets the stage for open market standards backed by a robust distributed computing infrastructure. No organization has contributed more to creating open, standard "middleware that's everywhere" - an OMG slogan. We can understand the OMG's Electronic Commerce Reference Model and the goals of the ECDTF by reading from its draft mission statement:

"The Electronic Commerce Domain Task Force (ECDTF) exists to define and promote the specification of OMG distributed object technologies for the development and use of Electronic Commerce applications by: (1) developing an object-oriented framework for open commerce that promotes the interoperation and reuse of applications and services, and (2) supporting an ongoing process for achieving broad consensus on issues of interoperability and reuse.

The ECDTF will focus on defining and influencing OMG specifications for technology areas related to EC, including: 

The ECDTF will work with other OMG elements to leverage existing activities and specifications. As new requirements are identified, the ECDTF will collaborate with other OMG elements to develop new OMG specifications. Finally, the Electronic Commerce TF will work with outside organizations (such as, CommerceNet, ANSI X12, EDIFACT, CEFACT, TINA-C) through the OMG Liaison committee to leverage and influence related activities and specifications." In recognition of the requirement for knowledge representation in e-Commerce, the OMG ECDTF includes an Agent Technology Work Group that has participants with world-class experience in the commercial intelligent agent community. 

The OMG's initial draft service architecture for open electronic markets, the Electronic Commerce Reference Model, is shown in Figure 8.8. The model is of sufficient depth to address such issues as "policy management" which affects market participant behavior and enterprise system rule enforcement. The architecture reaches deeply into the interactive relationship between participants such as customer and supplier (and their respective agents). Negotiation may equally occur over agreement on policy in order to establish a common, temporary domain. This concept of "dynamic policy domains" built using sophisticated policy management tools opens up new markets in third-party policies, used for the duration of a transaction and then discarded.
 
 

Figure 8.8. OMG's Electronic Commerce Reference Model Architecture

The e-Commerce related standards being evolved by OMG and CommerceNet, as well as the Workflow Management Coalition (WfMC), DISA (EDI) and the World Wide Web Consortium (W3C) are works-in-progress. Corporations wanting to excel in emerging, open markets should participate directly in the work of these organizations. Participation will help a company keep abreast of developments and offers the opportunity to help shape the standards that will serve as the rules of engagement.

The Critical Success Factors

In this chapter and throughout this book, we have explored the challenges and strategies of the third wave of e-Commerce. From working with the pioneers of e-Commerce on large-scale initiatives such as GE's TPN Register, we have seen some common patterns and gained valuable insight through observing traits common to those who have developed sustainable and flexible initiatives. We can now recap and summarize the critical business and technology factors of success. 

Inter-enterprise Architecture.

We have stressed the need for an inter-enterprise architecture to provide an underlying structure that is consistent, easily understood and comprehensive (it includes both business and technology elements). In his column, "Peopleware, Re: Architecture" Larry Constantine writes, "Architecture, whether in the organization of the internal functionality or in the structure of the user interface, is often among the first victims felled by today's time-boxed software projects, short release cycles, and rapid applications development. There seems to be no time to think through the consequences of architectural decisions. Often there is barely time to think. Full stop." The facts, however, remain. The development of a strong architectural vision and the adoption of incremental development cycles are keys to sustainable e-Commerce success. In turn, success in e-Commerce architecture will be determined largely by five key business imperatives: adopting the customer paradigm, optimizing the value-chain, achieving time-to-market, governance, and measuring progress and effectiveness.

Customer Paradigm

In the "old days" producers would determine what consumers could have. They would take their products and push them on their customers. Now, the shoe is on the other foot, subordinating production to the demands of the customer. 

With the new production-consumption equation, customers must be provided complete self-service access to a company's business processes and those of the company's value-chain. The customer-centric company of the 21^st century changes the customer relationship by engineering customer-facing processes from the outside-in, creating the "open" corporation where the customer initiates and conducts his or her own business using the open (yet secure and auditable) resources of the corporation. 

Value-chain Optimization: business-to-business.com

With the customer in control, a business must realign its value-chain around the customer, from end-to-end, squeezing out inefficiencies - and customizing information, products and services. The open corporation is extended to suppliers and trading partners so that when customers touch the resources of a corporation they also touch the resources of the value-chain. 

The customer drives the entire value-chain, determining what is to be produced, when and at what price. Pricing will ultimately behave as is does in the stock market, changing in real-time. As in the stock market, pricing will fluctuate with overall perceived value which, in turn, will be influenced by cyberbranding. The customer will interact with the whole ecosystem, not just the individual company, making general systems theory a core business competency. Companies must directly participate in building the new business ecosystem, or competitors will do it for them. Inter-enterprise architecture provides the framework for customer-driven, value-chain optimization.

Time-to-Software, Time-to-Market

In the domain of e-Commerce, time-to-market is governed by time-to-software. Component-based development is the next logical step in modular software development, a trend that has been underway since the advent of "structured" programming, then structured analysis and design, and then on to object-oriented development. By packaging software constructs and implementations into components, software can be removed from the critical path in time-to-market. Component-based development is the current best practice in software development because it combines strong architectural notions with rapid applications development. 

Governance: Put the CEO In Charge of e-Commerce

The question of e-Commerce governance summons a short and simple answer. Business users of information systems are the most thorough source of business and market knowledge, and the most accountable for business success. E-Commerce is, therefore, a business unit responsibility - with IT playing a role of enablement and support. 

Looking at the chain-of-command in Fortune 1000 corporations, and considering that e-Commerce will form a completely new platform for operating a business, it is logical to conclude that, ultimately, the CEO must also become the CECO, Chief Electronic Commerce Officer. As a company transitions to a fully digital business, the CEO will assume bottom-line responsibility for e-Commerce - to wit, Jeff Bezos, CEO at Amazon.com where e-Commerce is the business.

What's good for the CEO is good for the board of directors. In his provocative article, "Directors' Boards are Clueless About the Internet," Thorton Mays, Vice President of Research and Education at Cambridge Technology Partners, reflects on Emerson, "Ralph Waldo Emerson once observed that 'we learn geology the morning after the earthquake.' The emerging digital economy, and how it's affecting boards of directors, is being studied post-Web-quake by some top business scholars. Their conclusion: The directors of most mainstream companies don't understand the implications of the Internet, aren't aware of their ignorance and are taking no steps to remedy their dangerous strategic blind spot." For one, existing boards are too grounded in vision limiting experience in their industries, the very industries they need to transform. In addition, the ability to unlearn or forget entrenched mental models is a very difficult learning proposition. Boards need to learn new things and forget many of the ways they operated in the past. To overcome this behavioral inertia, Mays contends that boards of directors need to "add new tech-savvy DNA to the board, hire a technology coach for each board member and collectively educate the entire board on the competitive implications of IT."

Balanced Scorecard ROI

Measurement is a critical element in any system of management. As a new platform for conducting business, e-Commerce is a long-term business proposition - a company cannot go out and buy e-Commerce, it must make it a way of business and grow it. Measures of e-Commerce's value should include the long-term value of the business infrastructure it provides as well as the individual return-on-investment (ROI) of specific e-Commerce initiatives. 

Because e-Commerce changes the way a company operates, it calls for new measures of business performance. While financial (ROI) measures have dominated Industrial Age corporations, the business reengineering movement of the early 1990s gave birth to Information Age measures of performance. It follows that if companies were reengineering to do new things, they needed new, consummate, measures of business-critical performance. How else could they measure their progress in translating vision and strategy into day-to-day business reality? 

A modern jet airliner requires many more instruments to measure flight-critical performance than an automobile needs for its simpler operating environment. Business-critical performance in the e-Commerce environment requires measuring the right things, those things that create competitive advantage in digital age competition. 

Robert S. Kaplan and David P. Norton, developers of the Balanced Scorecard method, write, "The emergence of the information era in the last decades of the twentieth century made obsolete many of the fundamental assumptions of Industrial Age competition. The balanced scorecard retains traditional financial measures. But financial measures tell the story of past events, an adequate story for industrial age companies for which investments in long-term capabilities and customer relationships were not critical for success. These financial measures are inadequate, however, for guiding and evaluating the journey that Information Age companies must make to create future value through investment in customers, suppliers, employees, processes, technology, and innovation." More than a financial measurement system, the Balanced Scorecard, is a strategic management system for achieving long-term goals. Kaplan and Norton show how to use measures in four categories - financial performance, customer knowledge, internal business processes, and learning and growth - to align individual, organizational and cross-departmental initiatives and to identify entirely new processes for meeting customer and shareholder objectives. These measures are portrayed in Figure 8.9.

Figure 8.9 Kaplan and Norton's Balanced Scorecard

The Balanced Scorecard serves as a learning system for testing, gaining feedback and updating an organization's strategy. The four perspectives provide a balance between short-term and long-term performance, and include subjective as well as objective measures. When applied to e-Commerce initiatives, measures may include process cycle-time, transaction per employee ratios, cost per transaction, volume of transactions, percent of customers supported by e-Commerce, time to fulfill service requests, and inventory costs. Kaplan's recent research initiatives have extended activity-based analysis to technology and product development and interorganizational measurement systems between manufacturers and retailers that capture supplier and customer profitability. 

Whether it is the Balanced Scorecard or another equally robust system of measurement, measuring "the right things," in addition to financial ROI is crucial to successful e-Commerce. The following anecdote tells the story of measuring the right things, "The concept is interesting and well-formed, but in order to earn better than a 'C,' the idea must be feasible," wrote a Yale University management professor in response to Fred Smith's (founder of Federal Express Corporation) paper proposing reliable overnight delivery service. Is "well-formed" or "competitive breakthrough" the right thing to measure? We can wonder what grade the professor would have given Amazon.com's Jeff Bezos. 

The Ultimate Success Factor

A company deliberating its future in the brave new world of e-Commerce may seek out lessons learned from past experiences with disruptive technologies. "Dear Mr. President: The canal system of this country is being threatened by a new form of transportation known as "railroads." ... As you may well know, Mr. President, "railroad" carriages are pulled at the enormous speed of 15 miles per hour by "engines" which, in addition to endangering life and limb of passengers, roar and snort their way through the countryside, setting fire to crops, scaring the livestock and frightening women and children. The Almighty certainly never intended that people should travel at such breakneck speed," wrote Martin Van Buren, Governor of New York (1828). Like it or not, e-Commerce, along with its many side-effects, is quietly roaring and snorting its way through the business landscape, scaring investors and frightening Industrial Age thinkers and leaders. Whether by evolution or revolution, e-Commerce will create winners and losers in every industry. Who will they be? Who knows? In uncharted territories and in uncertain times, prediction is of dubious value. Through a stream of assimilation, individuals, departments, companies, industries, and markets must learn as they go. They must learn a little, do a little, learn a little, do a little. At each step in the journey, more information will become available and knowledge will grow from experience. 

Rather than being overwhelmed by rapid, discontinuous change, the winners will look back and learn that it was their total commitment to the underlying factors of success that enabled them to arrive at the future first. An inter-enterprise architecture allowed them to build learning organizations that used the first principles of general systems thinking to transform their companies into customer-centric businesses. With this architectural approach, they were able to rationalize, arrange and connect business and technology components to produce the desired results. For them, e-Commerce mastery provided the bridge to the Customer Age. 

Over a decade ago, Arie DeGeus of Royal Dutch/Shell wrote words in the Harvard Business Review that today describe the critical success factor for enterprise-class e-Commerce, "The ability to learn faster than your competitors may be the only sustainable competitive advantage." 
 
 
 
 
 
 

References.

1. Jim Champy, "Goodbye Info Age; Hello Age of Logistics," Computerworld, p. 54, August 24, 1998.

2. Patricia B. Seybold, Preparing for the E-services Revolution: Designing your next Generation E-Business, April 30, 1999, http://www.hp.com/e-services/article_sey_1.html

3. Alexander, Christopher, Timeless Way of Building, Oxford Univ. Press, 1979.

4. Donald A. Norman, The Design of Everyday Things, Currency/Doubleday, 1990.

5. James F. Moore, "The New Corporate Form," in Blueprint to the Digital Economy, McGraw Hill, 1998.

6. http://www.truste.org/about/

7. Paul Allen, A Framework for Business-IT Alignment Using Components. Distributed Computing Magazine, December, 1998. 

8. Christopher Alexander, Sara Ishikawa, Murray Silverstein, A Pattern Language: Towns, Buildings, Construction, Oxford University Press, 1977. 

9. Craig Thompson,Object Services and Consulting, Inc.; Ted Linden and Bob Filman, Microelectronics and Computer Technology Corporation (MCC). Thoughts on OMA-NG: The Next Generation Object Management Architecture. DARPA Research. September 1997.

10. Jon Byous, CO-STARS IN NETWORKING: XML and JAVA&trade; TECHNOLOGIES, http://java.sun.com/xml/co-stars.html

11. For an informative set of articles on XMLbeans, see Mark Johnson, "XML JavaBeans," JavaWorld, 1999, http://www.javaworld.com/javaworld/jw-07-1999/jw-07-beans.html

12. ____Ibid

13. Rik Drummond, Is XML Dead in the Water?, CommerceNet, Research Note #99-07, February 15, 1999. 

14. Ontology.Org, Frequently Asked Questions, http://ontology.org/main/papers/faq.html

15. The XML/EDI Group, The Future of Electronic Business, http://www.geocities.com/WallStreet/Floor/5815/executive.htm

15. Rik Drummond, Executive Consultant to CommerceNet. Report from the Jointly-sponsored CommerceNet and Veo Systems eCo Framework Workgroup, January, 1999.

16. CommerceNet, eCo Architecture for electronic commerce interoperability, 1999. http://www.commerce.net/eco/spec/eCoArchitecture.htm#Section_2

17. OMG, ECDTF, Draft Electronic Commerce Domain Task Force Mission Statement, Revised 5/18/99.

18. OMG, ECTD, Draft Mission Statement revision, May, 1999.

19. Larry Constantine, "Peopleware, Re: Architecture," Software Development Magazine, January, 1996, p. 87. 

20. Thornton May, XMLrfc "Directors' boards are clueless about the Internet," Computerworld, July 12, 1999.

21. Science and Technology Quotes located at http://busboy.sped.ukans.edu/~adams/sciquot.htm

22. ______, Ibid.

23. DeGeus, Arie, "Planning as Learning," Harvard Business Review, p. 74 (March-April 1988).

# # #