INTRODUCTION
One of the common beliefs within business today is that a portal is required in order to link an organization to its major customers. The typical response to such an idea is to then invest a considerable amount of money on infrastructure in order to build a portal. The question that often follows a review on a newly implemented portal is: What is the cost of the technology versus the return on investment or have we just created a money pit? The business finds it has just invested in endless applications, adaptors, licenses, committed staff, and resources over a six-month planning period and a twelve-month application development phase prior to implementation; which may have cost up to US$10 million dollars). But often the simpler and most economic approach is overlooked. Could a business literally save 97.5% of this financial outlay had they considered or chosen the alternative to an in-house portal development and partnered with an e-marketplace creating a cluster of e-booths and portlets residing on someone else’s technology. This can have exactly the same effective result as an overarching multi functional “uber-portaF at a fraction of the build-your-own-portal scenario (Gartner, 2003). The potential savings for corporations in implementing portals via the e-marketplace philosophy can be staggering and should not be dismissed when exploring a corporate built portal. Is this a consideration commonly used amongst businesses today?
This article addresses the possibilities of foregoing the build option for the corporate portal and hosting the corporate portal on an e-marketplace. From the users perspective there is essentially no difference. From an image perspective it may mean an adjustment in culture that is required especially from those organizations who still may not accept outsourcing as an option. From a financial perspective the savings can be considerable as the e-marketplace hosting option provides the required portal infrastructure. Both authors having been involved heavily in e-logistics and e-markets respectively since 1999, discuss the e-marketplace hosting option for potential business advantages and savings.
A PORTAL’S FUNCTION
The term “portal” is usually used as a marketing term to describe a Web site that is, or is intended to be, the first place people see when using the Web. Portals have emerged out of a need to enable users to quickly and efficiently obtain information relevant to their needs. Typically “a portal site” has a catalogue of Web sites, a search engine or both. A portal basically offers search and navigation sites, are supported by advertising and offer syndicated or user generated content (e.g., Yahoo). Portals come in many shapes and forms, but essential are accessed via an Internet, intranet, or extranet environment using a common language such ebXML, XML, SOAP (simple object access protocol) or WSDL (Web Service Description Language). Beneath portal’s presentation layer lies technology that integrates and consolidates all the separate information sources, data, applications and other types of content into the single, consolidated view presented to a user. Beneath portal’s presentation layer lies technology that integrates and consolidates all the separate information sources, data, applications, and other types of content into the single, consolidated view presented to a user. Portals basically are a framework or presentation layer in which the user can access data from multiple areas. It can be accessed via an Internet browser, a personal digital assistant (PDA), or a Blackberry.
A portal site may also offer e-mail and other services to entice people to use that site as their main point of entry. Customers accessing a portal have the ability to trawl through various sites but always within the environment of the original Web site—reinforcing who has brought this service to the customer. Portals like any other type of Web site, are designed with the specific needs of the user in mind. Requirements are gathered with the view to determining what users will need to do and want to do when they visit a portal. Once these requirements are understood, the portal is designed around the specific task the user will perform to accomplish it’s objective.
Because user objectives vary widely, portals differ in the content, functionality and applications they present to the users. Portals tend to have some general features that are common. These include:
• Single point of entry
• Single sign-on to all portal areas and applications
• Consistent interface
• Consolidation, integration and aggregation of relevant content to fit user roles and tasks
• Personalization of content to individual preferences and behaviours
• Efficient support of business processes and tasks
• Logical user-centered taxonomy and structure
• Knowledge management and collaboration
• Search and retrieval of additional content
Technology trends indicate an increasing reliance on Internet portals as an economic means of access as outsourcing drives the need for remote access. Portals will succeed or fail for all the usual business reasons. No matter how integrated and automated a business becomes, it will always be driven by demand, be it that of the customers, partners, and employees. Technology does not drive a portal. The business, customers, or users set the expectation. The portal may need to be totally personalized, it may require realtime information at any time, from any place, immediately in order to access data driven by the needs of the business, customer or user. It may also be a channel to a minimalist set, or a wealth of applications. The cost of set up may not at all be proportional to customer satisfaction and utility of the portal itself.
THE ELECTRONIC MARKETPLACE AND IT’S PORTAL RELATIONSHIP
An electronic marketplace generally comprises six main activities: information based activities relating to contracting including product selection, product comparison, formulation of mutually binding contracts, transaction execution based activities, order placement, order fulfillment, settlement followed by traditional logistics (see Figure 1). These facilities may be available without the need for third party providers if it were owned by an organization that offered technology services similar to that of an e-marketplace and had the infrastructure similar to that of a postal authority which may have both distribution and fulfillment divisions (i.e., Australia Post, Duetsche Post, etc.). (Hassall, 2003). Traditional marketplace participants generally prefer to deal within a single entity relationship rather than multiple service providers. An electronic marketplace on the other hand offers a variety of functions that may be performed by multiple relationships yet appear as a single transaction to the user. For example a document exchange capability, provided by an e-marketplace, combined with the distribution and logistics broadens the offer to potential customers outside that of a purchase transaction (see Figure 1).
Figure 1. Focus of electronic transaction execution
Figure 2. Outsourced portal architectural model for a large organization
POTENTIAL MODELS WITHIN AN ELECTRONIC MARKETPLACE
An electronic marketplace has the ability to deliver an inter-organizational, transactional processing environment that can support the following commodity based portals. If it is accepted that an electronic marketplace can provide all functionality of a portal it can also stand that the e-marketplace can therefore broaden its offering to provide portal functionality to many organizations if they so wish to outsource (see Figure 2).
However, as some e-marketplaces such as corProcure, Kaboodle, Farmland, Marketboomer, and Bartercard have discovered, focus on technology, lower prices, and connectivity is not a sustainable model nor attractive to potential users. Success was only achieved after the potential portal provider was able to articulate a compelling value proposition to its prospect. In some cases this realization came a little too late as business revenues declined to the point of no return, as was the case with Kaboodle and corProcure. Buyers wanted hard tangible dollar benefits and suppliers wanted to maintain their margins. The sustainable model involved a solution that could take the cost out of the business supply chain and surround the commodities with value added services.
A collaborative partnership approach amongst buyers/suppliers combined with the technology provided by the portal provider being at the epicenter to facilitate the exchange of information around goods/services could be seen as a contributing party (as opposed to a ‘broker’) to both buyers and suppliers succeeding in the economy. Limited content integration still supports simple business processes. There are two common solutions that are used in portal models:
Non-Personalized Portal
The non-personalized portal such as the aviation portal www. webjet.com is designed to present information about travel options categorized by the type of travels packages. It can be refined to include airline, accommodation, and car hire in geographical areas. You conduct a search of alternative travel destinations and obtain a number of options for your trip. It takes only a few minutes to obtain the information you need and you are able to compare alternatives before selecting the most appropriate to your needs. The information available is provided by travel companies via the one gateway. The user has fewer URLs to remember and information is available from origin to destination via one site. The draw backs may be the immense amount of information available and the wide range of choices.
Figure 3. A portal has many users
Personalized Portal
The personalized portal gives you access to your personalized Web page. It is customized to display details of your preferred mode of travel based on your specific user profile, including your home address and previous travel information obtained through the portal. You may enter your destination into the search and receive a recommendation of the cheapest, most direct method for your trip having taken into consideration your personal preferences. Other details supporting the recommendation, such as online booking, maps and accommodation are also provided.
The Enterprise Approach to Portals
Some companies have chosen to create virtual repositories and created common metadata that all users and systems can follow. If we accept that this is a problem within an enterprise how broad are these if applied to an electronic marketplace where there are a number of models applied across a single portal offering a wide range of portlets. Many organizations using multiple portals, are presenting applications and information to different users with varying profiles dependent on their role (see Figure 3). This in many cases has provided an easy and cost effective way to access data. Today as the infrastructure becomes easier to work with vendors are able to create robust frameworks that are easy to install, setup and deploy.
If we were to partition access within a portal and create a portlet that provides quick access to say a recruitment agency information for large organizations looking for casual staff on-call, will have the ability to access a labor hire portal to source resources 24×7 from any location (see Figure 3). In the past, recruitment agencies relied on organizations accessing cumbersome knowledge bases in an what may have become an overloaded repository which was also difficult to access remotely. When connected the user had trouble locating the correct information on specialist staff requirements. This task can now be provided in a timely, and efficient way, as employers seek a recruitment agency to provide staff in their area of expertise via portal access.
Same Portal, Different Deployment
Valdes (2003) writes, in his report for Gartner on “Narrowing the Broad Spectrum of Portal Costs,” that “the price to deploy a portal can vary from tens of thousands of dollars to several million. Cost variance depends on many factors, such as vendor pricing models, end users’ integration requirements, vendor discounting and the type of deployment the enterprise is planning.” It is suggested that “the portal” is multifunctional in that it can be deployed in different ways to meet a range of requirements.
Since their inception in 1998, portal products have evolved through four generations of technology, and the fifth generation is on the horizon. Features include:
Figure 7. The e-marketplace view of the corporate portal users
• A unified access to content across multiple repositories and data stores.
• A unified search capability.
• Access to applications via a single sign on.
• A general purpose platform for building a new class of applications, called composite applications.
As the portal sector continues to mature, the differentiators based on technology and features (including development capabilities) will diminish. Development tools will become more powerful and productive, and will be used to leverage economies of scale fostered by emerging portal standards, such as Java Specification Request 168 (JSR168) and Web Services for Remote Portlets (WSRP). Dealing with government may in fact be revolutionized by future portal application (Khrosrow-Pour, 2005), and this could also be achieved at a cheaper cost via an e-marketplace, after all a government department is akin to a large corporate.
Vendors are now paying more attention to the need for rapid, inexpensive deployment and continue to add tiered product lines that include “express” versions or quick-start packages. The final cost driver is variation in infrastructure and operational requirements.
One portal package may be more efficient than another and require less hardware. Some packages require servers dedicated to different types of functions (corresponding to the major elements of the portal software architecture). This source of variance will in time diminish.
THE E-MARKETPLACE VIEW OF A PORTAL
Other than what might be no more than a personalized login for a group of users the e-marketplace has little other requirement for any set of corporate portal users being differentiated from the other marketplace customers. This is represented in Figure 4. In brief there is an e-marketplace. It hosts suppliers and users. For simplicity let us assume that there are two types of users: the corporate portal users and other customers. In this example the corporate portal users have an interface to the marketplace, but this will be a different interface to the other users of the marketplace. Both the portal and other users will use specific marketplace applications and also specific suppliers. However, it may be a business rule or requirement that only specific applications or suppliers can be accessed by the corporate portal. The other users may have some similar partitioning but some users may have full access to all applications and suppliers.
In essence the portal users are just another customer with particular access requirements to selected suppliers and applications on that e-marketplace.
As long as the e-marketplace has the specific applications the clients and the instigating corporate portal customer requires, then the e-marketplace can segment any number of “requirement clusters” into “virtual portals,” which are just as effective for the portal users as the partitioning is for the other users. It is not transparent to the corporate customers or other users that they are connected through an e-marketplace, instead of a portal, but do they care? This philosophy was the basis for one of the future business strategies for one of Australia’s longest serving e-marketplaces, www. corProcure.com.
OPEN-SOURCED PORTALS
An open-sourced portal provides an enterprise with numerous advantages not afforded with traditional commercial software where you can feel more like a customer and not like a prisoner (McGovern, 2005). The value proposition of gaining access to source code avoids a dilemma faced currently by many enterprises when acquiring software, only to find the inevitable collapse of the vendor. By adopting open sourced portals enterprises are no longer at the mercy of the vendors and unfixed bugs especially those which are security related. Open source software provides enterprises with the opportunity to get support from other providers, thus gaining considerable freedom of movement. There remains the risk of going under as is the case with all service vendors. The advantage here is that you have the source code and can generally rebuild the technology from within your own technical team.
CONCLUSION
The possibility of hosting corporate portals through e-marketplaces is not a chant you hear loudly from the e-Business consultants. However, to investigate the option is an absolute necessity for every business case proposing the building of a portal. The selection of the right and appropriate e-marketplace is important for business image but the savings are so significant if the appropriate e-marketplace is selected, then every chief executive officer, chief information officer, or even chief marketing officer must be given the choice. The flexibility and the savings of hosting portals on an e-marketplace is an obvious collaborative and partnering opportunity, but which unfortunately seems to have been all too often overlooked, or has not even been suggested as an alternative option to building a portal. The only downside is saving millions!
KEY TERMS
eDNA: Enhanced diagnostic navigational aid. Electronic Business extensible Markup Language (ebXML): ebXML (Electronic Business XML) is a project to use the eXtensible Markup Language (XML) to standardize the secure exchange of business data. Among other purposes, ebXML would encompass and perhaps replace a familiar standard called electronic data interchange (EDI). ebXML is designed to enable a global electronic marketplace in which enterprises of any size, and in any location, could safely and securely transact business through the exchange of XML-based messages.
eXtensible Markup Language (XML): A flexible way to create common information formats and share both the format and the data on the World Wide Web, intranets, and elsewhere. For example, computer makers might agree on a standard or common way to describe the information about a computer product (processor speed, memory size, and so forth) and then describe the product information format with XML. Such a standard way of describing data would enable a user to send an intelligent agent (a program) to each computer maker’s Web site, gather data, and then make a valid comparison. XML can be used by any individual or group of individuals or companies that wants to share information in a consistent way.
Linehaul: Transport haulage depot to depot direct, usually distances in excess of 100km. May include customer direct delivery for large customers.
Personal Digital Assistant (PDA): A term for any small mobile hand-held device that provides computing and information storage and retrieval capabilities for personal or business use, often for keeping schedule calendars and address book information handy.
Simple Object Access Protocol (SOAP): A way for a program running in one kind of operating system (such as Windows 2000) to communicate with a progam in the same or another kind of an operating system (such as Linux) by using the World Wide Web’s hypertext transfer protocol (HTTP) and its eXtensible Markup Language (XML) as the mechanisms for information exchange.
Uberportal: An uberportal is a lightweight, thin portal framework that overarches other portals. The uberportal is a horizontal portal, while the underlying portals may be horizontal or vertical. The key integration points between the uberportal and the underlying portals include directory, security, personalization profiles, metadata, and the portlets. The uberportal becomes the initial entry point, and user interface personalization will likely be handled there as well. An uberportal can not be bought “out of the box.”
It must be built on top of the framework of a horizontal portal product.
Web Service Description Language (WSDL): An XML-based language used to describe the services a business offers and to provide a way for individuals and other businesses to access those services electronically.
Web Services for Remote Portlets (WSRP): Web services were initially conceived to execute as standalone pieces of software for interoperability purposes, their actual use has exploded into many application realms.
