Modeling Business

Valdis Vitolins, Audris Kalnins

arXiv (arXiv: 0307039v1)

Generated on April 20, 2025

 Modeling Business

Abstract
Business concepts are studied using a metamodel-based approach, using UML
2.0. The Notation Independent Business concepts metamodel is introduced. The
approach offers a mapping between different business modeling notations which
could be used for bridging BM tools and boosting the MDA approach.

MODELING BUSINESS
Audris Kalnins, Valdis Vitolins
University of Latvia, IMCS, 29 Raina blvd, LV-1459, Riga, Latvia
[email protected], [email protected]
In this article business concepts are studied using a metamodel- based approach. The Notation
Independent Business concepts metamodel is introduced. The approach of fers a mapping
between different
business modeling notations which could be used for bridging BM tool s and boosting the MDA
approach
1 Modeling Problems
An unambiguous and formal method how to describe some probl em has been demanded always.
A model of the
problem is essential for [1]:
investigation and analysis,
unambiguous information exchange between people and computer s ystems,
development of a practical solution, using the problem mode l.
Additionally a model must support measurement and comparison (both for simulation and in real
environment),
and should support version and change management during the mode l life cycle.
To ensure now a successful business, an enterprise must i ntegrate its information systems with
partners and
make the data exchange available. Today not only a simple data exchange but also more
complicated service
exchange is already used (e.g. web services and e-business). Howe ver, the demands are even
higher – the
business should support not only a simple service at a nar row area, but also any service at any
place (e.g.
e-government). In order to build such interoperable proces s definitions a notation independent
process modeling
is of highest value.
Currently many business modeling (BM) languages exist and even more tools, which support th
em. The most
popular ones are ARIS, IDEF3, UML with its Activity Dia gram (AD), GRADE BM (BM) [2].
What refers to
UML, its newest (in-progress) version 2.0 [3] is referen ced in this paper. However, these
languages mainly
support modeling of the business processes themselves, but say nothing or very little about the
business process
environment and semantics. They don’t answer - why th is process is used, how it is linked to
other processes a nd
enterprise demands, how we can control and improve it. C ertainly, some of these languages can
be used as a
framework for modeling the above mentioned higher-level concepts in an indirect way.
The question is – what are general concepts to which we should pay attention to describe all
aspects of an
enterprise, and which is the best way? Our approach to t his question is metamodel based. We
would like to build
a metamodel, which would be:
simple and natural enough to be understood also by non-IT pe ople
comprehensive enough cover all business aspects which a re more or less related to business
processes
detailed enough to serve the goals of system description, analysis and design, as far as business
processes are concerned
serve as a common basis for the most typical BM nota tions and would enable a more or less
automated
concept mapping from one notation (modeling language) to ano ther.
Thus our goal would not be to invent a new BM notation, but to provide more understanding to
the existing ones
and means to harmonize and extend them. Certainly, it i s impossible to cover literally all aspects
of the bus iness
(see a little bit failed attempt of this in [4]), ther efore we will concentrate on what is “around the
proce sses”. It
should be noted that such “platform independent modeling” is completely in line with the MDA
(Model Driven
Architecture) approach, extending the platform independent dev elopment to process modeling
area.
2 Business Metamodels
Business modeling is already a widespread term, however we wish to say that only some views
of business have
been investigated. At this time unambiguous and well-define d models exist only for several
narrow business
areas, but wide and comprehensive models are very inform al and generic. For example, a
business process as a
sequence of activities is well defined in several notat ions, but practically nothing is said about
its environm ent.
J. Zachman is one of the first, who has investigated enterprise level business aspects. His
methodology[5],
developed in 1987. and named Zachman Framework , has gained popularity and has been
implemented in
several modeling tools, including System Architect [6] by Popkin Software. In this framework,
several high- level
business concepts are introduced - goals, strategy and busin ess plan. These terms are used as a
context for
concepts, included in model diagrams. Unfortunately, this f ramework is too informal and
doesn’t show concept
relationships, no metamodeling approach has been used ther e.

As e-business spreads more widely, many models have been developed from this prospective.
Quite an accurate
view was introduced by Andreas Dietzsch [7]. His approach is described by a metamodel – a
class diagram (Fig.
1) therefore it is quite unambiguous. The model shows the b usiness goals and strategy like
Zachman framework,
but it also introduces input-output chain of an enterprise. Some of the model concepts (supplier,
input, business
process, output, customer) have a good correlation with th e ISO/DIS standard[8]. This model
introduces several
types of enterprise processes (management, support, perform ing).
Performing Process Support Process Management Process Input Critical Success Factor
Business Process Output Supplier Customer Process Map Service Strategy Business Goal Index
Value
1..* 1..*
1..* 1..*
1..* 1..*
1..* 1..* Is Consumed Is Provided 1 1..*

Fig.1 Business metamodel by A. Dietzsch

Another view of business is developed within the COMBINE project [9]. In this project the
main concepts of
business were investigated in relation to distributed sys tems (due to space limitations, some
lower level class es
are not displayed in Fig. 2):
Comunity
Role Enabling behaviour Goal
Business
Process
Step Resource Behavioural
Policy
Is fulfilled by
Fulfills 1..* 1..* Is behaviour of
Executes 1..* 1..* to meetmet by 1..*
1..*
Has
Is objective of 1..*
1..*
Is actor for Is performed by1..*
1..* Is member
Has 1..*
1..* Constrains Is constrained
by 1..*
0..*
1..* Subgoals 0..*

Fig.2 Business metamodel from Combine project

In this model resources and their relation to business processes are highlighted quite well. By the
way, in this
model the Community is what others call an Enterprise .
As you can see, the above-mentioned metamodels are quite different, yet a more dissimilar view
on business
concepts is described in [10], where business systems are explored in terms of e-business
requirements. One
more view on Business Processes is presented by Busines s Process Management Initiative
(BPMI) [11], where a
business is modeled in terms of its interfaces and coll aboration. Sure, we could list more models
- detailed or
generic, but the ones mentioned here are enough to show how different the views can be on the
same area.
3 Main business concepts and their relations
When several sources are combined into one model, the main problem is that similar concepts
are named very
differently. Therefore, the first step is the analysi s of semantics of concepts, and harmonization
to one general
concept (e.g., Community and Enterprise ). To support a general business pattern, we choose the
Value Added
Chain approach - a business of an enterprise is described in t erms of input (the enterprise is
supplied with raw
materials or “raw” service), process (add some value to this) and output (deliver it to customer
as a value added
service or a processed material)[12].
To make our metamodel as small as possible we paid attent ion only to these aspects, which play
some role in
business process automation. Such things as competitors or reputation that play big role in
business, but are not
directly related to business processes, are not included. However, we included such “intangible”
thing as
Knowledge , addressing that part of the enterprise knowledge, which i s stored as data, especially
in knowledge
management systems becoming so popular.
Also, we tried to exclude as many abstract classes from the model as possible, because they
damage the model
understandability. For sample, we included real classes Requirement and Conformity , but we
didn’t include
Quality (a conformity to determined requirements). Quality is shown only as a two-way
dependency between
these classes. We made an exclusion regarding to the abst ract class Performer . It was
introduced due to wish to
provide a more general relation to the Task concept.
Fig. 3 presents our current proposal for the business metam odel.
In the presented model, Business Goal means anything (tasks, goals, plans), that is strategic and
for a long term.
Business Goal [8] is split into two parts – Strategy , witch usually is an unstructured information
and Index Value
– a measurable magnitude that is used to measure the progress in strategy implementation.
Resource and its

relation to Enterprise , Input , Output and Business Process is taken from the Value Added
Chain approach. The
Measurement-Refinement and Determination-Satisfaction chains conform to ISO. The
important terms Business
Process and Performer are described in more detail in a separate metamodel fr agment - Fig. 4.

Material
Means of production Business Goal Resource Enterprise
Organisation
Tangible
Knowledge
Know How
Business Process
All activites flowed in
enterprise Task
Atomic activity
InternalCustomer
Output Service
Public Interface Input People Plant
Instruments, cash
Supplier Intangible
Strategy Index Value
Mensurable
Requirement
Processed MaterialRaw MaterialConformity Notation Independent
Business Concepts
Performer
Reference 1..* 1..*
Actor 1..*
1..* Operating 1..* 1..* Objective
1..*
1..*
1..* Staple
1..* 1..*
1..* Actor
1..* 1..*
1..* Production Satisfaction 1..*
1..* 1..* Quality
Determination 1..*
1..* Consumption
1..* 1..*
1..* 1..*
Measurement 1..*
Refinement
0..* Sub
process Measurement 0..*
0..* Best practice 1..*
1..* Realization Subsidiary 0..*
0..*
1..*
1..* Support
1..* 1..*
Utilization 1..*
1..* Nomination 1..*
0..* Supplement Subgoal
0..*

Fig. 3. Business metamodel – the top classes.

As mentioned before, the Performer is an abstract class (reference), which points to r eal
resources (explicitly to
Resource or implicitly through other references - Organizational Unit , Role (a role in a project)
or Qualification .
Task is an atomic business process unit, which actually desc ribes some step or function and is
done by a
Performer . In some notations it is called Action (UML 2.0 Activity diagram), Task (GRADE
BM, BPMN), Unit
of Behavior (IDEF3). Transition determines the sequence in which several Tasks are executed.
Pass is a normal
transition from task to task. Due to differences in not ations (GRADE PM and BPMN
incorporate task triggering
and output branching in the task itself while UML or IDEF 3 does not), separate subclasses –
Incoming and
Outgoing transitions must be introduced. These classes will be explained in detail in the
following section.
Control is singled out as a separate abstract class. It includes Decision (start of control
branching), Fork (start of
concurrent threads), flow unification ( Merge and Join – for concurrent threads) and process
start and stop point s.
BusinessProcess
Join
Fork Merge Start
End Role
Business role, or
privileges Organisational
Unit Service
Internal
Qualification
Implicit reference
through requirements Resource
HW, SW, etc. Notation
Independent
Business
Process
Decomposition
Decision Performer
Reference
Task
Smallest unit of
executable function Transition
Incoming Control
Pass Outgoing Subprocess 0..*
1..* 1..* 1
0..* 1..*
1
0..* 10..1 0..*
0..*
1 0..1 1..*
1..* 1..* 1..* 1..* Actor
0..20..*0..2
1..*

Fig. 4 Business metamodel – details of Business Process

4 Concept mapping in different notations
This section deals with the problem how the metamodel of business concepts can be used to
define a relation
between different business modeling notations. Namely, a mapping between such notations will
be defined. The
approach will be illustrated by defining a mapping between G RADE BM and UML AD
notations (actually a
fragment of it), but it could be extended to other notatio ns as well.
It should be noted that there is no special support for def ining a mapping between two class
diagrams in UML –
a fact acknowledged also in the MDA area. However, when the mapping is at “class level” (i.e.,
an instance of a
class in one diagram is always mapped to an instance of the corresponding class (or instances of
several class es)
in the other diagram) the mapping can be denoted via asso ciations between corresponding
classes (augmented
when necessary by constraints such as XOR). Namely t his is the case in the paper.

Another issue is the graphical presentation of concepts in business modeling by diagram

elements. For example,
the generic solution of this problem in UML 2.0 is positi oned outside the main UML
metamodel. Fortunately,
for business processes (Activity diagrams in UML 2.0) the re exists already a “logical diagram
concept”
(Activity ) in the metamodel, in the result the “UML-internal” mapping from domain concepts to
their graphical
presentation actually is one-one. The situation is sim ilar in most BM notations, including
GRADE.
Therefore it is natural in the BM area to define a ma pping at the domain layer. Namely, we take
the “native”
metamodels of several BM notations (in our case, GRAD E BM and UML AD) and define a pair
of mappings
from their concepts to the concepts in our notation in dependent metamodel. They are shown as
associations
between the corresponding classes of the metamodels. A concept from a particular notation can
be mapped to
one or more concepts in the independent domain (and vice versa). In the result, a derived
mapping (which can be
quite complicated) is obtained between the graphical eleme nts of both notations – namely this
mapping is of
interest for the users of BM notations. Fig . 5 summari zes this approach at meta-metamodel
level, showing the
possible primary and derived associations between two no tations A and B and the independent
metamodel.
Domain
Concept
Layer
Presentation
Layer NotationB NotationA
Notation Independent
BP Domain NotationDependent
BPDomainANotationDependent
BPDomainB
ConceptPresentationB ConceptPresentationANotationIndependent
Concept
Dependsonconceptmapping ConceptBConceptA1..* Is viewof
1..* Actualmappingway
0..* 0..* Presentation
mapping 1..* 1..* ConceptAmapping
1..* 1..* ConceptBmapping 1..* Is viewof
1
0..1 1
0..1

Fig.5 The scheme of metamodel mapping

It should be noted that another approach to notation mappi ng could be used – namely that in the
Exigen Business
Modeler [2]. There one common domain metamodel (the not ation independent one) is mapped
to several
notation dependent graphical layer metamodel fragments. Th is approach is more efficient for
tool building, but
seems to be more limited in power – though GRADE BM and U ML AD have been mapped to
each other, adding
more notations would require significant changes in the “ fine-tuned” domain metamodel.
Unfortunately, the size of the paper does not permit to describe our mappings in detail. Instead,
they will be
explained on an example. A simple business process is display ed in Fig. 6 both as a GRADE
BM and UML
Activity diagram (the letters beside the lines are not part of the notation but annotate the
mapping example).
b
g
haIntegration
Integrator IsNot
Motivated Review
Coordinator
Is
Motivated
Development
OR
Developer
Testing
AND
Tester
IsFixed
IsNot
Fixed Close
OR
Coordinator OR
Tester New problem
appears
(Tester)
Testinga
cdg
e
f(Developer)
Development
(Coordinator or Tester)
Close(Coordinator)
Review
(Integrator)
Integrationb
[Is Fixed]
[Is Not Fixed][Is Motivated] [Is Not Motivated]

Fig.6 A business process as GRADE BM and UML AD

The next Fig. 7 shows part of the defined mapping between t he GRADE metamodel classes and
the independent
domain (the top left area) and the independent domain and a fragment of UML 2.0 metamodel
(top right). The
(not shown) association multiplicities are 0..1 or 1, so me XOR constraints are also shown. Note
that the GR ADE
Task is a very inclusive concept – it includes a triggering condition attribute, and according to
the values of that
attribute ( OR , AND , none ) a task maps to either Merge or Join classes (or none of them) in
the independent
domain. If either of these classes is present the Incoming transition is also included in the
mapping. A similar
situation is for the task exit. It should be noted that t he described conditional mapping can be
described formally
using OCL.

The lower area in Fig. 7 presents the mapping of some of the class instances according to the
example in Fig. 6.
Actually there should be instances also in the middle co lumn, but they are omitted to simplify
the drawing, sinc e
in this fragment the mapping between the notation indepen dent classes and UML is one-one.
The (not shown)
mapping between the notation domains and their presentati ons is also one-one.
(According concepts logical
instances are assumed) UML 2.0 Activity Diagram
domain Grade BP domain Notation independent
domain
Merge
Task
Fork Join
Decision Action Join Node
Task Merge Node
Fork Node
Decision Node
Testing:Action a:Activity Edge
b:Activity Edge
Is Not Fixed:Guard Testing:Task XOR
a:Path
b:Path
d:Activity Edge
e:Activity Edge
g:Activity Edge
Condition = "Is Not Fixed" Activity Edge
XOR XOR
f:Decision Node c:Join Node Guard-In-Path
Guard-Out-Path Guard
Path
g:Guard-In-Path
h:Guard-Out-Path Outgoing Incoming
Pass XOR
Domain Instances Domain
concepts
layer

Fig.7 Mapping definition and example

5 Conclusion
The presented Notation independent business model and the mappings between two BM
notations based on this
metamodel is the first step in the selected direction. The results obtained so far seem to be
promising for bui lding
a comprehensive business modeling framework covering most of the known BM notations and
extending them.
The practical aspect of this approach would be a possibili ty to build a notation independent
repository for several
simultaneously accessing BM tools using different BM nota tions. Each of the tools internally
would “live” upon
its native domain metamodel. Additionally this could boos t the MDA approach by providing
unambiguous
model translations between different modeling notations .

References

1 A. Osterwalder, S. Ben Lagha, Y. Pigneur, An Ontology for Developing e-Business Models,

INFORGE, Encole des
HEC, http://inforge.unil.ch/aosterwa
2 Kalnins, A., Barzdins, J., Celms, E., Lace, L., Opmanis, M., Podnieks, K., Zarins, A.: The
First Step Towards Gene ric
Modelling Tool. Proceedings of Baltic DB&IS 2002, Vol. 2, Ta llinn (2002) 167-180
3 Unified Modeling Language: Superstructure, version 2.0, Object M anagement Group (OMG),
http://www.omg.org/docs/ad/2003-01-02.pdf
4 ESPRIT project ADDE. http://www.fast.de/ADDE
5 The Zachman Institute for Framework Advancement (ZIFA), http: //www.zifa.com
6 System Architect,Tutorial, 2001, Popkin Software, http://www.
popkin.com/products/product_overview.htm
7 Andreas Dietzsch. Adapting the UML to Business Modelling's Ne eds - Experiences in
Situational Metod Engineering,
UML 2002. LNCS 2460, pp 73-83
8 International Standard, ISO/DIS 9001 Quality management systems — Requirements,
International Organization For
Standardization, http://www.iso.com
9 Sandy Tyndale-Biscoe. Business Modelling for Component System s with UML. Proceedings
of the Sixth EDOC
Conference (’02)
10 A. Osterwalder, An e-Business Model Ontology for the Crea tion of New Management
Software Tools and IS
Requirement Engeneering, Ecole des Hec, Université de Lausanne,
http://inforge.unil.ch/aosterwa
11 Business Process Modeling Notation. Working Draft (0.9) Nov ember 13, 2002, Business
Process Management Initiative
(BPMI), http://www.bpmi.org
12 International Standard, ISO/TS 16949 Quality systems - Automoti ve suppliers, International
Organization For
Standardization, http://www.iso.com