Customer experience management (CEM) denotes a set of practices, processes, and tools that aim to personalize a customer's interactions with a company around the customer's needs and desires. This personalization depends on the purchase scenario at hand, and on how much a company knows about its customers. In turn, the purchase scenario depends, among other things, on the complexity of the product or service being offered (e.g., a carton of milk versus a house), and the complex set of motivations that can trigger a purchasing process. E-commerce software tool vendors need to provide the building blocks that enable retailers to configure and develop CEM functionalities that take into account these factors. In earlier work, we proposed such building blocks within the context of a CEM development framework that relies on a cognitive modeling of the purchasing process and identifies the touch points between seller and buyer and relevant influence factors. We envision a CEM scenario specification tool that enables business analysts to specify their purchase scenario, from which we generate data structures and algorithms to implement CEM functionalities by instantiating the framework. The framework is embodied in a set of ontologies and algorithm templates that can be instantiated with the specification parameters. In this paper, we present the principles behind our approach, and a prototype CEM scenario specification tool. We illustrate the tool with a moderately complex purchasing scenario, to validate the underlying theory, and to explore implementation strategies

Typical OO applications implement several functional features that are interwoven into the same class hierarchies. In the absence of aspect-oriented techniques to develop and compose functionalities, developers resort to object-oriented design and programming idioms. Given a legacy OO application, it pays to identify existing functional features to help understand the structure of the application and potentially to extract those features into separate software modules that can be maintained and reused individually.We are interested in the identification of functional features in legacy OO code. We first characterize what we mean by functional feature, and then explore the footprints that such features are likely to exhibit in a legacy application that integrates many of them. We identified three such footprints: 1) aggregation, 2) multiple inheritance, and 3) repetition (ADHOC). We describe a set of algorithms for recognizing such footprints in legacy code, and then present the results of experiments where we applied those algorithms to five open source applications: JHotDraw, FreeMind, JReversePro, JavaWebMail, and Lucene. Our results show that: 1) the different algorithms are able to identify the important functional features/dimensions within an application, 2) they can identify opportunities for reuse and refactoring, 3) they are complementary, and 4) they can serve as the basis for a design aid. We compare our work to related research, and conclude by discussing directions for future research.

Companies model their business processes either for documentation, analysis, re-engineering or automation purposes; usually using normalized business process modeling languages such as EPC or BPMN. Although these models explain how the processes should be performed and by whom, they abstract away their business rationale (i.e. what is offered and why). Business modeling aims to answer the latter and different frameworks have been proposed to express the process in terms of value-chains. Ensuring alignment between both of these views manually is error prone and labor intensive. In this paper, we present a novel approach to derive a value-chain - expressed in REA - from a business process model expressed in BPMN. At the heart of our approach and our main contribution lies a set of nine general business patterns we have defined and classified as structural and behavioral patterns.

Organizations build information systems to support their business processes. Some of these business processes are industry or organization-specific, but most are common to many industries and are used as is, modulo a few modifications. Our work tries to capitalize on these similarities to develop a methodology and tools that help business analysts generate organization-specific process models from a catalog of generic business processes. We developed a framework for representing and classifying business processes that supports process variability management by, 1) navigating a repository of generic processes, and 2) automatically generating new process variants around key process variation points. We use business patterns from the Resource Event Agent ontology to identify variation points, and to codify the model transformations inherent in the generation of the process variants. We developed a prototype, showing the computational feasibility of the approach, and validated the relevance of the variation points, and the correctness of corresponding transformations in the context of ERP key processes, showing the conceptual soundness of the approach.

A typical e-business transaction takes hours or days to complete, involves a number of partners, and comprises many failure points. With short-lived transactions, database systems ensure atomicity by either committing all of the elements of the transaction, or by canceling all of them in case of a failure. With typical e-business transactions, strict atomicity is not practical, and we need a way of reversing the effects of those activities that cannot be rolled back: that is compensation. For a given business process, identifying the various failure points, and designing the appropriate compensation processes represents the bulk of process design effort[8]. Yet, business analysts have little or no guidance. For a given failure point, there appears to be an infinite variety of ways to compensate for it. We recognize that compensation is a business issue, but we argue that it can be explained in terms of a handful of parameters within the context of the REA ontology, including things such as the type of activity, the type of resource, and organizational policies. We propose a three-step compensation design approach that 1) starts by abstracting a business process to focus on those activities that create/modify value, 2) compensates for those activities, individually, based on values of the compensation parameters, and 3) composes those compensations using a Saga-like approach. In this paper, we present our approach along with an implementation algorithm and propose a business ontology for compensation design.

Service oriented paradigm offers a way to leverage business agility and reactivity by shortening time-to-market and increasing reusability. However, we argue that in order to offer robust software the business process designer has to account for numerous error paths with little or no guidance. Many studies have shown that this activity represents the bulk of the design process. In this paper, we propose an approach at assisting the process designer in assessing the compensatory activities based on business objectives that we model through a value chain.

Software development is a fairly complex activity, that is both labour-intensive and knowledge-rich, and systematically delivering high-quality software that addresses the users’ needs, on-time, and within budget, remains an elusive goal. This is even more true for internet applications presents additional challenges, including, 1) a predominance of the highly volatile interaction logic, and 2) stronger time-to-market pressures. Model-driven development purports to alleviate the problem by slicing the development process into a sequence of semantics-preserving transformations that start with a computation-independent model, through to an architecture-neutral platform independent model (PIM), all the way to platform-specific model or code at the other end. That is the idea(l). In general, however, the semantic gap between the CIM and PIM is such that the transition between them is hard to formalize. In this paper, we present a case study where we used an ontology to drive the development of an e-tourism portal. Our project showed that it is possible to drive the development of an internet application from a semantic description of the business entities, and illustrated the effectiveness of this approach during maintenance. It also highlighted the kinds of trade-offs we needed to make to reconcile somewhat lofty design principles with the imperative of producing a product with reasonable quality

The separation of concerns, as a conceptual tool, enables us to manage the complexity of the software systems that we develop. Such was the intent behind the OORAM [Reenskaugh et al., 1995]. When the idea is taken further to software packaging, greater reuse and maintainability are achieved. There have been a number of approaches aimed at modularizing software around the natural boundaries of the various concerns, including subject oriented programming [Harrison & Ossher, 93], composition filters [Aksit & Bergmans, 1992], aspect-oriented programming [Kiczales et al., 97], our own view-oriented programming [Mili et al., 99-02], and many others. The growing body of experiences in using separation of concerns techniques have identified a number of issues, both fundamental ones (what is an aspect, what is a concern, which concerns are separable, which aspects are composable) as well as technical ones (how to use a particular technique to solve a particular problem). Rather than focussing on the mechanics—and semantics—of aspect-oriented software development methods, we should really focus on the semantics of separation of concerns. What is it that we are trying to separate, and which concerns are even separable, before we worry about how to compose the artifacts that address them. We propose a conceptual framework based on a transformational view of software development. In particular, we distinguish between essential separability and inseparability, which characterize requirements, from accidental separability and inseparability, which characterize the realizations of those requirements.

The tourism products involves a combination of speciliazed products such as air travel, lodging, car rental, etc. The Internet has revolutionatized the way customers shop for the tourism products, but has not significantly changed the way the industry players interact to buld or offer such products. We need to rethink the portal system whereby the portal operator acts as a broker between customers and individual product suppliers, and allow for a more peer-to-peer model wherweby different suppliers can collaborate to offer a combined product to consumers. We recognize that two levels of integration are required: 1) message-level integration, to enable business partners to understand each other's messages (Ashari et al.,2001; Leewattanakit et al., 2001); and 2) business process integration, to enable complex business to business transactions, the kind that would be needed for negociations and joint product offering. We propose an open and flexible architecture that relies on: 1) the XML-based Open Travel Alliance messaging standard (OTA, 2003), and 2) semantic matching of process descriptions witten in BPEL4WS (Andrews et al., 2003).

Enterprise frameworks are a special class of application frameworks. They are distinguished from other application frameworks in terms of scale and focus. In terms of focus, application frameworks typically cover one particular aspect of an application, either a domain dependent aspect (e.g., billing in a web-based customer-to-business ordering system), or a computational infrastructure aspect such as distribution,manmachine interface, or persistence, etc. Generally, an application framework alone delivers no useful enduser function. With infrastructure frameworks, we still have to plug in domain functionalities, while with domain frameworks, we need to set-up the infrastructure. In contrast, enterprise frameworks embody a reference architecture for an entire application, covering both the infrastructure aspects of the application, and much of the domain-specific functionality. Instantiating an enterprise framework is nothing short of application engineering, where the architecture and many of the components are reusable.While creativity and continual improvement may be the major ingredients for building a good application framework, anything related to enterprise frameworks, be it building, documenting, or instantiating them, is complex and requires careful design and planning. In this paper, we identify the issues involved in building, using, and maintaining enterprise frameworks, both from research and practical perspective.

The separation of concerns, as a conceptual tool, enables us to manage the complexity of the software systems that we develop. A number of approaches have been proposed that aim at modularizing software around the natural boundaries of the various concerns, including subject-oriented programming (SOP) [Harrison & Ossher, 1993] aspect-oriented programming (AOP) [Kiczales et al., 1997], and our own view-oriented programming (VOP) [Mili et al., 1999]. Both SOP and AOP support compile-time composition. A major advantage of VOP is run-time behavioral composition, which comes at the expense of a cumbersome dispatching mechanism. The same applications that warrant the kind of separation supported by these techniques tend also to be distributed whereby different client sites see different compositions of aspects, simultaneously. The level of indirection provided by distribution middleware simplifies the programming model, and reduces the overhead of VOP.