The first phase in the process of realizing the electronic commerce portal was an analysis of the content and function requirements. To gain insight into the portal users' needs, the project team visited several insurance companies. Through demonstrations of systems currently used by insurance agents and discussions with developers, the team learned about the typical tasks an insurance agent performs in his daily work and how these can be supported by software solutions. The results of the analysis were organized by breaking the more comprehensive tasks down into singular activities which were then prioritized and documented in requirement forms.

Based on the requirement forms, the subsystems office, content management, procurement, communications, legacy, search and administration were identified. For each of these subsystems, a make-or-buy decision had to be made. After evaluating existing solutions and considering the effort for developing a subsystem from scratch vs. integrating the existing solution, the team chose the integrative approach for most systems, namely:

• Office: Outlook 98 by Microsoft Corporation (Byrne, 1999)
• Content Management: Pirobase 4.0 by PiroNet AG (Pironet, 2000)
• Procurement: SmartStore Standard Edition 2.0 by SmartStore AG (SmartStore, 2000)
• Communications:
  • e-mail: JavaMail by Sun Microsystems, Inc. (Sun, 2000)
  • Fax: sendfax - Freeware; included in Linux 6.3 (i368) by SuSE GmbH (SuSe, 1999)
  • SMS: yaps - Freeware; included in Linux 6.3 (i368) by SuSE GmbH (SuSe, 1999)
• Legacy: Sample partner database of the Continentale Versicherung

The search and administration systems were not classified as external systems but as controllers since they actively request or modify information of the other systems.

To test the feasibility of these decisions, the team programmed cut-through prototypes, i.e. "quick-and-dirty" implementations of the adaptors described in the system architecture. The goal of these prototypes was to prove that it is possible to encapsulate the native interfaces of the external systems and make their key features accessible via the adaptors. This goal was met for all subsystems, clearing the way for the next phase of the software development process.

For the object oriented design phase, the team used the Unified Modeling Language (UML) (Booch et al., 1999). The key features of all subsystems were modeled in use cases in order to identify business objects and possible dependencies between the subsystems. Based on the insights gained in this step, concrete classes were defined for each subsystem. To ensure an easy consolidation of the results and allow for later changes to the subsystems without touching any dependent classes, each subsystem is represented at the "outside" by one boundary class. This class provides all methods other classes need to access the subsystem. As an example, let's consider a search request handled by the legacy system (Figure 3):

Figure 3. Integration of Legacy System

The large box in the middle is a view inside the legacy subsystem that we know from previous figures. The smaller boxes inside represent classes. Because only the legacy boundary class is connected to the workflow controller via the middleware, in our example the controller does not pass the search request object directly to the query encoder. Instead, the search request is passed to the legacy boundary class which then passes it to the query encoder. This class is a part of the adaptor that, as discussed earlier, hides the native interface of the external system from the portal subsystem: In the case of the legacy system, queries and results of the insurance company's partner database are XML-encoded (Bray et al., 1998) for maximum platform and transport independence. The XML-encoded search query is run against the insurance company's database, and the encoded result is returned to the legacy subsystem where the result decoder (another part of the adaptor) creates a search result object and passes it to the legacy boundary class, which returns it to the workflow controller.

After consolidation of the designs for subsystems, controllers and user interface, the team entered the implementation phase. Most classes were implemented in the Java programming language (Gosling et al., 1996), only the adaptor for the office system uses Microsoft Visual C++ (Kruglinski, 1997) code to access the Microsoft Outlook 98 API.

Figure 4 shows the homepage of the electronic commerce portal. After logging into the system, the insurance agent is presented with all information that is relevant to him that time: Personal messages, articles of interest from the content management system, scheduled appointments and due tasks from the office system, events and items from the procurement system. Legacy applications like the partner database and a provisioning system are accessible via links on the homepage. A search interface allows for meta searches in selected areas of the portal.

Figure 4. Electronic Commerce Portal Homepage

< Architecture | Conclusion >