Enterprise Architecture for Open eCommerce

Designing interoperable information systems

Peter Fingar

Peter Fingar is a recognized author and independent consultant focusing on component-based eCommerce.

He can be reached at http://home1.gte.net/pfingar. 

This is the stuff with which CEOs, not just programmers, must grapple.  This does not leave, however, the IS department off the hook.  On the contrary, information systems architecture must be tightly aligned with business architecture. What good is a paper palace of innovative business architecture unless the vision can be executed? Execution means building on today's heritage systems by creating open systems architectures that are agile and can embrace standards of interoperability as they emerge. Moreover, both enterprise and inter-enterprise architectures must be developed in order to participate in open eCommerce.

Enterprise computing is about consolidating and harmonizing the many islands of disparate information and systems scattered throughout an enterprise into a unified whole. The goal is to streamline business processes and enable outward-facing information systems. The attention given to enterprise computing over recent years is a result of the business process reengineering revolution which, in turn, was enabled by information technologies such as client/server computing. Through some hard learned lessons, corporations now know that it is not enough to wire together machines through a network using a client/server architecture. Although a well thought out technical architecture may have been developed, what is missing is a coherent information model. This is where object-orientation comes into the picture. 

Business objects are vital  as a means of developing the agile software needed for eCommerce.   Business objects are chunks of software that reflect real things in the real world: customers, employees, orders, shipments, and so on. Business objects combine their processes and their data into a single entity in such a way that the integrity of the object is assured by the object itself. The addition of the component paradigm moves business objects one step further. Business objects, though they represent things in the real world, become unwieldy when they are combined and recombined in large-scale commercial applications.  What is needed are ensembles of business objects that provide major chunks of application functionality (e.g. preprogrammed workflow, transaction processing and user event notification) that can be snapped together to create complete business applications. This approach is embodied in the next step in the evolution beyond objects, application components. 

This focus on business objects with their underlying information models is in contrast to the relational database model typical of client/server architectures where data is isolated from the processes that manipulate it. Such processes can be scattered across an organization and many integrity and complexity problems result. Companies that tried to crisscross connections among the many relational databases and processes that use them ended up with incomprehensible spaghetti architectures and were not successful in creating a unified enterprise information infrastructure. 

Application components and business objects can handle the tasks of business processes and activities while suppressing the details of the underlying systems plumbing objects. The technology resources are needed, of course, but a component architecture supports the high level business objects by encapsulating and separating out the underlying systems services infrastructure. The component paradigm provides just such technical facilities - for example, the containers in the Enterprise JavaBean (EJB) specification. While the EJB specification is only for Java at this time, the OMG’s CORBA 3.0 is in the initial stages of creating a generic component packaging model called the CORBA Component Model (CCM). Dr. Richard Soley, Chairman and CEO of the Object Management Group (OMG) explains, "CORBA 2.0 attacked interoperability. CORBA 3.0 attacks ease of use and Web/Java Integration." Steve Mills, General Manager of IBM Software Solutions adds, “We view CORBA 3 as a critical global building block in a quest to help customers enable e-business.”

In addition to allowing corporations to work with business information models and semantics, the distributed object paradigm is essential to tying together disparate islands of information throughout an enterprise and across enterprises to form business ecosystems - the essence of eCommerce. The secret is that the objects need not be on a single machine. Objects can exchange messages across networks as easily as within a local computer system. This interoperation is possible among objects programmed in different languages (COBOL, C++, Java); existing heritage or legacy systems can be "wrapped" to appear and function as objects; and the platform can be of no matter, a mainframe, a Unix server, or a PC. An object request broker or ORB makes all objects on the network appear just as though they reside on the local machine. 

The Object Management Group, an 800 plus member organization, has developed the standards needed for truly open systems, the Common Object Request Broker Architecture (CORBA). De facto standards also exist, but Microsoft's DCOM requires all participants to be selected versions of Microsoft only operating systems, and Sun's Remote Method Invocation (RMI) initially spoke Java language only and couldn't talk to C++ or Smalltalk objects until it was restructured above OMG's Internet InterOrb Protocol (IIOP). Fortunately bridges are being build to cross the chasms of these distributed computing standards. To wit, IONA Technologies’ OrbixCOMet Desktop combines both CORBA and Microsoft COM, and IONA announced plans to integrate Microsoft Transaction Server (MTS) and IONA's OrbixOTM standards. In addition, since a JavaBean can look like an ActiveX control and visa versa, developers do not have to necessarily choose between the two client-side component standards. The same can be expected for server-side components.

Distributed object computing sets the foundation for both enterprise computing and the inter-enterprise computing that is essential to open processes of eCommerce. In fact, it is the distributed object paradigm that has made it possible for eCommerce 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. In other words, common business semantics must be available to all participants in an open digital market. 

Like the little inscription on your car's rear view mirror says, "objects are closer than they appear." OMG's Common Object Request Broker Architecture (CORBA) has made system and technology interoperation available for a number of years now, and many mission critical business systems and applications have already been developed by Fortune 1000 companies with staffs who have climbed the learning curve of distributed object computing, handling low level systems and plumbing objects along with business functionality. The interface definition language (IDL) specification allows programmers to write and publish interfaces that can be used by objects anywhere at anytime. To date, however, developers have had to master a mix of business object semantics and the underlying systems objects which require low level plumbing in order to build complete business solutions. What is needed is a business object component model that suppresses the complexity of the underlying systems technology, thus providing a clear separation of concerns. With such a model, business solution developers can assemble and tailor prefabricated business components into complete solutions.

The exciting stuff in the object world is just now in the process of being standardized by the OMG, the CORBA Component Model (CCM). It addresses both the Business Object  Interoperability Framework initiative and Unified Modeling Language (UML) extensions to support the business object paradigm. CORBA components suppress the low level development tasks needed in the original CORBA approach. In short, CORBA components provide a higher level of abstraction of CORBA and object services, greatly simplifying CORBA applications development.  How all this fits together is shown in Figure 1.

As shown, CORBA is the foundation for distributed object computing and provides objects with not only transparent access to other objects, but also to infrastructure objects known as CORBAservices and CORBAfacilities. Such common facilities and services allow programmers to "plug into" standard preprogrammed services such as transaction processing, permanent storage of objects, event-handling services and the like. They may be thought of as the essential computing services, and programmers ask for the services without having to know the internal workings of the objects that deliver them. The low level systems services call on the actual technology infrastructure that may consist of wrapped legacy systems as well as services provided by native objects. Although not yet a standard, the Business Objects Interoperability Framework initiative seeks to provide a meta-model for business semantics. For the latest information on CORBA components visit OMG’s web site at www.omg.org.

The World Wide Web is extremely complex under the covers, but it is simple for a business user to browse the Web. The telephone is easy to use while telephony and telecommunications are very complex. As shown in Figure 1, technologists are component builders and deal with the complexity of the underlying information systems and technology infrastructure. Their expertise includes object level interaction via the interface definition language (IDL). Computer specialists are the toolsmiths for building reusable components. Business solution developers, on the other hand, are able to assemble application components using business constructs and semantics that insulate them from the underlying complexity. With this clear separation of concerns between component builders and component assemblers, the ultimate language of applications development will be the "language of business," not "the language of computers." Eventually, as the component paradigm matures, business people will be trained to develop many of their own information systems solutions to business problems. 

The component paradigm will forever change "programming." Application programmers who make up the bulk of today's commercial IS shops will simply go away. Where will they go? They will work for software vendors who manufacture components. Microsoft, SAP, Baan, SSA, IBM, Oracle and most other software vendors are working hard to bring about the shift from writing code to component assembly. Application components, however, 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 eCommerce components shown in Figure 1. The eCommerce components provide essential inter-enterprise functionality for electronic 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 the frameworks to 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. 

Much of the extension and tailoring of components focuses on the user interfaces and involves both graphical and task-centered customization. In the long run, corporations will no longer design and code their applications. Instead they will buy component-based enterprise application packages. These packages, however, will not be the complex, hard to understand and configure packages we see in today's ERP world. They will be frameworks based on distributed object architectures that allow individual components to be mixed and matched even though they are built by a variety of software vendors. Hello frameworks, good bye compilers. Hello solution developers, good bye corporate programmers. As a precursor to this trend, notice the new phenomena of teaching vendor specific courses in business schools. SAP and other ERP vendors are aggressively implanting their software, based on case studies, into business (not computer science) curriculums at both the graduate and undergraduate levels. The result will be business graduates who can build information systems from frameworks. The programmer as "translator" between the business and the computer will fade into history. 

What language will solution developers speak? As shown in Figure 1, CommerceNet is working on the Common Business Language (CBL) as one such language for gluing together eCommerce components in their evolving eCo System architecture. Other high level tools such as IBM’s VisualAge for Java, Inprise’s Open JBuilder, and Sun’s Java Studio serve as component assembly means and suppress the details and complexity of the underlying technologies and systems. Sure there will be new languages to master, but the task will be mastering the semantics of business, not the computer. 

At the middle level of Figure 1, notice the Common Business Objects (CBOs) that represent objects of interest across industry bounds - customer, shipping document, account, order, and so on. Using these CBOs, industry specific business objects and framework specifications are being developed by various consortia and standards groups such as the OMG's domain task forces: Manufacturing Domain TF, Telecommunications Domain TF, Financial Domain TF, CORBAmed TF, and the Transportation Domain TF. Meanwhile, the Open Applications Group (OAG) is forging standards for applications interoperability among ERP vendors. ACORD is taking on the standards task in the insurance industry, the Supply Chain Council is addressing supply management, RosettaNet is focused on the IT industry supply chain, and POSC is addressing the standards needed in the oil and gas industries. Through such groups consistent business semantics are defined and evolved that enable the building of open markets and processes. The new rising star of web standards, the eXtensible Markup Language (XML), is nothing without agreement from these industry groups on such deep and contemplative issues such as “what is a part number?” Agreement on naming conventions has eluded computer systems developers since the advent of centralized data bases in the 1960s - just ask any Data Administrator. Data semantics are one thing. Consistent behavioral semantics are yet another monumental challenge that must be met. 

OMG's Electronic Commerce task force is tackling the domain of electronic commerce business objects and service architecture for open electronic markets, the Electronic Commerce Reference Model shown in Figure 2. The model is of sufficient depth to address such issues as "policy management" which affects agent behavior and enterprise system rule enforcement, and 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. For information and status of this vital work, visit http://www.osm.net/about/library.cfm. 

While somewhat differing in approach to interoperation among commerce participants, CommeceNet is developing its eCo System architecture around the new Web standard, the eXtensible Markup Language (XML). XML describes structured data packages that move around the Web 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. With links to processes and objects containing behavior, XML can make commerce applications such as Electronic Data Interchange (EDI) available to small and mid-sized companies that have not been able to afford such systems. The eCo System architecture does not preclude OMG's or other object models due to linking facilities that allow behavior to be added to XML documents. Quite the opposite, eCo System needs access to such deep and adaptive object infrastructures to handle the business processes and workflows inherent in real commerce. In fact, the World Wide Web Consortium (W3C) is developing the next generation of the Web to incorporate an underlying distributed object model, HTTP-NG. The lynchpin between XML and CORBA will be the W3C’s Document Object Model (DOM) that defines an object-oriented API of an XML document.  The name "Document Object Model" was chosen because it is an "object model" as used in the traditional object-oriented design sense: documents are modeled using objects, and the model encompasses not only the structure of a document, but also the behavior of a document and the objects of which it is composed. For an informative report, "Towards a Web Object Model," visit http://www.objs.com/OSA/wom.htm. Companies seeking architectural direction will keep a close eye on these standards activities, and those intent on leading their industries will participate directly in developing the standards. 

Putting their information systems house in order (so they can integrate their internal islands of information into a unified whole and interoperate with their suppliers and customers) should be the highest priority of CEOs and other business leaders. This is the stuff of business strategy for the future. Not only handling, but embracing change is the foremost criteria. Distributed object computing and enterprise system architecture provide the blueprints. 

Building technology alliances will be key. Leading software vendors are hard at work to establish leadership in this brave new world and deliver solutions today, not in some distant future. For a quick survey visit the following web sites: IBM's San Francisco Project (www.ibm.com/Java/Sanfrancisco/prd_summary.html), OSM Sarl's Business Agents (www.osm.net), and EC Cubed's ecWorks (www.eccubed.com). Other companies to watch include Veo Systems (www.veosystems.com) and Ensemble Solutions (www.ensemblesolutions.com).  Visit www.commerce.net and www.omg.org to find other leading firms building the future of eCommerce. 

Information systems architecture must be tightly aligned with business architecture in the chaotic and uncertain business world of the future where the system is the business and the business is the system. No company is an island, and industry boundaries are becoming blurred into new and evolving  business ecosystems. The goal of enterprise systems architecture is to design information systems that have the interoperability and agility demanded of them in the unfolding world of eCommerce. The tasks are to build solid architectural blueprints that preserve inward focused heritage systems while extending them outward to suppliers, trading partners, and customers.  To maintain their lead, progressive companies will directly participate in the work of setting the standards that make this new world of digital commerce possible. Now is the time to build the architectural foundation for competing in the digital economy.
# # #