Essay:

Essay details:

  • Subject area(s): Engineering
  • Price: Free download
  • Published on: 7th September 2019
  • File format: Text
  • Number of pages: 2

Text preview of this essay:

This page is a preview - download the full version of this essay above.

\chapter{Theoretical background}

\noindent

This chapter provides the background information regarding this research thesis. The main purpose of the literature study conducted for this research was to review the currently existing literature regarding information-centric modeling methods to design and specify case management systems to support knowledge workers. However, the central purpose of this chapter is to analyze the literature regarding the modeling method of choice at Formetis BV based on enterprise ontology called DEMO. The other modeling methods found in the literature are not discussed here as of yet but will be used as comparison in chapter \ref{app:cmt}.\\

\\

\noindent

The literature collection procedure employed is stated in the following paragraph. Section 2.1 discusses the notion of enterprise ontology in more depth. Section 2.2 elaborates the system development process associated with DEMO. Section 2.3 reviews the DEMO modeling method itself. Section 2.4 examines the software engine developed at Formetis BV and the chapter ends with a conclusion in section 2.5.\\

\newpage

\noindent

\textbf{Literature collection procedure}\\

The relevant subject domains for this review, regarding information-centric modeling methods to support knowledge-intensive processes, consist of business process management and information systems. The searches were conducted on all non-full text related fields of peer-reviewed scholarly journals and conference proceedings using the ProQuest online indexer. The literature uses different terminology for information and as such may refer to documents, products, data, entities and so on. All these terms have different meanings depending on the modeling method. Therefore, the more general terms object and activities will be employed in order to remain consistent with the taxonomy used in section 1.3. Furthermore, this classification is similar to the one used by \cite{Reijers2016}. Object life cycle based methods primarily focus on the different states an object in a domain can have and relate activities to these state transitions. Communication-based methods primarily focus on how different actors in a system communicate with each other through speech acts in order to coordinate activities that act upon objects.\\

\\

The main selection procedure for the first iteration of literature collection consisted of a comprehensive set of books and articles regarding the history and applications of the communication-based DEMO method using the key words \emph{DEMO, enterprise ontology, methodology}.\\

\\

The second iteration centered around the history and applications of business artifact based methods, since the associated GSM meta model formed the conceptual basis for the CMMN standard, using the key words \emph{business artifacts, artifacts, methodology}.\\

\\

In addition, other relevant references and related work cited by the authors of the found articles were also extracted and included in the review. Moreover, articles suggested by the thesis supervisors that were not found during earlier searches were also incorporated. This ultimately led to the a selection of books and articles for several information-centric, rather that activity-centric, modeling methods (Table \ref{methods}).\\

\\

\noindent

\FloatBarrier

\begin{table}[!h]

\centering

\caption{Modeling methods}

\label{methods}

\bgroup

\def\arraystretch{1.5}

\begin{tabular}{l}

%\hline

%\textbf{Object-dependency}                                                                                                                                                                                                    %\\ \hline

%Document-driven workflows \cite{Wang2005}                                                                                                                                                                                                          \\

%Product-Based Workflow Design \cite{reijers2003product, vanderfeesten2008product}                                                                                                                                                                   %\\ \hline

\textbf{Object life cycle based modeling}                                                                                                                                                                                                     \\ \hline

Data-Driven Process Structures \cite{muller2007data}                                                                                                                                                                                               \\

Business artifacts \cite{nigam2003business, liu2007modeling, bhattacharya2007artifact, hull2008artifact, bhattacharya2009data,cohn2009business,hull2010introducing, Esta''ol2013}                                                                 \\

Process to data-centric model translation \cite{Eshuis2016}                                                                                                                                                                                        \\ \hline

\textbf{Communication based modeling}                                                                                                                                                                                                         \\ \hline

DEMO \cite{maij2002use, dietz2006enterprise, albani2006identifying, albani2006benefit, op2008applying, barjis2009collaborative, huysmans2010using, op2012benefits, dietz2013discipline, guerreiro2013towards, de2013method, janssen2016enterprise}

\end{tabular}

\egroup

\end{table}

\FloatBarrier

\newpage

\section{Enterprise ontology}

This section reviews the communication based DEMO methodology and the related theory of enterprise ontology, also known as the $\Psi$-theory. The $\Psi$-theory consists of 4 axioms and 1 theorem. The next subsections elaborate the Operation, Transaction, Composition and Distinction axioms and is followed by an explanation of the Organization theorem.

\subsection{Operation axiom}

The first axiom, commonly referred to as the \emph{operation axiom}, simply states that the operation of an enterprise consists of the activities performed by actor roles. Every actor role is therefore assigned with an elementary amount of authority and responsibility regarding the performance of these activities. These actor roles are fulfilled by actors such as human beings. However, some actor roles can also be fulfilled and automated by technology as will be discussed in the section regarding the Organization theorem.

Actors, in their actor roles, are able to perform production activities, or production acts, and are able to communicate with other actor roles regarding these production acts through coordination acts. These acts create definite results in the form of production facts and coordination facts.\\

\\

Production acts, or P-acts, are necessary to bring about the goods and/or services of the enterprise and consist of material or immaterial acts. Material acts are all essentially all activities that require physical labor and the manipulation of physical objects such as the manufacturing, storage and transport of goods. Immaterial acts are for the most part mental activities such as the decision to grant an insurance policy or the judgment by a court to sentence someone \cite{dietz2006enterprise}.\\

\\

Coordination acts, or C-acts, are the communication mechanism through which actors create and adhere to commitments towards each other regarding the aforementioned production acts. Coordination acts are performed by one actor, the performer, and are aimed at another actor, the addressee. These coordination acts contain the performers' intention, a production fact and the associated creation time of the fact. For example, an actor fulfilling a applicant role can communicate a request to become a member at a certain time towards an actor role that registers members within a library (Fig. \ref{fig:cord}). This internal actor can then choose to honor this request and thus create a commitment towards the applicant or decide to decline depending on the circumstances.\\

\\

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=0.8\textwidth]{figures/coordinationact.png}

\caption{Notation of a coordination act \cite{dietz2006enterprise}}

\label{fig:cord}

\end{figure}

\FloatBarrier

\newpage

\noindent

The performance of production and coordination acts create facts in their corresponding worlds. The state of the production world, or P-world, at a particular point in time is nothing more than the set of created P-facts up to that point in time. Likewise, the state of the coordination world, or C-world, at a particular point in time consists of the set of created C-facts up to that point in time. This is represented graphically in Figure \ref{fig:op}. Actors are represented with a square, the C-World is represented with the disc and the P-world is represented with the diamond. The solid arrows represent that actors perform C-acts and P-acts, while the dashed arrows represent that actors take account of the C- and P-facts created in the C-world and P-world when they are active \cite{dietz2006enterprise}.

\vfill

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=.5\textwidth]{figures/OperationAxiom.png}

\caption{Graphical representation of the operation axiom \cite{dietz2006enterprise}}

\label{fig:op}

\end{figure}

\FloatBarrier

\vfill

\newpage

\subsection{Transaction axiom}

The second axiom states that the performance of coordination acts between actor roles regarding production occur as steps in an universal pattern. These patterns are referred to as \emph{transactions} and always involve two actor roles. One of the two actor roles is called the \emph{initiator} and the other is called the \emph{executor} of the transaction (Fig. \ref{fig:transaction}). A transaction consists of two conversations between the initiator and executor and are aimed at achieving a well-defined result concerning a P-act/fact; the order and result conversation with execution of the production act in between.\\

\\

The Order phase consists of coordination acts with the intention request, promise, decline and quit. The Execution phase produces the fact(s) and the Result phase consists of the acts of stating, rejecting, stopping and accepting. The production facts only come into existence in the production world when they are accepted by the initiator in the Result phase. The transaction states declined and rejected are known as discussion states where both initiator and executor have to discuss what the cause of the exception is and how to proceed. If either initiator or executor wants to revoke an act this can be done for every C-fact through their respective revocation patterns. This entails a revoke act followed by either a refuse or allow act from the opposite party.\\

\\

A transaction can thus be in 20 different states of coordination that denote a transaction as either successful, problematic or canceling (Table \ref{tab:sfc}). This complete pattern is depicted in Figure \ref{fig:transaction}. Important to note is that during a transaction not all C-acts have to be performed as they can be performed explicitly or implicitly. This allows for optimization and reflects business policy in situations where explicit coordination acts are deemed unnecessary or undesirable \cite{huysmans2010using}. This whole transaction pattern can seem quite complex but fortunately this complexity can be abstracted through a simplified construct as depicted in Figure \ref{fig:transaction2}.

\vfill

\FloatBarrier

\begin{table}[htbp]

  \centering

  \caption{Different states of a transaction}

    \begin{tabular}{llr}

    \textbf{success} & \textbf{problems} & \multicolumn{1}{l}{\textbf{cancellation}} \\

    \midrule

    request & quit  & \multicolumn{1}{l}{revoke} \\

    promise & decline & \multicolumn{1}{l}{refuse} \\

    state & stop  & \multicolumn{1}{l}{allow} \\

    accept & reject &  \\

    \end{tabular}%

  \label{tab:sfc}%

\end{table}%

\FloatBarrier

\vfill

\newpage

\vfill

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=\textwidth]{figures/Transaction2.png}

\caption{Complete transaction pattern \cite{awarenessL1}}

\label{fig:transaction}

\end{figure}

\FloatBarrier

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=\textwidth]{figures/organizationalbuildingblock.png}

\caption{Transaction abstraction \cite{awarenessL1}}

\label{fig:transaction2}

\end{figure}

\FloatBarrier

\vfill

\newpage

\subsection{Composition axiom}

The \emph{composition axiom} simply states that a business process is a collection or tree structure of casually related transaction types. Every transaction is enclosed in some other transaction, a transaction with a customer or a self-activated transaction. Thus, the start of a business process is either a request performed by an external actor role or a request by an internal actor role to itself which is referred to as self-activation. In this manner the production of an enterprise can be decomposed into sub assemblies and atomic parts. This comes naturally for physical products such as a bicycle (Figure \ref{fig:f1}). However, it also applicable for mixtures of material and immaterial production such as establishing a problem in health care (Figure \ref{fig:f2}).

\vfill

\FloatBarrier

\begin{figure}[!h]

  \centering

  \subfloat[Bicycle decomposition]{\includegraphics[width=0.4\textwidth]{figures/DecompBicycle.png}\label{fig:f1}}

  \hfill

  \subfloat[Problem decomposition]{\includegraphics[width=0.4\textwidth]{figures/DecompProblem.png}\label{fig:f2}}

  \caption{Different component structures \cite{dietz2006enterprise}}

\end{figure}

\FloatBarrier

\vfill

\newpage

\subsection{Distinction axiom}

The fourth axiom states that actors have three distinct human abilities, called \emph{performa, informa} and \emph{forma}. Through these abilities humans are able to create things, reason, process information and communicate. This axiom mostly serves as a separation of concerns and is therefore called the \emph{distinction axiom} \cite{dietz2006enterprise}.\\

\\

The forma ability is concerned with the form aspects of communication and information. Regarding coordination it is the ability to utter and perceive information in some language such as the ability to write and read plain English. Regarding production it concerns the ability to deal with recorded information items called data or documents through storing, transmitting, retrieving etc.\\

\\

The informa ability is concerned with the content aspects of communication and information regardless of its form. Regarding communication it is the ability to formulate and express thoughts such as the ability to form and interpret sentences regardless of the language in which it is expressed. Regarding production this ability is to reason, compute and derive as well as remember and reproduce facts.\\

\\

The performa ability is the ability to create new, original things or facts. Regarding communication it is the ability to enter into and comply with commitments and reach social understanding between two actors. Regarding production it is the ability to establish new facts such as creating, storing or transporting material products or making decisions. This production ability is considered the core of doing business and the transactions in which they occur are called the essential or ontological transactions. Transactions using the informa and forma abilities are considered to be a realization of the ontological transactions. A summary of this axiom is presented graphically in Figure \ref{fig:distinction}.

\FloatBarrier

\begin{figure}[!hp]

\centering

\includegraphics[width=.6\textwidth]{figures/DistinctionAxiom.png}

\caption{Summary of the distinction axiom \cite{dietz2006enterprise}}

\label{fig:distinction}

\end{figure}

\FloatBarrier

\newpage

\noindent

This separation of concerns is best depicted through the process of performing a coordination act (Figure \ref{fig:distinctioncoordination}). The performer (P) wants to make his intentions towards the addressee (A) known in order to reach social understanding. He therefore needs to be able to express his thoughts and formulate it in a sentence using some language through speaking or writing. This data then has to reach the addressee by encoding some medium. In everyday face-to-face conversations air is encoded through speaking which produces sound waves. Paper can also be encoded using ink and sent through postal mail. Smartphones produce electro-magnetic waves to transmit data. The means with which to exchange data are numerous and will therefore be referred to as (tele-)communication technology. The result is the same; the data arrives at the addressee. The addressee needs to able to decode the medium and understand the language. The received sentence must then educe a thought in the mind of the addressee. When the addressee responds to the coordination act, the roles become reversed and the process repeats.

\vfill

\FloatBarrier

\begin{figure}[!hp]

\centering

\includegraphics[width=.6\textwidth]{figures/DistinctionTransaction.png}

\caption{Process of a coordination act \cite{dietz2006enterprise}}

\label{fig:distinctioncoordination}

\end{figure}

\FloatBarrier

\vfill

\newpage

\subsection{Organization theorem}

The organization theorem is an extension of the distinction axiom regarding  the whole enterprise. It simple states that organization of any enterprise is a heterogeneous system that is formed by the layered integration of three homogeneous systems: the B-organization (from Business), the I-organization (from Intellect), the D-organization (from Document). The relationships between them are such that the D-organization support the I-organization and the I-organization supports the B-organization as depicted graphically in Figure \ref{fig:organization}. This means that the actors of the O-organization or in other words the employees of an enterprise use the functionality of the actors in the I-organization to remember and share facts during their work. This I-organization, in turn, use the functionality of the actors in the D-organization to archive, provide and transmit these facts using documents.\\

\\

However, most modern organizations use software to assist these three aspect layers in their work as well as physical hardware and infrastructure. Notable pieces of software to support the employees in the O-organization are Decision Support Systems and Business Process Management Systems. The I-organization is usually supported through information systems such as accounting or ERP systems. The D-organization is supported or in most cases completely replaced with generic applications such as text processors, operating systems and database systems.

\FloatBarrier

\begin{figure}[!hp]

\centering

\includegraphics[width=.6\textwidth]{figures/OrganizationTheorem2.png}

\caption{Summary of the organization theorem \cite{awarenessL1}}

\label{fig:organization}

\end{figure}

\FloatBarrier

\newpage

\section{Generic System Development Process (GSDP)}\label{GSDP}

The DEMO methodology views organizations as social systems. Since systems can be developed, such as bringing about a new system or making changes to an existing one, this also applies to organizations. The Generic System Development Process consists of all the activities that are needed in order to develop systems of any kind and is depicted graphically in Figure \ref{fig:gsdp}. According to the GSDP, the development of any system actually concerns two systems; the using system (US) and the object system (OS). The OS is the system to be developed and the US is the system that is going to use the services, or functionality, of the object system.\\

\\

The GSDP consists of three phases; design, engineering and implementation. Design consists of two activities called function design and construction design. Function design starts from the construction of the US and ends with the functional, black box model, of the OS. Construction design starts from the specified function of the OS and ends with constructional, white box model, of the OS. The word ontology, in Figure \ref{fig:gsdp}, refers to the fact that both constructional models of the US and OS are ontological, or white box, system models in contrast with the teleological, or black box, system model of the OS at the center. Engineering is the activity of converting the highest level constructional models into lower level implementation models are constructed (e.g., Java, C\#, C++). Implementation is the activity of assigning technological means to each constructional component in the implementation model so the system can be made operational.\\

\\

The entire design process is understood as alternating between analysis and synthesis steps in order for the end result to be compromise between reasonable requirements and feasible specifications. Furthermore, since this is a generic development process applicable to all kinds of systems, instances of the GSDP can be applied to design all three layers of an organization.

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=0.8\textwidth]{figures/GSDP2.png}

\caption{Generic Systems Development Process \cite{dietz2006enterprise}}

\label{fig:gsdp}

\end{figure}

\FloatBarrier

\section{DEMO modeling}

The process of modeling an enterprise is known as the Design \& Engineering Methodology for Organizations (DEMO). This methodology relies on the theory of enterprise ontology discussed in the previous sections. DEMO modeling produces four distinct aspect models of the O-organization collectively called the essential model. This section will briefly discuss these aspect models including the diagrams and tables used to represent these aspects.

\subsection{Aspect models}

The four aspect models that together completely represent an enterprise consist of the Construction Model (CM), the Process Model (PM), the Fact Model (FM) and the Action Model (AM) (Figure \ref{fig:aspectmodels}).

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=\textwidth]{figures/AspectModels2.png}

\caption{The aspect models \cite{awarenessL1}}

\label{fig:aspectmodels}

\end{figure}

\FloatBarrier

\newpage

\paragraph{Construction Model}\mbox{}\\

The Construction Model specifies the ontological transaction types and their initiating and executing actor roles. This model also contains the information links between actor roles and the information banks. These information banks consists of the production and coordination banks. Production banks contain the created production facts of a transaction and the coordination banks contain the created coordination facts of a transaction. This information, or data, can be stored in databases, spreadsheets, mail applications, text files and so on. These transaction types, actor roles, information links and information banks are represented using an Organization Construction Diagram (OCD) using diagram elements similar to the ones depicted in Figure \ref{fig:OCD}. This is supplemented by a Transaction Product Table (TPT) which specifies the resulting product kinds of each transaction. The facts contained in each information bank is specified in an Bank Contents Table (BCT).

\vfill

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=.8\textwidth]{figures/crispielegend.png}

\caption{OCD Legend \cite{dietz2006enterprise}}

\label{fig:OCD}

\end{figure}

\FloatBarrier

\vfill

\newpage

\noindent

Take Figure \ref{fig:OCDexample} for example, it represent a hypothetical firm that gives financial advice to its' clients for a fee. Please note, however, that this is an simplified example for illustration purposes. The composite actor role B-CA01, the client, is the initiator of the transaction B-T01 with the production fact \emph{[advice] has been given} as intended result (Table \ref{tab:TPTexample}). The internal elementary actor role B-A01, the advisor, gives his or her advice based on the clients' personal information, credit rating report(s) and income statement(s) which are contained in the external fact bank B-APB01 (Table \ref{tab:BCTexample}). Since this the essential ontological construction model, only the information links between the actor role B-A01 and the external fact banks are depicted to denote that the actor role has or should have access to this information. How this actor role accesses this information is a matter of implementation (see Section 2.1.4 and 2.1.5). Furthermore, before completing transaction B-T01 a fee must be paid for the advice through transaction B-T02 which has the intended production fact \emph{fee for [advice] has been paid}.

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=.8\textwidth]{cookbook/examples/OCD1.png}

\caption{Example OCD - Financial advice}

\label{fig:OCDexample}

\end{figure}

\FloatBarrier

\begin{table}[htbp]

  \centering

  \caption{Example TPT - Financial advice}

    \begin{tabular}{ll}

    \textbf{Transaction kind} & \textbf{Product kind} \\

    \midrule

    B-T01 & \textbf{P1} [advice] has been given \\

    B-T02 & \textbf{P2} fee for [advice] has been paid \\

    \end{tabular}%

  \label{tab:TPTexample}%

\end{table}%

\begin{table}[htbp]

  \centering

  \caption{Example BCT - Financial advice}

    \begin{tabular}{ll}

    \textbf{Fact bank} & \textbf{Fact kind} \\

    \midrule

    \textbf{T01} & ADVICE \\

  & [advice] has been given \\

  & client of [advice] is [person] \\

  & credit rating of [person] is [credit rating] \\

  & income statement of [person] is [income statement] \\

    \textbf{T02} & fee for [advice] has been paid \\

    \textbf{APB01} & PERSON \\

  & CREDIT RATING \\

  & INCOME STATEMENT \\

    \textbf{APB02} & standard\_fee \\

    \end{tabular}%

  \label{tab:BCTexample}%

\end{table}%

\newpage

\paragraph{Process Model}\mbox{}\\

The Process Model specifies how the transactions types of the CM are related to each other through causal and conditional links including cardinalities. Thus this model specifies the so called state space and transition space of the C-world. This model is essentially a non proportional horizontal time line of nested transactions and represented with a Process Structure Diagram (PSD). Figure \ref{fig:PSDexample} depicts the PSD for the financial advisor example. The figure shows that an (for the firm) unknown event causes T01 to be requested (rq). The link between T01 promise (pm) and T02 requested (rq) shows that once the advisor promises to give financial advice the payment fee should be requested. The conditional (dashed) link between T02 accept (ac) and T01 execute denotes that completion of T01 has to wait on the completion of T02. This has the effect that the transaction T02 is fully enclosed in the transaction T01.\\

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=.5\textwidth]{cookbook/examples/PSD1.png}

\caption{Example PSD - Financial advice}

\label{fig:PSDexample}

\end{figure}

\FloatBarrier

\newpage

\paragraph{Fact Model}\mbox{}\\

The Fact Model represents the so called state space of the P-world. It specifies the object classes, associated fact kinds and any existence laws that apply. Furthermore, it specifies the production event kinds, which are the results of transactions as noted in the TPT, including any occurrence laws that apply. This model is represented by an Object Fact Diagram (OFD) using a modified Object Role Modeling (ORM) notation (see Appendix \ref{app:wosl}), an Object Property List (OPL) and Derived Fact Specifications. Figure \ref{fig:OFDexample} represents the OFD for the running example and Table \ref{tab:OPLexample} the OPL and derived facts.\\

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=\textwidth]{cookbook/examples/OFD1.png}

\caption{Example OFD - Financial advice}

\label{fig:OFDexample}

\end{figure}

\FloatBarrier

\begin{table}[htbp]

  \centering

  \caption{Example OPL \& DFS - Financial advice}

    \begin{tabular}{llr}

    \textbf{Property} & \textbf{Domain} & \multicolumn{1}{l}{\textbf{Range}} \\

    \midrule

    fee   & ADVICE  & \multicolumn{1}{l}{MONEY} \\

    standard\_fee   & FIRM  & \multicolumn{1}{l}{MONEY} \\

    minimum\_age & FIRM  & \multicolumn{1}{l}{NUMBER} \\

    date\_of\_birth & PERSON & \multicolumn{1}{l}{DATE} \\

    age(*) & PERSON & \multicolumn{1}{l}{NUMBER} \\

  &       &  \\

    \textbf{Derived Fact Specifications} &       &  \\

    \midrule

    age(P) = & year(date\_of\_birth(P))-current\_year &  \\

    \end{tabular}%

  \label{tab:OPLexample}%

\end{table}%

\newpage

\noindent

The OFD above shows the main internal object class called \emph{ADVICE} of which instances are produced in the firm through T01 and the external object classes \emph{PERSON, CREDIT RATING} and \emph{INCOME STATEMENT}. The binary fact type \emph{client of [advice] is [person]} denotes the relationship between a person and an advice instance. This relationships is dependent on the \emph{ADVICE} domain and has a unicity constraint. This basically means that this relationship always refers to an advice instance and this instance may occur only once in its population. In other words, one advice object is given to at most one client, but a client can have multiple advice objects. Similar reasoning holds for the other relationships where the client can have multiple credit ratings and income statements as long as each of them is unique.\\

\\

The OPL contained in Table \ref{tab:OPLexample} specifies the properties of the \emph{FIRM} domain or in other words; the internal variables that the company uses such as the fee amount per advice and the required minimum age of a client. The properties of the object class \emph{PERSON} consists of a date of birth and the corresponding derived age property.

\paragraph{Action Model}\mbox{}\\

The Action Model contains the action rules that serve as guidelines for actors when dealing with their agenda. An agendum is nothing more than a coordination fact from another actor as discussed in the previous sections. Every actor role has a set of action rules for each agendum type (requested, promised, stated and so on). These rules specify the coordination acts that need or may be performed in response to a coordination fact given that certain conditions hold. It should be noted that these rules serve as guidelines and actors may deviate from these rules at their own discretion but are held responsible for their actions. Action rules are contained in the Action Rules Specifications (ARS) and expressed using a pseudo-algorithmic language.\\

\\

For the running example the action rules are fairly simple (see Listing \ref{lst:ars1}). The first block specifies what to do when T01 is requested. First a new advice object is created and linked to a person entity, credit rating report and income statement. If the person does not meet the age requirements the request should be declined, otherwise the request should be promised. This age requirement may seem a bit strange but it is almost a standard verification procedure when using websites such as online retailers, social media and so on. Remember, the essential model is abstracted from all implementation choices but these types of verification methods should be considered since a transaction need not be face-to-face. No specific conditions apply to the credit rating report and income statement; they should just be present.\\

\\

Following a promise of T01, T02 should be requested with the fee amount as specified in the external fact bank APB02. When payment by actor role B-CA02 is stated, the advisor should check whether it is sufficient and respond accordingly. If T02 is accepted, T01 can be executed and stated which completes the business process.

\newpage

%\begin{lstlisting}[caption={Example ARS - Financial advice (Actor role B-A01)},label={lst:ars1},mathescape]

%

%on requested T01(A) with client(new A) = P and credit_rating(P) = C and income_statement(P) = I

%

% if age(P) < minimum_age $\rightarrow$ decline T01(A)

% $\diamondsuit$ age(P) $\geq$ minimum_age $\rightarrow$ promise T01(A)

% fi

%

%no

%

%on promised T01(A)

%

% request T02(A) with fee

%

%no

%

%on stated T02(A)

%

% if <payment is acceptable> $\rightarrow$ accept T02(A)

% $\diamondsuit$ <payment is unacceptable> $\rightarrow$ reject T02(A)

% fi

%

%no

%

%on accepted T02(A)

%

% execute T01(A)

% state T01(A)

%

%no

%\end{lstlisting}

\begin{lstlisting}[caption={Example ARS - Financial advice (Actor role B-A01)},label={lst:ars1},mathescape]

------------------------------------------------------- T01/rq

when T01(A) is requested with client(new A) = P

          and credit_rating(P) = C

          and income_statement(P) = I

if age(P) $\geq$ miminum_age

then promise T01(A)

else decline T01(A)

------------------------------------------------------- T01/pm

when T01(A) is promised

then request T02(A) with fee(A) = standard_fee

         and addressee of request = client(A)

------------------------------------------------------- T02/st

when T02(A) is stated

if <payment is acceptable>

then accept T02(A)

else reject T02(A)

------------------------------------------------------- T02/ac

when T02(A) is accepted

if <no specific condition>

then execute T01(A)

  state T01(A)

\end{lstlisting}

\newpage

\subsection{Modeling method}

According to \citet{dietz2006enterprise}, the logical sequence of producing the aforementioned models is in an anti-clockwise manner starting with the OCD. This is done using the knowledge contained in all available documentation regarding an enterprise of whatever kind and in whatever form. This can be interviews, procedure manuals, handbooks and so on. However, one should keep in mind it is a method not a dogma and one may freely iterate through these six steps or even skip a step:\\

\begin{enumerate}[noitemsep]

\item \emph{Performa-Informa-Forma Analysis}: Available knowledge is divided according to the distinction axiom. This can best be done by coloring the appropriate parts of the descriptions/documentation.

\item \emph{Coordination-Actors-Production Analysis}: The Performa items are divided into C-acts/facts, P-acts/facts, and actor roles according to the operation axiom.

\item \emph{Transaction Pattern Synthesis}: The transaction pattern is used to cluster the results into transaction types. This allows for the creation of the TPT.

\item \emph{Result Structure Analysis}: The composition axiom is used to determine the components of each transaction with the environment.

\item \emph{Construction synthesis}: For every transaction type, the initiating actor role(s) and the executing actor roles are assigned resulting in an OCD.

\item \emph{Organization synthesis}: A definite choice has to be made as to what part of the construction will be taken as the organization to be studied and what part becomes the environment. This allows the OCD to be finalized.

\end{enumerate}

\noindent

However, this brings us as far as the OCD. Thereafter, the remaining models are created in broad strokes. A complete OCD allows for the PSD to be created. This is then followed by specifying the Action Rules, after which the OFD, OPL and BCT can be created.

\newpage

\subsection{Applications}

\citet{maij2002use} applied an early version of DEMO in an health care organization in order to create a starting point for deriving information system functionality using UML use cases. The main method for determining the models is stated as consisting of interviews, however no systematic approach was presented. The case study demonstrated that the combined use of DEMO and UML is useful for aligning business processes and functional features of ICT-infrastructure where end-users played a vital part.\\

\\

\citet{albani2006identifying} used a version of DEMO in order to identify and specify business components which are software components of an organization that directly support operational activities. However, this shifted the problem of software requirements engineering to determining high quality business domain models. Nonetheless, they were able to obtain a domain model in conjunction with stakeholders, but only presented the result of this identification and specification process and did not provide an account of the process itself \cite{albani2006benefit}.\\

\\

DEMO has been effectively applied in order to split off parts of the Dutch Agency of Public Works and Water Management \cite{op2008applying} where transactions were used to calculate an optimal seperation. This seperation caused minimal communicational dependencies between the now seperate entities. Furthermore, it can help to manage change in a multinational enterprise \cite{op2012benefits} and to determine inter-organizational software requirements \cite{huysmans2010using}. \citet{de2013method} provides a method with which to derive specifications for an enterprise information system from the ontological models of the O-organization. DEMO has also been used to develop a case management system for an Dutch utility company. During that project, besides the case management software, an additional piece of software was developed that can directly execute DEMO models and was dubbed the Enterprise Operating System (EOS) \cite{van2012ontology}. Furthermore, the study claimed optimal business-IT alignment through shared reasoning and model creation with stakeholders. However, the case study called for a systematic derivation of high quality specifications regarding the availability of contextual information needed during each process step \cite{hintzen2014professional}. As a result, the modeling stage was deemed the only remaining creative stage as opposed to providing an implementation in software.

\newpage

\section{The Enterprise Operating System}

Formetis BV has developed software which they call the Enterprise Operating System (EOS) \cite{hintzen2014professional, skotnica2016towards}. The EOS consists of the DEMO engine which reads and executes the four DEMO aspect models and therefore has complete prescriptive control of the enterprise. The software handles all communication between actors and enforces compliance to the specified DEMO models providing full work-flow capabilities (Figure \ref{fig:demoengine}). Consequently, it has complete and total knowledge of the enterprise as every production act/fact and coordination act/fact of every actor is recorded and (optionally) notarized using the blockchain technology.\\

\\

The DEMO engine is developed due to the observation that each design step in the GSDP (i.e., function design, construction design and implementation design) is prone to errors in practice. In order to skip these steps and deliver any complete, correct implementation of the ontological construction model of the organization, the DEMO engine directly executes this model as workflow. Employees of the enterprise interact with a presentation layer driven by the DEMO engine. In this manner, the ontological model becomes the executable software and changes to the software can be made by modifying the model \cite{van2012ontology}. Therefore, the EOS and the DEMO models directly form the foundations of any enterprise information systems that support the enterprise ranging from descriptive systems such as inventory, financial and personnel information systems to production systems such as case management systems.

%\FloatBarrier

%\begin{figure}[!h]

%  \centering

%  \subfloat[Foundations of the EOS]{\includegraphics[width=0.6\textwidth]{figures/EOS.png}\label{fig:eos}}

%  \hfill

%  \subfloat[The DEMO engine]{\includegraphics[width=0.3\textwidth]{figures/DEMOengine_2.png}\label{fig:demoengine}}

%  \caption{The Enterprise Operating System}

%\end{figure}

%\FloatBarrier

\FloatBarrier

\begin{figure}[!h]

\centering

\includegraphics[width=\textwidth]{figures/DEMOengine.png}

\caption{DEMO engine architecture \cite{hintzen2014professional}}

\label{fig:demoengine}

\end{figure}

\FloatBarrier

\newpage

\section{Conclusion}

The purpose of this literature review was primarily to understand the way of working at Formetis BV and identify any possible gaps. Analysis of the relevant literature regarding the theoretical foundations of the DEMO methodology, and the software created by Formetis BV, allows for some conclusion to be drawn.\\

\\

Enterprise ontology views organizations as social systems comprised of actors that communicate regarding production act through coordination acts. This communication occurs in a universal pattern called the transaction that occurs between an initiator and executor (e.g., customer and producer). Furthermore, it makes a distinction between three distinct abilities that play a role during the operation of actors, called performa, informa and forma. These abilities apply to both production and coordination acts. By extending these abilities to an entire enterprise, the theory views the organization of an enterprise as a social system consisting of a layered integration of three homogeneous systems; the O-organization, I-organization and D-organization.\\

\\

The design of each layer occurs through iterative application the Generic Systems Development Process, such that the functionality of each layer supports the construction of the layer above it. In other words, the information services provided by the I-organization support the actors in the O-organization and the data services provided by the D-organization support the actors in the I-organization. However, currently the 'official' modeling method for specifying the O-organization is focused on the OCD and based on the analysis of the essential knowledge contained in text of narrative descriptions, procedure manuals, handbooks and so on. The found literature were DEMO was applied in practice also do not provide a detailed account of any systematic approach to collect this knowledge if these texts are not available. The case study conducted and published by Formetis BV at Endinet also called for a systematic derivation of high quality specifications for each process step in the ontological model. This means the specification of the required contextual information elements at each step in the ontological transactions. These elements are to be defined in the Fact Model and contained in the Action Model as well. The DEMO engine, that was developed during that project, executes DEMO models directly and these models are an one-to-one representation of (a part of) the organization. Therefore, it is important to these models are of the highest quality as possible and that this specification process is done quickly.\\

\\

In summary, enterprise ontology provides a social systems view of an organization and establishes solid links between the business system, information systems and database systems. Each system layer can be designed using an instance of the GSDP and the resulting models can be directly executed as workflow in the DEMO engine. On the basis of these models the application specifications for each actor can be determined, such as UI elements, for the software developers handling the presentation layer.  However, the current official DEMO modeling method to model the organization (the business system) relies heavily on textual descriptions. The knowledge contained in these descriptions needs to be filtered to arrive at the required essential knowledge with which to construct the ontological construction model. In the opinion of the researcher, this may not be an highly efficient approach.

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, . Available from:< https://www.essaysauce.com/essays/engineering/essay-2017-05-16-000CvA.php > [Accessed 14.10.19].