Design & Engineering Methodology for Organizations

Design & Engineering Methodology for Organizations (DEMO) is an enterprise modelling methodology for transaction modelling, and analysing and representing business processes. It is developed since the 1980s by Jan Dietz and others, and is inspired by the language/action perspective[1]

Diagram of the principle of a DEMO transaction between two actors, with the result in between.

Overview

DEMO is a methodology for designing, organizing and linking organizations. Central concept is the "communicative action": communication is considered essential for the functioning of organizations. Agreements between employees, customers and suppliers are indeed created to communicate. The same is true for the acceptance of the results supplied.[2]

The DEMO methodology is based on the following principles:[3]

  • The essence of an organization is that it consists of people with authority and responsibility to act and negotiate.
  • The modeling of business processes and information systems is a rational activity, which leads to uniformity.
  • Models should be understandable for all concerned.
  • Information should 'fit' with their users.

The DEMO methodology provides a coherent understanding of communication, information, action and organization. The scope is here shifted from "Information Systems Engineering" to "Business Systems Engineering", with a clear understanding of both the information and the central organizations.[3]

History

The DEMO methodology is inspired on the language/action perspective, which was initially developed as a philosophy of language by J. L. Austin, John Searle and Jürgen Habermas and was built on the speech act theory. The language/action perspective was introduced in the field of computer science and information systems design by Fernando Flores and Terry Winograd in the 1980s.[4] According to Dignum and Dietz (1997) this concept has "proven to be a new basic paradigm for Information Systems Design. In contrast to traditional views of data flow, the language/action perspective emphasizes what people do while communicating, how they create a common reality by means of language, and how communication brings about a coordination of their activities."[5]

DEMO is developed at the Delft University of Technology by Jan Dietz in the early 1990s, and originally stood for "Dynamic Essential Modelling of Organizations". It builds on the Language Action Perspective (LAP), which is derived from the work include John Austin, John Searle and Jürgen Habermas since the 1960s. It is linked to the "Natural language Information Analysis Method" (NIAM) developed by Shir Nijssen,[6] and object-role modeling (ORM)[7] further developed by Terry Halpin.

In the 1990s the name was changed to "Design & Engineering Methodology for Organizations". In the new millennium Jan Dietz further elaborated DEMO into "enterprise ontology", in which the graphic note of object-role modeling is integrated.[8] These concepts were also developed by Dietz and others into a framework for enterprise architecture, entitled Architecture Framework (XAF).[9] In the new millennium the French company Sogeti developed a methodology based on the DEMO, called Pronto. The further development of DEMO is supported by the international Enterprise Engineering Institute, based in Delft in The Netherlands.[10]

DEMO, topics

Pattern of a business transaction

In DEMO the basic pattern of a business transaction is composed of the following three phases:[11]

  • An actagenic phase during which a client requests a fact from the supplier agent.
  • The action execution which will generate the required fact
  • A factagenic phase, which leads the client to accept the results reported

Basic transactions can be composed to account for complex transactions. The DEMO methodology gives the analyst an understanding of the business processes of the organization, as well as the agents involved, but is less clear about pragmatics aspects of the transaction, such as the conversation structure and the intentions generated in each agents mind.[11]

Abstraction levels

DEMO assumes that an organization consists of three integrated layers:[12][13]

  • B-organization,
  • I-organization and
  • D-organization.

The B-organization or business layer according to DEMO is the essence of the organization, regardless of the device is possible there. Understanding the business layer is the right starting point in setting up an organization, including the software to support business processes.

This vision leads to a division into three perspectives or levels of abstraction:[3]

  • Essential: business system or the B system
  • Informational: either the information I system
  • Documenteel: data system either D system

At each level has its own category of systems at that level "active": there are so B systems (of company and business), I-systems (of informational and information) and D systems (from documenteel and data) . The main focus in DEMO is focused on the critical level, the other two are, therefore, less discussed in detail.[3]

The ontological model of an organization

The ontological model of an organisation in DEMO-3 consists of the integrated whole of four aspect models, each taking a specific view on the organisation:

  • Construction Model (CM)
  • Process Model (PM)
  • Action Model (AM), and
  • Fact Model (FM)

There are two ways of representing these aspect models: graphically, in diagrams and tables, and textually, in DEMOSL.

Construction Model The Construction Model (CM) of an organisation is the ontological model of its construction: the composition (the internal actor roles, i.e. the actor roles within the border of the organisation), the environment (i.e. the actor roles outside the border of the organisation that have interaction with internal actor roles), the interaction structure (i.e. the transaction kinds between the actor roles in the composition, and between these and the actor roles in the environment), and the interstriction structure (i.e. the information links from actor roles in the composition to internal transaction kinds and to external transaction kinds).

The CM of an organisation is represented in an Organisation Construction Diagram (OCD), a Transaction Product Table (TPT), and a Bank Contents Table (BCT).

Process Model The Process Model (PM) of an organisation is the ontological model of the state space and the transition space of its coordination world. Regarding the state space, the PM contains, for all internal and border transaction kinds, the process steps and the existence laws that apply, according to the complete transaction pattern. Regarding the transition space, the PM contains the coordination event kinds as well as the applicable occurrence laws, including the cardinalities of the occurrences. The occurrence laws within a transaction process are fully determined by the complete transaction pattern. Therefore, a PSD contains only the occurrence laws between transaction processes, expressed in links between process steps. There are two kinds: response links and waiting links.

A PM is represented in a Process Structure Diagram (PSD), and a Transaction Pattern Diagram (TPD) for each transaction kind. In these diagrams it is indicated which ‘exceptions’ will be dealt with.

Action Model The Action Model (AM) of an organisation consists of a set of action rules. There is an action rule for every agendum kind for every internal actor role. The agendum kinds are determined by the TPDs of the identified transaction kinds (see PM). An action rule consists of an event part (the event(s) to respond to), an assess part (the facts to be inspected), and a response part (the act(s) to be performed.

An AM is represented in Action Rule Specifications (ARS) and Work Instruction Specifications (WIS).

Fact Model The Fact Model (FM) of an organisation is the ontological model of the state space and the transition space of its production world. Regarding the state space, the FM contains all identified fact kinds (both declared and derived), and the existence laws. Three kinds of existence laws are specified graphically: reference laws, unicity laws, and dependency laws; the other ones are specified textually. Regarding the transition space, the FM contains the production event kinds (results of transactions) as well as the applicable occurrence laws. The transition space of the production world is completely determined by the transition space of its coordination world. Yet it may be illustrative to show the implied occurrence laws in an OFD.

The FM is represented in an Object Fact Diagram (OFD), possibly complemented by Derived Fact Specifications and Existence Law Specifications.

Operation principle

If somebody (a person) wants to ensure that someone else creates a desired result then he or she starts a communication with a request. The person responsible for the results, can respond with a promise. Some time later, when work was done (the execution has taken place), he/she can state that the desired result is achieved. If this result is accepted by the person who had asked for the result then this is a fact. The pattern described in the communication between two people is called a DEMO transaction. A chain of transactions is called in DEMO a business process.

Diagram of the principle of a DEMO transaction between two actors, with the result in between.

The result of a transaction can be specified in DEMO as a facttype, using object-role modeling ( ORM ).

Support tools

The Dutch company Essmod the "Essential Business Modeler" tool developed based on DEMO, which was acquired in 2008 by Mprise after which it renamed to Xemod.

DEMO is also supported in the open source world with the architecture tool Open Modeling. There is also a free online modeling tool Model for World DEMO which can be in an online repository. Multiuser worked This tool is platform-independent in a web browser without downloading or installing software.

gollark: Heterochromia?
gollark: Which thing? Automated racism?
gollark: I assume someone has something like that so they can train racism *detection* things.
gollark: Some bits of reddit, possibly.
gollark: If we trained GPT-3 to be racist, would it be *truly* racist or merely a bad simulacrum of a racist human?

See also

References
  1. Jan L.G. Dietz (1999). "DEMO : towards a discipline of Organisation Engineering" In: European Journal of Operational Research, 1999.
  2. Enterprise Engineering Institute. Accessed November 21, 2008.
  3. Jan Dietz (1996) Introductie tot DEMO Archived 2016-03-05 at the Wayback Machine. Accessed April 2, 2013.
  4. Flores, F., Graves, M., Hartfield, B., & Winograd, T. (1988). "Computer systems and the design of organizational interaction Archived 2014-10-29 at the Wayback Machine." ACM Transactions on Information Systems (TOIS), 6(2), 153-172.
  5. Frank Dignum, Jan Dietz editors. (1997) Communication Modeling, The Language/Action Perspective. Second International Workshop on Communication Modeling (LAP'97) Veldhoven, The Netherlands, JUNE 9-10 1997 Working Papers.
  6. Rob Aaldijk en Erik Vermeulen (2001). Modelleren van organisaties -- nieuwe methoden en technieken leiden tot beter inzicht. Landelijk Architectuur Congres 2001.
  7. Jan L. G. Dietz, Terry A. Halpin (2004). "Using DEMO and ORM in Concert: A Case Study". In: Advanced Topics in Database Research, Keng Siau (red.) Vol. 3 2004: pp. 218-236.
  8. Jan L.G. Dietz (2006). Enterprise Ontology - Theory and Methodology, Springer-Verlag Berlin Heidelberg. p.46.
  9. Jan Dietz (2008). Architecture - Building strategy into design. Academic Service. ISBN 978-90-12-58086-1
  10. Enterprise Engineering Institute
  11. Kecheng Liu (2001). Information, Organisation, and Technology: Studies in Organisational Semiotics. pp.198-2002.
  12. Jan L.G. Dietz (2006). Enterprise Ontology - Theory and Methodology, Springer-Verlag Berlin Heidelberg. p.118.
  13. Jan L.G. Dietz (2008). Architecture : Building strategy into design. Academic Service. ISBN 9789012580861 p.32

Further reading
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.