Details
SOM is a comprehensive methodology for modeling business systems. The acronym means Semantic Object Model, expressing that the SOM methodology is both fully object-oriented and designed to capture business semantics explicitly. The SOM methodology is based on concepts of systems theory.
SOM supports the core phases of business engineering, such as analysis, design, and redesign of a business system. A business system is an open, goal-oriented, socio-technical system. Thus the analysis of a business system focuses on the interaction with its environment, goal pursuing business processes, and resources. Moreover, the dynamic behavior of a business system requires analysis of properties such as stability, flexibility, and complexity.
The backbone of the SOM methodology is an enterprise architecture using different perspectives on a business system via a set of models (fig. 1). These models are grouped into three model layers referring to a business plan, business process models and resource models. Each layer describes the business system as a whole, but with respect to a specific perspective on the model. In order to reduce complexity, each model layer is subdivided into several views, each focusing on specific aspects of a model layer.
Fig. 1: Enterprise Architecture of SOM
Example: Business Process "Distribution"
To give an example, figure 2 (left) introduces the business process distribution of a trading company. At the initial level, the interaction schema consists of three components, (1) the business object distributor which provides a service, (2) the transaction service which delivers the service to the customer, and (3) the business object customer itself. Distributor is an internal object belonging to the universe of discourse while customer is an external object belonging to the environment. At this level the entire cooperation and coordination between the two business objects is specified by the transaction service.
Figure 6 (right) shows the corresponding sequence of tasks which is very simple. The task names in the task-event schema are derived from the name of the transaction. Here, the task service> (say „send service“) of distributor produces and delivers the service, the task >service (say „receive service“) of customer receives it. The arrow service here defines the sequence of the two tasks belonging to the transaction service which is represented in the interaction schema by an arrow, too.
Fig. 2: Interaction schema (left) and task-event schema (right) of business process distribution (1st level)
Transactions like service connect business objects inside the universe of discourse and link business objects to the environment. When modeling a value chain the business process model of a trading company includes a second business process procurement, which receives services from a business object supplier, belonging to the environment, and delivers services to distributor.
Fig. 3: Interaction schema (left) and task-event schema (right) after one transaction decomposition (2nd level)
The example (fig. 2) will be continued now. As customer and distributor negotiate about the delivery of a service, the service transaction is decomposed according to the negotiation principle into the sub-transactions i: price list (initiating), c: order (contracting), and e: service (enforcing transaction). The corresponding task-event schema is determined implicitly because the sub-transactions are executed in sequence (fig. 3). The tasks of each business object are connected by object-internal events.
