Software engineering concerns methods and techniques to develop large software systems. The engineering metaphor is used to emphasize a systematic ap… - Hans van Vliet

Almost 2000 years ago, the Roman architect Vitruvius recorded what makes a design good: durability (firmitas), utility (utilitas), and charm (venustas). These quality requirements still hold, for buildings as well as software systems. A well-designed system is easy to implement, is understandable and reliable, and allows for smooth evolution. Badly-designed systems may work at first, but they are hard to maintain, difficult to test, and unreliable.

Present-day applications are rather different in many respects. Present-day programs are often very large and are being developed by teams that collaborate over periods spanning several years. These teams may be scattered across the globe. The programmers are not the future users of the system they develop and they have no expert knowledge of the application area in question. The problems that are being tackled increasingly concern everyday life: automatic bank tellers, airline reservation, salary administration, electronic commerce, automotive systems, etc. Putting a man on the moon was not conceivable without computers.

Innovative e-business projects start with a design of the e-business model. We often encounter the view, in research as well as industry practice, that an e-business model is similar to a business process model, and so can be specified using UML activity diagrams or Petri nets. In this paper, we explain why this is a misunderstanding. The root cause is that a business model is not about process but about value exchanged between actors. Failure to make this separation of concerns leads to poor business decision-making and inadequate business requirements.