Would you like to send a flower to your loved ones in a distant city? Or would you like to buy airline tickets and fly to them? Or perhaps you would like to make long-distance calls for almost free? Or you could buy a laptop cheaply and send email messages. Using e-commerce, you can do these things whenever you want and wherever you might be, directly from the seller or indirectly through an auction site or through an agent. It may be more than just for personal matters, for example, your company's order for motorcycle parts from suppliers, for their assembly and for the supply of the finished motorcylces to distributors. Your company could use even some of the data-warehousing e-commerce services before making important decisions as well as buying/selling object brokerage services and smart agent services. E-commerce can be just about anything in just about any shape, B2C (Business to Consumer), B2B (Business to Business), C2C (Consumer to Consumer), B2G (Business to Government), G2B, O2O (Organization to Organization), A2A (Any to Any), etc. Whatever it may be, electronic commerce is expected to play a critical role in our daily lives, just about anytime, anywhere, for anything and anyone, and through any device (desktop, laptop, palmtop, wired, wireless, web appliance, webTV, PDA, PCS, etc.) if not already. Or are all these just as much of a hype as with computers, PCs/NCs, laptops, mobile phones, Internet, satellite communications, wearable computers, etc.?

But why electronic commerce if at all?
Perhaps because an e-commerce system is expected to make buying and selling done in a better, cheaper, faster and happier manner. Not just of conventional goods and services but of just about any types such as informational, or computational, object brokerage services.
If so, what is it that an e-commerce system should offer? Is there a systematic way to find out the "what"?
Once the "what" has been found, can the needed e-commerce system be built over-night? Perhaps or perhaps not, depending on the size, complexity and quality characteristics of the system. Typically an integrated e-commerce system will be too complex for that to happen --- not only can there be an enormous number of system components but also (chains of) complex dependencies among the components.

Just like in an ordinary commerce system, even a small e-commerce system may have to do with a variety of tasks. To start with, it should help with accurate registration of customers, here possibly both on-line and off-line, and fault-tolerant maintenance of customer information. The system should also be able to compile, maintain and display an easily customizable catalogue of goods and services, some of which might originate from several different suppliers, possibly all of these to be done dynamically in real-time. The system should also allow for flexible recording and processing of orders and for informative display of their status later on, as well as correct acquisition of the terms and methods of payment and approval of sales (perhaps involving fast verification of credit card information). Also, secure transmission of invoices, possibly together with periodic reports (internal and external), may need to be associated with fast shipments of goods and services. From the e-commerce organization's point of view, it would also be important for the system to offer facilities for Keeping track of inventories and maintaining cost-effective levels of inventory, in relation to the changing circumstances of its suppliers. Towards a more customer-centric system, the system may need to record transaction histories, monitor customer behavior, summarize statistics, and help with management's strategic decision-making processes. It may also be desirable for the system to possess the capability for proactive attraction and retention of (chains of direct, indirect and potential) customers. for example through timely and automatic dissemination of e-fliers and greeting cards. Handling returns, repairs, and customer complaints may also need to be part of the system as well. Of course, few of these tasks can stand in isolation; but rather, they are related to one another to make them so much more powerful.

An e-commerce system may also need to determine which activities can be done routinely (and automatically) and, if necessary, offering human assistance and negotiation capabilities perhaps through call centers, help desks and field workers. The various tasks may need to be carried out not only by the (geographically distributed) divisions, departments and branches of the particular organization but also by those of other institutions (vertical or horizonal). Some of them might be front-office tasks and accessible by the customer (both the buyer and the vendor in the supply chain), while there might also be back-office tasks internal to the business organization. Of course, one organization's back-end task (e.g., a B2B eProcurement task) may very well be another organization's front-office task if the task is visiblly linked as part of e-business to the tasks of another organization; or it can be a purely internal task (e.g., internal accounting and auditing) or linked to external tasks invisiblly or with tightly controlled visibility (e.g., sending shipping instructions through the traditional EDI or more recent middleware).
In an e-commerce system, then, we would have many different (types of) agents/actors carrying our a wide variety of tasks which may be directly related to the commercial activities of buying and selling or only indirectly as supporting activities (e.g., human resource management for running interactive call centers, accounting for payments and reimbursements, marketing for promotion of new products, etc.). In other words, an e-commerce system would have a network of agents and their commercial tasks linked together via the ever-expanding wired- and wireless- Internet, as a manifestation of the so-called "Internet empowerment".

Due to the many different types of needs and wants, there can be many issues in building an e-commerce system, be they organizational, managerial or technological. What are they?
On the technology side alone, there can be as many issues as there are aspects of an e-commerce system, ranging from internet infrastructures to end-user applications, fancy system-user communication devices, real-time streaming audio and video, and personal software agents, etc. There are many variations to all these technologies: use of webpages, use of multimedia, thin vs. thick clients, computation-centric vs. network-centric servers, centralized vs. distributed servers, internal (local hosts) vs. external servers (remote hosts), server-centric vs. storage-centric, corporate intranet vs. extranet vs. public Internet, virtual vs. physical store, dynamic (derived) vs. static store, centralized vs. distributed repository, shared vs. dedicated vs. co-located servers, use of data-/web-warehouses or ASPs (application service providers) or ISPs (integrated service providers - not internet service providers) - fully or only partially for the purpose of backups, single vs. multiple outsourcing, file-oriented vs. database-oriented vs. transaction-oriented servers, independent vs. groupware-oriented servers, use of middlewares, smart cards, voice recognizers, etc.
Hence, mapping the needs and wants of the customers into an e-commerce software system is far from trivial, even when they are reasonably well defined.

The highest-level of abstraction for the solution of an e-commerce system is its architectural description, and there is growing acceptance that we need this level of abstraction to conquer the complexity inherent in just about any system. Whatever architecture an e-commerce system may take, no doubt an e-commerce system will be only as good, or as bad, as its components and interactions between the components. Hence various questions: what should be the components?, what should they do individually and collectively?, when should they do it?, who need to communicate?, what needs to be communicated?, how many resources should flow at a time and how should they flow - point-to-point vs. selective broadcating vs. broadcasting, synchronous vs. asynchronous, upon explicit request vs. (partially or fully) event-driven, addition of event announcers vs. addition of event users?, etc. Furthermore, some of the components might be in-house developed, outsourced through ASPs (application service providers), etc.
Of course, all these things will have to be carefully chosen, tailerd and integrated in relation to the goals and tasks of the agents participating in e-commerce, more specifically in relation to the knowlege they possess and the reasoning they carry out to perform the tasks towards achieving their goals.
So, there goes a plethora of concepts and techniques, along with a long list of tasks to support, many different types of tasks to suppot, many ways to allocate the tasks, many different ways to realize the allocations, many design steps to go through to realize the particular allocations, hence many decisions to make, some highly critical and some less breathtaking.
And the question is how to build a survivable and successful e-commerce system - a task which can be as complex as it is challenging.

One vital premise of just about any e-commerce system is that it will make the buyers and sellers feel better, cost-effective, faster and happier about the various buying and selling activities (which we will call "non-functional"). Any such system will of course need to offer at least the same, or even more, functionality for the goods and services that the business organization has been offering (which we will call "functional").
For example, one main reason why a supermarket chain is looking to e-commerce might be that they may want to help their customers reduce shopping time and travel time to and from the store. Another reason might be easier comparison of prices. Yet another might be easy access to discount items. Perhaps they want their business becomes more adaptable to the fast changing behavior and needs of their customers. Also how about a virtual reality through e-window shopping in the cozy sofa in your very own sweet home?
Often times, such "non-functional" issues inevitably become the driving force behind the transition into e-commerce, perhaps more so than simply the "functional" features that they offer. Such issues, however, are often implicit, or if stated, only informally, tentatively, inconsistently, and ambiguously


The objective of this project is to provide notations and methods for defining the system architecture of an electronic commerce system (i.e., the structure of the enterprise which comprises of people carrying out the various buying- or selling-related activities, the various hardware/machines used for the activities, and the various software systems deployed including the e-commerce software system to be built), and deriving from the system architecture the architecture of the software system. The software architecture should help the buyers and sellers by supporting the variety of e-commerce activities through maintaining various types of information and automating some of the activities such as e-crm, e-orm, e-procurement, e-erp, etc. In a nutschell, the project's goal is to help build a survivable and successful e-commerce system, namely, human-centered, but not technology-centered, system and software architectures in a systematic manner through the use of the notations and methods.

The methodology to be used and further developed in this project will take a multi-paradigm approach to:

  1. facilitate modeling the system architecture of the e-commerce system and deriving from it a software architecture.

    The system architecture describes the enterprise/environment in which the underlying e-commerce software system is to function. The components of the system architecture include buyers, sellers, brokers, distributors. The components also include the respective goals of the various types of people and business organizations, the various activities - both individual and collaborative - they need to carry out in order to achieve their goals, and the various hardware and software systems, along with any other resources they need in order to carry out the daily activities. The software architecture describes the functional components of the the e-commerce software system and interactions between them.

  2. With the very realization that any e-commerce system should add to the value of the business, distinguish between "non-functional" and "functional" issues. This applies to the system architecture as a whole, hence more specifically to the software architecture as being part of it.
  3. carry out, for both types of architecting, goal-oriented as well as object-oriented modelling and analysis by the use of the NFR-Framework+ for a goal-oriented analysis of non-functional requirements (NFRs) and UML+ for an object-oriented analysis of functional requirements (FRs) - informational, functional and dynamic. A goal-oriented analysis for the consideration of, and selection among, alternatives for refinements, allocation alternatives, and software architectural alternatives:
    1. Simple refinement strategy: For each top-level NFR goal, one type decomposition followed-by one topic decomposition or one topic decomposition followed-by one type decomposition.
    2. Simple allocation strategy:
      1. allocate storage of simple data and calculations to the software system;
      2. allocate real-time reactive behavior to hardware and software systems;
      3. allocate tasks involving a high amount of tacit-knowledge, complex knowledge and reasing to humans;
      4. define interactions among the agents.
    3. Simple software architectural design: for each task, create one processing component; for each type of data cluster, create one data component. For each task dependency, create a corresponding software component link.
  4. be knowledge-based, offering catalogues of (both generic and domain-specific) knowledge about NFRs, FRs, architectures, and relationships among them, and various decision points:
    1. requirements:
      1. NFR-side: methods and correlation rules for both NFR-specific and selection-oriented
      2. FR-side: ontology base, feature based, use-case/scenario based,
    2. Architecture-side:
      1. styles: pipe-&-filter, process control, passive repository, virtual repository, blackboard, whiteboard, OO, layered, homogeneous/heterogeneous,
      2. patterns: sequential, parallel, fan-in, fan-out, ring, star, grid,
      3. components: process, data, control
      4. interactions: none/explicit/implicit, point-to-point/broadcast, uni-/bi-lateral,
      5. constraints:
    3. These catalogues can be seen as the reusable building blocks for domain analysis and software architectural analysis.
    4. be component-based, using objects and (intelligent) software agents as the building blocks of the distributed, collaborative software architecture.


    The analyses in the methodology will help ensure the completeness, consistency, and clarity of NFR, FR and architectural descriptions. These analyses will apply to both within each kind, as well as across different kinds, of descriptions. In particular, the NFR analysis will help prevent fatal mistakes such as

    1. a lopsided emphasis in only one kind of NFRs and ignoring all the other kinds, e.g., "a secure e-commerce system" with no mention of any other.
    2. an unachievable NFR, e.g., "absolute security".
    3. a faulty unanimity assumption, e.g., "evolvability means the same thing to everybody and its meaning is 100% clear".
    4. a reduction in scope, e.g., "adaptability if modifiability"
    5. a non-traceable design, i.e., a design which cannot clearly be related to the NFRs, but only in a "begging-the-question" manner. E.g., what's in the design defines the NFRs.
    6. a faulty optimality claim, e.g., "this design is optimal with respect to the list of NFRs", when the definitions of the NFRs are unclear and the NFRs conflict with each other.

      It is more likely that a solution is a local suboptima. Also it is more likely that a local optima, even when present, is not a global optima. A more appropriate approach to be taken is to explore as many options and choose those that synergistically contribute to multiple NFRs, instead of those that antagonistically contribute to only few NFRs while hurting other NFRs.

    7. an incomplete design which does not address an important NFR, e.g., "reliability" is interpreted to reduce errors in the program when it really meant data accuracy.
    8. an unjustifiable design, e.g., because the NFRs stated are of interest only to developers but not to the customer.
    9. an universiality assumption, i.e., one-solution-fits-all approach when the particular solution considers only one, or few, NFRs and independently of the variability of applications.
    These analyses will be based on the properties of NFRs: dialectical, suboptimal, subjective/relative and interacting. These analyses will lead to satisficing NFRs, i.e., exploring good-enough architectural designs. In the NFR analysis, NFRs will be met in two ways:
    1. i) selection among competing designs that collectively best meet the prioritized NFRs; and
    2. ii) through features of the design that are specific to the particular NFRs. Often mechanisms that prevent, detect and correct the violation of such NFRs. And mechanisms that facilitates the achievement of NFRs. E.g., automatic logout of the user in case of a system crash or prolonged inactivity in order to enhance security, confirmation of data entry in order to enhance accuracy, intuitive graphical menu display (albeit at the cost of performance), automatic alerters in order to enhance responsiveness and timeliness, load distribution (e.g., multiple servers at increased cost) and balancing (e.g., local store of cookies at the expense of increased space requirement) in order to enhance web speed and reliability, supervisors/monitors that keep track of the particular NFR aspect and try to either improve dynamically or report warnings for later improvements.
    The methodology will provide to the system and software architects guidance
  5. interactively throughout the architecting process, i.e., representing and reasoning with the system architecture, the software architecture, and their intra- and inter-dependencies. More specifically, the guidance will involve:

    automatic checking of ambiguities, internal consistency and incompleteness of NFRs:
    based on a set of simple syntactic rules:
    1. missing topic
    2. presence of cycles
    based on a catalogue of typical NFRs in the particular kind of e-commerce systems
    automatic generation of (missing) NFRs from FRs:
    assuming the presence of a top NFR, type [topic], and a FR chunk, relationship (FR1, {FR1i})
    1. {type[FR1i} as descendant of NFR
    2. Given typei[topici] and its descendants {typej[topicj]} and topici, {topicj} and topick, deduce and propose typei[topick] as a low priority NFR.
    automatic generation of (missing) FRs from NFRs:
    assuming the presence of NFRs, {typei [topici]}
    1. {topici}
    automatic generation of parts of candidate architectures
    based on a set of simple syntactic rules:
    1. For each activity Ai in FR, make Ai in top-level component
    based on a catalogue of typical architectures in the particular kind of e-commerce systems
    1. typical style, components, interactions for the functionality
    2. typical NFR-specific components for the non-functionality
    automatic generation of parts of FRs from candidate architectures
    1. For each top-level architectural component, Ci, make Ci in FR
    automatic generation of parts of NFRs from candidate architectures
    1. For each architectural component, Ci, make NFRi [Ci] in NFR, where NFRi in NFR.TYPE
    2. For each architectural interaction, Iij, make NFRi [Iij] in NFR, where NFRi in NFR.TYPE
    3. For each architectural component, Ci, which hurts/breaks NFRi [Cj] in NFR but chosen in the target, where NFRi in NFR.TYPE, introduce/prioritize !NFRi [Ci]


    The e-commerce system architecture will be modelled using:

    1. goals: softgoals and hardgoals
    2. agents: organization, individual, hardware, software
    3. roles: buyer, seller, broker, controller
    4. tasks:
    5. information flows:
    6. rules: generic/domain-specific, static/dynamic, intra-/inter-agent
    7. dependencies: softgoal-contribution, hardgoal-dependency, agent-dependency, task-dependency
    which will be organized along the dimensions of:
    1. classification-instantiation:
    2. aggregation-decomposition:
    3. generalization-specialization:
    4. views:

    The e-commerce software architecture will be modelled using:

    1. components:
    2. connections:
    3. constraints:
    4. rationale:
    5. styles:

    The architecting process will consist of three iterative phases:

    1. pre-system architecting (descriptive): goals, agents, dependencies, information flows, roles, rules
    2. system architecting (prescriptive): task allocation and task-dependency modeling
    3. software architecting:

    Architecting: Let's do it!

    In a free world, that is