=Paper=
{{Paper
|id=None
|storemode=property
|title=
Determining the Role of Enterprise Modeling for Respecting Regulations
|pdfUrl=https://ceur-ws.org/Vol-933/pap10.pdf
|volume=Vol-933
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/BusinskaKPBR12
}}
==
Determining the Role of Enterprise Modeling for Respecting Regulations
==
https://ceur-ws.org/Vol-933/pap10.pdf
Enterprise Modeling for Respecting Regulations
Ligita Businska, Marite Kirikova, Ludmila Penicina, Ilze Buksa, Peteris Rudzajs
Institute of Applied Computer Systems, Riga Technical University, 1 Kalku, Riga,
LV-1658, Latvia
{ligita.businska, marite.kirikova, ludmila.penicina, ilze.buksa, peteris.rudzajs}@rtu.lv
Abstract. The paper reports on experience in creating an enterprise model
compliant with the Latvian Accounting Law. The focus is on a possibility to
represent parts of the law in the form of business processes. The issues that the
law considers together with the information on processes are organized in
related sub-models. The main elements of the enterprise model sufficient for
representing issues prescribed by the regulations are presented and discussed.
The suitability of the de facto business process modeling standard BPMN 2.0
for representing regulations is examined.
Keywords: business process, compliance, BPMN, enterprise modeling
1 Introduction
Different types of regulations [1] are to be taken into consideration when organizing
enterprise business processes. At a high level of abstraction regulations can be divided
into the following categories [2]: mandatory regulations, which are issued by
governing bodies; “good to have” non-mandatory regulations such as various industry
standards; and internal regulations, which are chosen by an enterprise to be followed
in its performance. From the enterprise point of view, the first two types of
regulations are regarded as external regulations. Internal regulation may depend on
(or mirror) external regulations as well as they may be independent.
In the scope of this paper we are examining and analyzing only external
regulations that are mandatory for enterprises. The purpose of the research is to
represent the law as parts of business process model that can be used by enterprises in
designing and managing their business processes [2]. Using the law mirroring parts of
business process models would prevent enterprises from multiple efforts of translating
regulations into business processes. It is also necessary to maintain the business
process linkage to the specific structural parts of the regulation to ensure regulation
change monitoring and thus facilitate up-to-date business process compliance with the
regulations.
The goal of the paper is to contribute towards the enterprise modeling method that
would provide enterprises with business process patterns, which precisely and
completely conform with valid external (issued outside the enterprise) regulations.
For achieving this goal we have analyzed the relevance of currently popular process
modeling language - Business Process Model and Notation (BPMN) – for modeling
of external regulations. BPMN is the standard for representing in a very expressive
graphical way the processes occurring in virtually every kind of organization [5].
Moreover, it is the de facto business process modeling standard [5] and currently is
implemented by more than 70 applications [3]. According to [4] BPMN is a plenty
construct-rich process modeling language that could be successfully adopted for
modeling of procedural aspects of regulations. In the scope of this paper we attempt
to verify how BPMN 2.0 language constructs overlap the core elements of regulations
based on the developed meta-model of regulations. The comparison is empirically
approved by the case study creating an enterprise model process patterns for the
Latvian Accounting Law. Based on the obtained results, we can conclude that BPMN
2.0 cannot fully support modeling of regulations, because of its limitation concerning
structural modeling. For modeling of regulations in full extent, it is necessary to
represent not only the procedural nature of regulations, but also the constraints on
data content, organizational structure, information systems functionality, etc.
In this paper we envision a solution which is based on the set of inter-related
models each focusing on a specific aspect of regulations: processes, data,
organizational structure, events, information systems, and rules. A collection of these
models is sufficiently complete to describe the regulations in useful way. Proposed
approach is similar to enterprise architecture modeling approaches, as it also captures
the structure and dynamics of an enterprise as collection of multi-level and inter-
related artifacts, i.e., diagrams, documents, and models [6]. We provide the
comparison of proposed approach with enterprise modeling method EKD (Enterprise
Knowledge Development) [7] that is a representative of the Scandinavian strand of
enterprise modeling methods. We have found considerable similarities between EKD
and our approach; hence this enterprise modeling method has been selected for
comparative evaluation.
The remainder of the paper is organized as follows. In Section 2 related work is
outlined. In Section 3 core elements of the regulations are presented and compared to
meta-model of BPMN 2.0. In Section 4 the empirically faced limitations of BPMN
2.0 are illustrated. Section 5 contains the enterprise model proposed for regulations
modeling and its comparison to the enterprise model used in well-known EKD
method. Brief conclusions are presented in Section 6.
2 Outline of Related Works
In [9] authors provide a high-level architecture of the document analysis and change
detection system which is used for the retrieval of regulations and document analysis
and preparation for their linkage to business processes. Another related field is legal
informatics which addresses the linkage between business process models and legal
documents in order to create traceable law models [10]. The Legal Knowledge
Interchange Format (LKIF) is a semantic web based language for representing legal
knowledge in order to support modeling of legal domains and to facilitate interchange
between legal knowledge based systems [11].
The more recent approaches towards achieving compliance strive to provide some
level of automation through automated detection. For instance, in [12] proposed an
approach that has a preventative focus. At first, the approach allows a formal
representation of control objectives in formal language for representation of
compliance requirements (using FCL-Formal Contract Language). Then, control tags
should be defined from FLC expressions, and used to visually annotate and analyze
typical graph based process models. However, it remains unclear, how to linkage
process model with the source of controls to be able to detect changes in controls
timely. As well as, the effect of controls is analyzed only form the process
perspective, leaving other aspects of enterprise (e.g., data model, organizational
model, information systems model, events model) unattended.
ArchiMate standard [13] provides a graphical language for the representation of
enterprise architectures. However, the current ArchiMate 2.0 specification does not
address business policies and rules concepts modeling. Very often business rules and
policies are based on legislation and regulations. Because of this limitation to address
business rules and policies ArchiMate 2.0 is not used as a basis in this research.
In this paper we focus only on the regulation based view on the enterprise, i.e., we
examine what enterprise architecture (model) and what capabilities of business
process modeling language are needed if we represent the regulation in a form of
enterprise/business process models.
3 Core Elements of Regulations
In [1] regulations are defined as directives published by a legislature. Compliance of
business process models to these directives is mandatory. In this paper we use softer
interpretation of term “regulation”. We consider regulation as a directive or guidelines
that are mandatory for or chosen to be followed by an enterprise. This complies with
the definition of a regulation given in [8]. The certain part of regulation may be
related to the particular business process model part that represents the regulation in
terms of business processes. For process modeling the candidate is BPMN 2.0
modeling language as it was recognized the most appropriate for compliance
modeling [4]. Visualizing the content of regulations, we may obtain the business
process patterns that may be made publicly available for the enterprises. It is
necessary to provide mappings between core elements of regulations and
corresponding elements of process modeling language to have a linkage between the
regulations and their visualization. For this purpose we provide the meta-model of
core elements of regulations (see Figure 1). The core elements of regulations were
obtained empirically from modeling the Latvian Accounting Law [13] and are built to
conform to Bunge, Wand and Weber ontology [14] concepts that define the things to
consider when developing information systems. The developed meta-model of
regulations is compared with simplified BPMN 2.0 meta-model (see Figure 2) which
is based on the standard specification of BPMN 2.0 [3]. Simplified BPMN 2.0 meta-
model consists of only those elements that could be useful for representation of
regulations. The results of comparison are summarized in Table 1. They reveal that
BPMN 2.0 has several limitations if considered as a business process modeling
language for modeling regulations. Some empirical illustrations of these limitations
are provided in the next section.
Fig.1. Meta-model of core elements of regulations
Table 1. Comparison of core elements of regulations with BPMN 2.0
Regulation Description BPMN elements
elements
Processes The sequence of activities Activity, Control Flow, Gateway
required to be performed to
comply with the law
Events Something that happens at a Events (is not possible to specify user-
given place and time defined events)
Schedule Dates and times at which things Not supported (does not show the
are required to occur events ordered according time axis)
Actors Roles that are required to take Pool, Lane (does not allow to model
part in specific processes inter-relationships between actors, and
their authorities and permissions)
Organizational Organizational entities that are Pools, Lanes (does not allow to model
structure required to take part in specific inter-relationships between organiza-
processes tional entities)
Data Collections of facts processed Data Object, Message (does not allow
during activities as inputs or to model inter-relationships between
outputs data objects and attributes of objects)
Data stores Registries for storing and Data Store (does not allow to model the
accessing data content of data store, data visibility and
access permissions)
Information Software applications that assist Pool, Lane (does not allow to model the
systems a human performer to carry out functionality of information systems
an activity and inter-relationships between them)
Rules Definitions, operations,Business Rule Task (is not possible to
constraints and statements that show the internal structure of regulation
resolve either true or false and links with other regulations)
Locations Geographical and spatial
Not supported
locations of the enterprise, data
stores, and information systems
References to References to linked and derived Not supported
other regulations regulations
Fig.2. BPMN 2.0 simplified meta-model
4 Limitations of BPMN 2.0
Limitations of BPMN 2.0 detected in the previous section were verified empirically
by carrying out the controlled experiment in the project where the Latvian Accounting
Law [15] was modeled. The following BPMN 2.0 limitations were identified:
1) BPMN 2.0 does not support data structure modeling apart from process model.
In the context of regulation modeling, thus it is not possible to specify constrains
on the content, visibility, and access permissions of data objects. For example, in
Figure 3 the fragment of governmental regulations that sets the inventory
procedure is shown. In the business process model the sequence of inventory
activities is represented, but constrains on the content of the source documents
are not supported (see Rule 1).
Fig.3. Missing regulations on data structure
Regulations prescribe permissions, authority, obligations, and competencies of actors
that perform the activities. Currently the inclusion of organizational perspective in
BPMN 2.0 is limited, i.e., actors and organizational units could be modeled in pools
and lines without additional information. For example (see Figure 4) Rule 2 specifies
the generalization of class “head of the company”, including all possible sub-classes.
And Rule 3 defines the responsibilities of the role “Head of the Company”. This
information is not included in the model.
Fig.4. Missing regulations on organizational structure
2) BPMN 2.0 provides modeling primitives for standard event types, e.g. Message,
Signal, Start, and End, but this is not enough in the case of regulation
documentation. The main mission of offered event types is modeling of executed
processes. However, it should be possible to specify user-defined pre- and post-
conditions, in order to force the analyst to model the activities as lawful
sequence of events and state changes of the data objects. For example, see Rule
4 in the Figure 5 where the first activity of accounting process may start only if
certain pre-conditions are fulfilled. There are two possibilities how to model
this regulation with BPMN 2.0 language.
• We can use Parallel Multiple Event object that indicates multiple ways of
triggering the process or activity [3] as it is shown in the Figure 5. It means
that multiple activities or events are enabled in parallel, and have the
potential to occur at the same time. This could be appropriate language
construct for modeling pre-condition, but unfortunately this may lead to
misunderstandings. Event objects denote starting point of activity execution,
i.e., when activity should be started. But we should model just pre-conditions
of activity not the triggering conditions.
• The language construct appropriate for modeling pre- and post-conditions is
Parallel Event-Based Gateway, where the occurrence of all subsequent
events starts a new process instance. But this language construct is used to
denote several inclusive or exclusive paths of process execution. That means
it is not possible to model conditions that should be fulfilled in parallel.
Other limitation is that Event-Based Gateways are configured by having
outgoing Sequence Flows target an Intermediate Event or a Receive Task in
any combination [3].
Fig.5. Using Parallel Multiple Event object for modeling regulations on pre-conditions
3) BPMN 2.0 does not allow to model constrains on information systems, registers,
warehouses and their geographical location in full extant. Using Data Store
object it is possible to model information that is retrieved or updated in the data
stores (see Figure 6), but modeling constructs that could be used for inclusion of
information systems (software applications) in process model are missed. In
addition it is not possible to represent the content of data store that is prescribed
by the regulations. For instance (see Figure 6), Rule 5 specifies how long the
documents in archives should be saved, while Rule 6 constrains the language
that should be used in the registers. As well it is not possible to represent the
mandatory functions of software application that should be used to perform
certain activity or general set of functions that should mandatory provide the
software application. For instance, Rule 7 specifies that the accounting software
program must provide certain functionality and data formats (see Figure 7).
Fig.6. Missing regulations on data bases
Fig.7. Missing regulations on information systems
4) Regulations describe dates and times at which things are required to occur, thus
modeling language should provide representation of the time/dates. BPMN 2.0
includes special type of event Timer that could be used for this purpose, but, in
addition, it may be preferable to obtain separate diagram with events ordered
according time axis similar to Gantt chart. For example (see Figure 8), Rule 7
constrains the starting data of accounting period, but Rule 8 specifies the lawful
duration of this period.
Fig.8. Missing regulations on time/dates
5) Ordinary the process model expresses actions that should be carried out, but on
the other hand regulations may describe illegal actions that are not allowed to
perform. None of process modeling languages (including BPMN 2.0) directly
provides such a possibility.
5 Inter-related enterprise models for capturing of regulations
In this section we describe the proposed architecture (enterprise model) for
regulations modeling. For complete and precise modeling of regulations it should be
provided the parallel development of several sub-models using inter-model links.
The ability to trace fulfillment of regulations throughout the enterprise is dependent
on the use and understanding of these inter-model relationships. Each of these sub-
models emphasizes the certain aspect of the regulations according to the particular
enterprise architecture artifacts. We distinguish the six sub-models:
• Regulations Model that defines and maintains explicitly formulated rules,
consistent with the source documents such us governmental law and
corresponding to them regulations. On the one hand, this model helps to deal
with conceptual linkages within one regulation and across several
regulations, as well as with their legal hierarchy. On the other hand, it
clarifies the linkages between the organization’s structure, performed
business processes, used information systems, and processed data artifacts;
• Business Process Model that defines enterprise processes that are
constrained by regulations, the way they interact and the way they handle
information as well as material. Business Process Model clarifies, which
activities the organization should perform to manage the organization in
compliance with regulations;
• Organizational Model that describes how different actors and organizational
units should be related to each other and what permissions and obligations
they have corresponding to the regulations;
• Data Model is used to strictly define the "things" and "phenomena"
described in the regulations. Data Model represents enterprise concepts,
attributes, and relationships as well as what rules and constraints that monitor
these objects and concepts;
• Information Systems Model where attention is focused on the technical
systems that are needed to support the business processes of the enterprise.
This model clarifies questions, such as: what are constrains on the
information system to be used, which functionality information system
should perform, with what other systems it should be integrated, what data
formats are mandatory, etc.;
• Events Model that provides a convenient way to explicate time relationships
between people, places and actions, i.e., Event Model defines events ordered
according time axis, activities triggered by events, geographical location and
involved actors.
The modeling elements of the sub-models are related between themselves within a
sub-model (intra-model relationships), as well as with components of other sub-
models (inter-model relationships). Figure 9 shows inter-model relationships. The
ability to trace regulations throughout the enterprise is dependent on the use and
understanding of these relationships. The central role plays two sub-models, namely,
Regulations Model and Business Process Model. All other sub-models are associated
with these two models. For instance, the structural relationships between performers
of activities in Process Model are clearly defined in Organizational Model. In the
same way, temporal and spatial relationships between events and activities in Process
Model are particularly specified in Events Model. In addition each sub-model have
links with Regulations Model to clarify which parts of the regulation correspond to
which part of the business process, data, organization, information systems or events.
Links between the sub-models make the model traceable.
To manage rules which are included in Regulations Model and still keep the
linkage to their original source, one more link (external relationship) is required.
External regulations issued by the government usually are available in the web pages
of the governmental institutions. There are also web portals providing search
facilities of the regulations by such criteria as issuer, type, subject, free text search
and other criteria. Therefore we propose solution that has been developed in our
previous researches [9]. The main idea is to identify and annotate document
structural elements that could be referenced with external relationship by element of
Regulations Model using direct URL’s (see dashed line in Figure 9). Thus we gain
the ability to reference specific part of the document (title, chapter, section, article,
sub-article), that should be directly applied when implementing business process.
This link between the rules of Regulations Model and their original source is
captured by the elements in other sub-models via inter-model relationships (see bold
lines in Figure 9).
Fig.9. Regulation modeling using the inter-related models
The proposed approach is verified according the enterprise modeling method – EKD
[16], that is Scandinavian strand of enterprise modeling methods. Figure 10 on the
right (see B) represents the EKD sub-models with their inter-relationships, and on the
left – the proposed sub-models with appropriate links.
There are obvious similarities between Data Model and Organizational Model of
proposed approach and corresponding models in EKD (Concepts Model and Actors
and Resource Model). These models have the same focus and modeling primitives
for representation of structural relationships between elements (e.g., generalization,
composition, specialization). Moreover, the meaning of Business Process Model in
EKD is very close to the model proposed in our approach. Differences are related to
the syntaxes and quantity of used modeling primitives, because BPMN provides
more expressive notation than EKD Business Process Model. Information System
Model in our approach differs from the Technical Component & Requirements
Model in EKD as in our case this model specifies constrains on the functionality of
information systems, but in EKD it specifies the needs (requirements) of information
systems. We have proposed the new model, namely Event Model, instead of Goal
Model in EKD. This model portraits constrains on the events and timing.
Relationships between sub-models are different, too; because in our approach the
emphasis is on structural and behavioral aspects of regulations, where the most
important are Process Model and Regulations Model. In EKD there are more inter-
model relationships, as the main purpose is to capture as much knowledge about
enterprise as possible.
Fig.10. Comparison to the enterprise model used in EKD: A. inter-related set of proposed
models for modeling of regulation; B: EKD inter-related models [7].
6 Conclusions
The paper reports on enterprise modeling experiment that is based on representation
of regulations as reusable business process model parts. The experiment showed that
for proper positioning of the parts it is necessary to represent in models not only the
process per se, but also other related information available in regulations. The paper
proposes the enterprise model suitable for modeling regulation. The comparison of
this model to a well known enterprise model helps to see that the enterprise model has
to include an events model as one of its sub-models for regulations modeling
purposes.
The paper contributes with clearly described and illustrated limitations of BPMN
2.0 in its applicability for regulations modeling. It is a matter of future research to
overcome these limitations, since due its popularity the BPMN is still the main
candidate for modeling regulations in situations where models are developed for
public use.
The research experiment described in this paper is limited to one law and its related
regulations only. Further experiments with other regulations may reveal some new
requirements for enterprise and process models. The general aim of the research is to
provide reusable business process model parts (that mirror regulations) in cloud [2] in
order to enable easier enterprise business process compliance to regulations.
Acknowledgment
The research presented in this paper is partly supported by Ltd “Komerccentrs DATI
grupa”, Latvia in terms of joint research project, contract No. 5/7-2012. This work has
been supported by the European Social Fund within the project «Support for the
implementation of doctoral studies at Riga Technical University».
References
1. Basel Committee on Banking Supervision, Basel II Accord,
http://www.bis.org/publ/bcbsca.htm
2. Kirikova, M., Buksa, I., Penicina, L.: Raw Materials for Business Processes in Cloud. In:
Bider, I., et al. (eds.) Enterprise, Business-Process and Information Systems Modeling,
LNBIP 133, pp. 241-254, Springer-Verlag, Berlin, Heidelberg (2012)
3. Object Management Group, “Business Process Model and Notation”, www.bpmn.org
4. Muehlen Z., Indulska, M., Kamp, G..: Business Process and Business Rule Modeling
Languages for Compliance Management: A Representational Analysis. In: 26th
International Conference on Conceptual Modeling, pp. 127-132 (2007)
5. Chinosi, M., Trombetta, A.: BPMN: An introduction to the standard. In: Computer
Standards & Interfaces 34, Elsevier, pp. 124-134 (2012)
6. Lankhorst, M, van Drunen, H.: Enterprise Architecture Development and Modelling -
www.via-nova-architectura.org
7. Stirna, J., Persson, A. and Sandkuhl, K.: Participative Enterprise Modeling: Experiences
and Recommendations. In: Krogstie, J., Opdahl, A., and Sindre, G. (eds.) CAiSE’07,
LNCS 4495, pp. 546-560, Trondheim, Norway (2007)
8. Kharbili, M.E.: Business process regulatory compliance management solution
frameworks: a comparative evaluation. Accepted for the Eight Asia-Pacific Conference
on Conceptual Modelling (APCCM 2012) (2012)
9. Rudzajs, P., Buksa, I.: Business Process and Regulations: Approach to Linkage and
Change Management. In: 10th International Conference on Perspectives in Business
Informatics Research, pp 96-109 (2011)
10. Ciaghi, A., Weldemariam, K., Villafiorita, A.: Law Modeling with Ontological Support
and BPMN: a Case Study. In: Second International Conference on Technical and Legal
Aspects of the e-Society (CYBERLAWS 2011), IARIA (2011)
11. Legal Knowledge Interchange Format, http://www.estrellaproject.org
12. Sadiq, S., Governatori, G., and Namiri, K.: Modeling control objectives for business
process compliance. In: Alonso, G., Dadam, ., and Rosemann, M. (eds.). 5th international
conference on Business process management (BPM'07), pp. 149-164, Springer-Verlag,
Berlin, Heidelberg (2007)
13. The Open Group, ArchiMate 2.0 Specification, https://www2 .opengroup.org/ogsys/jsp/
publications /PublicationDetails.jsp?catalogno= c118
14. Gehlert, A., Pfeiffer, D., Becker, J.: The BWW-Model as Method Engineering Theory.
In: Proceedings of the 13th Americas Conference on Information Systems (AMCIS
2007). Keystone, CO, USA (2007)
15. Latvian Law on Accounting, http://www.likumi.lv/doc.php?id=66460
16. Stirna, J., Personn, A.: Ten Years Plus with EKD: Reflections from Using an Enterprise
Modeling Method in Practice. In: Pernici, B., Gulla, J. A. (eds.) Proceedings of the
Eleventh International Workshop on Exploring Modeling Methods in Systems Analysis
and Design (EMMSAD’07), pp. 99-108, Trondheim, Norway (2007)