This case study describes a real world project carried out by Formetis in 2012, for a professional client, a utility company, who maintain the infrastructure for electricity and gas services for their customers. The client requires an IT system for the production of complex contracts, while many quality requirements have to be met. The project has been carried out “by the book”, using the theory, methodologies and software tools provided by the discipline of enterprise engineering. This includes DEMO modeling, model validation and simulation, derivation of specifications for a supporting adaptive case management system and application of the Enterprise Operating System. The proposed approach is new and radically different from state of the art methodologies. This case is a guide to carry out similar projects for a wide range of applications in financial services, government services, legal, litigation etc.
This case study is a real world project, the “AVS case management system” for
Endinet BV, The Netherlands, carried out by practitioners, Formetis BV in the
Netherlands, applying the theories, methodologies and software tools provided by the
discipline of enterprise engineering (EE) [
The purpose of this case study is 1) to provide other practitioners a new and radically different but appropriate and promising approach to carry out comparable projects in related domains [sections 4, 7.2]; 2) to assess empirically the quality of the approach and the result itself, compare functional qualities to state of the art methodologies [section 3]; 3) assessment of the alignment between the theoretical foundations of enterprise engineering and the here applied engineering approach [section 3.1]; 4) to identify areas for further scientific and engineering research [section 6]. The applied discipline of enterprise engineering includes the DEMO methodology, the software DEMO engine, the Enterprise Operating System, model simulation and validation, the derivation of high quality specifications for supporting IT systems.
This case study is not about the practice of DEMO modeling, nor the underlying theories since there is much empirical evidence for the appropriateness in many areas and the theory is well described [section 3.5]. The case study is about using the DEMO models as foundation for enterprise IT systems, how to do this, and the experiences so far.
This paper involves: 1) a description of the case [section 2] with an assessment of the specific problems and challenges that have to be met for business cases such as the one described here [section 2.1]; 3) an assessment of state of the art methodologies and best practices with their limitations [section 3]; 4) the task conducted [section 4] and the applied engineering approach [section 4.1]; 5) project results and experiences [section 5]; Future research [section 6] and 6) reflections [section 7].
This paper is partly based on scientific engineering, the discipline of enterprise engineering, but also based on many years of experience and domain knowledge of the industry. This paper represents our current personal stance and view on things, with client's interests on the foreground, and not always founded on published scientific research. The proposed approach is founded on a new paradigm and may be found controversial. It should be considered that enterprise engineering is still a young and immature engineering discipline and this is the first business case with this approach.
The Client of Formetis is a semi-public organization, Endinet BV (“client”), The Netherlands. They provide the infrastructure of electricity and gas services to their customers, which are private persons and various types of companies with a wide range of requirements. The delivery and periodical billing of these services is based on a contract signed by Client and the customers. This contract is a complex and custom made document – set of documents - that should meet various requirements, set out below.
As with most custom made services, the customer is an active co-producer of the contract. There are usually several subcontractors involved for the fulfillment of the contract. The contract covers issues such as type of services provided, costs, costs calculation methods, conditions for payments, instructions for the subcontractor, correspondence etc. Documents such as technical drawings, inspection reports, approvals originating from several sources are part of the contract or are related to this specific contract.
Special requirements and boundary conditions include: 1. Validation of the completeness and correctness of the draft contract, before sending it to the customer for his approval and signing. 2. The delivery of a contract proposition within a specified period of time after a customer's request, defined by law. 3. The contract should comply with external legal regulations and internal business policies, conditions, procedures and this compliance should be enforced, which is a GRC related topic [23], [section 3.4]. The quality of the contracts should be high; errors are unacceptable and may be expensive, incomplete transactions, deadlocks, deadline overflow, violation of business procedures etc, must be eliminated. The production of the contract is highly structured; there is a controlled sequence in the production of certain parts and there is (sometimes) an assessment and acceptance/approval step of production parts before the production may continue. 4. The possibility to modify the contract due to changing requirements from the customer during its life time, while maintaining the guaranteed coherence and correctness of the new version of the contract. 5. The possibility to modify the business process whenever needed, due to changing legal requirements or and improved way of working. This implies the need for evolving IT systems to support this agile enterprise. 6. The requirements that external parties, subcontractors participate in the execution of the contract and that the customer is also an active co-producer or subcontractor. The customer executes various roles in production, which should be modeled also. 7. The long life time of a contract; after signing it may exists for decades and may be subject to many modifications. This, and the fact that during operation the contract is the basis for production and billing, demand a high degree of continuity, maintainability and stability of the IT system over time.
The required solution is a dedicated IT system (AVS case management system) to support the production of these contracts, meeting the requirements mentioned before.
The state of the art technologies and their strength - limitations are briefly discussed below, “as is”, as stated before, from our experience and professional point of view, an opinion, not always supported by published research results.
A case management system is defined by us being “an IT system, supporting the production of tailor made services, produced by the human actors of an enterprise, in collaboration with the demanding customer, following certain rules and procedures”. The services may encompass financial services, investments products, mortgage loans, litigation cases, medical services provided in hospitals, many (governmental) services for customers, such as this case. The professional application domain is very wide and may cover industries and domains currently captured by ERP1 systems. The actual service is often some legally binding document combined with certain actions taken or “things” delivered. The service depends much on the production of documents. The services may be produced by chains of producers or sub-contractors. One of the sub-contractors is typically the customer.
Currently there is a lack of a precise and appropriate definitions. The AIIM
(Association for Information and Image Management) [
The AIIM and other parties define and describe the ways how the case management system is implemented, a “project”, “transaction”, “CRM systems”, or “help desk”, or “involve multiple persons”, or “opened and closed over a period of time”. While this is often true, this “how to” is considered not so relevant here and should not be part of a definition of what a case management system is.
There is an OMG standard for case management systems in development2. It is observed by us – our professional stance - that some of the limitations of BPMN we identified [section 3.3] (lack of formal foundations, lack of ontological qualities, concept overload, construct excess etc) also apply here. CMMN is therefor considered not (yet) good enough for our purpose.
The key notions of our case management system, presented above, definition are: 1)
the production of a specific service; 2) the production is subjected to specific
(business) rules from various origins [section 3.4]; 3) the service is tailor-made for a
demanding specific customer; 4) the customer can be an active co-producer of the
service. Our definition makes no statements on implementation choices. This
definition is compliant with, and based on the definition of an “enterprise” provided
by the discipline of enterprise engineering, Dietz J.L.G et al. [
Notation, CMMN. Version 1.0, 2014-05-05.
production, actors communicate about the production of some service for an external
customer. This notion is covered in detail in the theory of Enterprise Ontology by
Dietz [
From the above follows that a case management system is composed of two subsystems; one subsystem for implementation of business rules and procedures using some workflow-like3 system, and one subsystem for management of all types of produced documents. Our approach for a case management system is composed of a structured dossier system [section 3.2] and the enterprise operating system [3.6].
Most of today's many case management systems are essentially document-based, supporting the production of documents, and often supported by a so-called work flow system to control sequences of operations on a specific document. If the service to be provided is simple, not demanding much customer interaction, not handling many exceptions, then a document-based approach may be very suitable. Example: processing of credit card payments. If the service is complex, with interactions and contributions from several sources and sub-contractors, such as for example a mortgage loan, then a document-based approach may be found inadequate. The context of all related information carriers from many sources then becomes important to support the case worker and stakeholders well.
The concept of an electronic dossier is proposed here. It does: 1) provision of the case worker with all required information within the context of the case, in a well supporting way; 2) guarantee compliance to all applicable rules and procedures of the dossier using the first subsystem; 3) take autonomously appropriate actions when needed; 4) supports the production of documents.
An electronic dossier, is a highly contextual structured aggregation of documents, organized in such a way that all needed functional useful perspectives on the case are provides. The derivation of the structure of the documents is based on the “finegrained” DEMO models, described in section 4.1, step 2. The electronic dossier itself is a model-driven dynamic structure and supports incremental linking and embedding of new documents at run time. The built-in knowledge of the electronic dossier about business procedures and rules to be followed is described in section 3.6. 3.3
A work flow procedure is typically defined being an orchestrated and repeatable pattern of business activities, based on the systematic organization of resources4. In practice it involves a sequence of operations, declared as work of a person or group. State of the art technology is BPMN5, which provides a graphical representation of a business process. 3 The term workflow-like idicates a similar purpose but based on different principles. 4 Several definitions and 'types' of workflow exist.
While BPMN is the current de facto world standard6, there are some serious
limitations that may become problematic when dealing with these types of complex
services. In Van Nuffel et al [17] an assessment has been made of BPMN 1.0 7 and
recommendations have been made to enhance the formal foundations of BPMN 1.0.
The most important findings were: 1) the lack of ontological completeness of BPMN,
typically only the “happy flow” is/can be modeled, which means that any exceptions
in the business process are not captured and at run time a manual intervention must be
made; 2) The lack of representation of state and history in dynamic systems; 3) For
non-trivial business processes the complete work flow procedure cannot be modeled
by humans, simply because the complexity explodes exponentially; 4) The applied
symbols and concepts are not aligned with a formal domain ontology and not based
on an appropriate scientific theory. A large degree of concept overload, concept
mismatch and construct excess has been observed8; 4) There is lack of appropriate
abstractions in BPMN models, the models encompass “too much” and tend to become
too large for human understanding; 5) A lack of formal rigor; BPMN is a notation, not
a formal language. A formal language would enable the development of an software
automaton that executes models expressed in that language in a proper way. 6) As a
result, early simulation and validation of models, before any commitment of resources
to implementation and coding, is difficult or even impossible. This limitation is
considered very serious and a source of business-IT alignment problems9 much later
[
Our professional stance: For the production of complex services, BPMN is considered to be much better than other approaches in the industry, but not good enough for state of the art applications such as this case [section 2.1]. We calculated that an ontologically complete BPMN model of the 40 transactions [fig 4] of this case would require the “manual” modeling of 2080 state transitions [shown in section 3.3], which is considered 'impossible' to do and to verify for humans. Calculation of work flow should be done by a software engine using higher abstracted models.
The mentioned rules are partly in a domain encompassing three sources; GRC, the abbreviation of Governance, Risk and Compliance. The compliance of the enterprise in operation to externally imposed legal rules and regulation, is generally known as Compliance. The compliance of an enterprise to internally defined principles and rules is generally know as Governance. The identification and mitigation of risks, 5 The OMG Group, Object Management Group, Business Process Model and Notation.
http:www.bpmn.org
6 An important foundation of the state of the art is described in 'workflow management', W.
van der Aalst, K van Hee, 2002. However, we do not follow this approach or the BPMN
approach for modeling, methods and systems.
7 The current latest version of BPMN is 2.0. Some comments may not apply for version 2.0.
8 These notions are described by the Bunge Wand Weber ontology.
9 In [
The engineering approach of this case study is founded on the (emerging) discipline
of enterprise engineering ('EE'), defined in [
The methodology to devise models of enterprises is DEMO, in detail described in [
A very short overview of DEMO modeling and its symbols is provided here. DEMO is founded on four axioms. The operation axiom of DEMO states that there are actors, fulfilling actor roles, and transactions. Transactions are composed of communication between the actors about the production to be delivered, and a reference to the production it self.
The DEMO transaction axiom states that any communication between actors follows a specific well-defined pattern. 10 Comprehensive: all symbols for concepts that must be in a model, are there. 11 Coherent: semantic meaningfulness of symbols and their relations from every perspective. 12 Concise: there are no symbols of concepts in a model that are not necessary. 13 Consistent: the lack of any anomalies and contradictions.
The informal example on the right of fig. 1 shows the delivery of flowers, where 1) the customer (initiator) request flowers, 2) the producer (executor) promises the delivery of flowers, 3) the producer states that the flowers are delivered and 4) the customer accepts the flowers. This is the basic communication pattern. More sophisticated patterns exist where an executor may decline a request (“we have no flowers, I cannot deliver”) and an initiator may refuse the flowers (“these flowers are not what I want, I do not accept”).
Operation
Axiom Transaction
Axiom initiator
A0 e l o r tr o c a rq ac transaction
executor basic transaction process
T1 rq pm st ac
A1 pm st
O-phase E-phase R-phase request desired result result customer accepted accept result requested result stated promise result promised result produced state producer
The left part of fig. 1 is a formal representation that shows the symbols of the operation axiom for this transaction; the actor that fulfills the initiator role, the actor that fulfills the executor role and the transaction T1 with the communication between the actors and the production about which the actors communicate.
These actor roles and transactions are the atomic building blocks of any complex organization, as shown in figures 3 and 4, and the detail shown in fig 5 as example. The model on the top left side (Initiator A0, Transaction T1, Executor A1) is drawn using a graphical tool and is directly executed by the DEMO engine. 3.6
The foundation of our approach is the Enterprise Operating System (EOS), [
At run time (Communication and Control of Actors 1..n) complete
prescriptive control of the enterprise, with enforced compliance to a DEMO
model, which is a work flow capability, calculated from the DEMO model
instance [
Descriptive control of the enterprise, there is total knowledge of every
atomic act and fact [
DMOL XML models
Repository model rendering <-==> parsing & model building
DEMO Engine
DEMO 4 aspect models
Edit model
Model simulation Communication
& Control Communication & Control
Model Validation Results Actor 1
The DEMO engine, with its descriptive and prescriptive control capabilities of an
enterprise to a model in execution, is very similar to a computer operating system. It
provides the interface and abstractions between the hardware electronics and any
software applications, hence the term enterprise operating system (EOS).
The calculation at run time of workflow-like14 capabilities from much simpler higher
level DEMO conceptual models that overcome the before-mentioned BPMN
limitations is a major asset. It reduces the effort in coding and BPMN type of
modeling for the process aspect completely. These DEMO models, expressed in the
DMOL15 formal language, are executed by the software DEMO engine [
To summarize; the case management system is composed of two subsystems; 1) The
subsystem enterprise operating system, composed of the DEMO engine executing
DEMO models. 2) The subsystem for the management and production of documents.
14 The workflow capabilities mentioned here are based on the Language Action Perspective,
and communicative acts, provided by Habermas [
The following steps were performed for the AVS case management system. fig 3. The ontological DEMO model of a part of the organization (example).
(The yellow line is irrelevant here) 1. The project started with DEMO modeling with the knowledgeable staff, which delivered the so-called ontological model of the enterprise of fig. 3.
Fig 4. Detailed realization example – the NCD_AVS model is an implementation of a DEMO model, including infological and datalogical transactions.
Extensive shared reasoning with the staff has been done to validate that this DEMO
model (fig. 4) represents properly the service of the enterprise delivered to the
customer. This ontological model is strictly implementation-independent.
2. The second step involved a “realization” DEMO modeling step (designing a
specific implementation, one of many), based on the implementation-independent
ontological DEMO model. De Jong provided a detailed methodology to carry this out
in a systematic way [
This part (Fig. 5) has the following meaning:
Actor I-A0108 is initiator of these transactions:
- Transaction I-T0125 (“check for unfinished work”), to be done – executor - by actor
role “actor who checks any unfinished work”.
- Transaction I-T0109 (“fill out data of the type of work to be done”), to be done by
role I-A0109, actor who fills out this data.
- Actor I-A0109 is also initiator for the work described by transaction I-T0123
(“determination of excess length”), executed by actor “who decides on excess length”.
3. The third step involved the implementation in executable software in a systematic
way of the dossier system. The DEMO models provides specs for decomposition of
16 DEMO methodology identifies three types of human activities, ontological performa,
infological informa and datalogical [
The practical experiences until now are: 1. The first two steps [section 4] exploit the knowledge of key personnel and the early model validation assures an optimal business-IT alignment. The application has in essence been designed by the key staff, which almost assures acceptance for full production. The staff was strongly motivated to do this.
2. The complex document production and management software has been decomposed into 40 simple production system software components [fig 4]. Each software component is highly structured, well specified and very simple to implement in software (also model-instance-driven). Its simplicity enables easy modifications.
3. The resources in time required for the implementation in software are already less than the resources in time for the modeling stages. A further reduction in resources for software implementation is expected, a clear move from programming to modeling.
4. After acceptance testing and some time running in production, stakeholders proposed a number of implementation changes of the system and the DEMO model. These modifications were simple to implement without much impact on other software modules. The staff recognized also that the software implementation we delivered complies precisely with the models they designed and approved themselves. Their general perception is that the system is very demanding and structured in the separation of various production steps and enforces a specific way of working with little freedom. They find also that the transaction steps deviate from 'standard' GUI practice and demands many “extra mouse clicks”, which is true and will be fixed. They appreciate that ongoing modifications due to better insight are quickly implemented.
5. The communication between the actors for each production has been simplified because in a good case management system one single person – the responsible case worker - does most of the contract production work. However, the precise sequence of the production steps is well guarded and there are no anomalies or incomplete transactions. Correctly executed nested transaction rollback is assured.
6. There is no separate 'work flow’ modeling stage (BPMN etc). The communication patterns between actors and the sequence of process steps are completely calculated from the DEMO model instance under execution. A modification of the business process demands only a new DEMO model to be installed.
8. The relation between project costs and required resources versus project size, measured in number of transactions, seems to become closer to linear. This is opposed to the typical exponential ratio found so far in larger software engineering projects.
9. An important advantage is that the only remaining 'creative' phase is the modeling stage. The implementation in software leaves much less space for 'free and creative' programming choices. Software engineering for adaptive case management systems is becoming more a standard production process, as in other engineering domains and as it should be.
10. This is a project where we simultaneously build an IT system and the underlying executing software engine, a calculated risk. We missed the first deadline by a number of weeks. Some software shortcuts have been made to achieve operational functionality within the limited available time. Currently most of these have been replaced by proper software implementations, but much more work remains to be done.
The customer is satisfied, since it functions very well, adaptations are easy to implement and this is the only system in the Netherlands of this type that meets the legal compliance requirements.
Two specific topics for future empirical research are mentioned below.
The systematic derivation of high quality project specifications while using the DEMO engine to simulate DEMO models must be well supported. Simulation of DEMO models at design time identifies all specific transaction states that may occur in real life operation. For each process state a set of requirements must be devised. This includes the availability of all required information for an actor to take a justified decision for a communication act, specified in the DEMO external data banks. This must be carried out in a much more structured and systematic way than in this project.
The topic of GRC is included in this paper since there are some compliance issues, but also because this approach seems to support this important topic well [24]. Similarly to the topic before, detailed model simulation supports the identification of all possible transaction states for the whole enterprise, which must be assessed also from a risk (GRC) perspective. What are the specific risks17 from outside or inside related to any specific state? Does reaching an “unusual state” imply a specific risk, an attack from outside or inside? Is the actor provided with all information needed to carry out a communication act, but nothing more than that (need to know information limitation)? Is any actor fulfilling more actor roles and does this represent a risk if the actor is malicious? Is there any combination of two actors, assuming that they might be malicious, that are able to commit fraud or cause damage? Which actions can be designed at design time to mitigate potential hazards at run time? Process mining type of analysis in operation is considered very valuable. This type of analysis supports the validation that a specific DEMO model based operation complies with Governance principles and Compliance requirements (or not). Detailed analysis of the interaction between the enterprise of external customers is of interest to Compliance analysis. For financial services industry, the compliance to regulation coming from sources such as Basel, Sarbanes Oxley, is of such paramount importance, which merits and requires extensive research. 7
We consider the decision taken to develop the DEMO engine simultaneous with the project execution as a well-calculated risk that paid off favorably, despite exceeding the first project phase deadline for acceptance testing. Without the DEMO engine it would be impossible to design and implement such a case management system that operates so strict and precisely model driven. We might have stayed within the deadline for acceptance testing, but would have had much more rework and fixes immediately after acceptance testing due to the incomplete and lower quality project specs. The implementation of this business process of fig. 4 in BPMN is considered to be 'impossible' for humans.
DEMO modeling is considered 'difficult' for many stakeholders to capture since it is a complete abstracted representation; there is not a trace of implementation or parts of an example. Stakeholders need time and training to grasp the meaning of a DEMO model before they are able to reason about a model. BPMN models are much easier to understand because “much more”is shown. However, the high level of abstraction with formal rigor is the strongest point in complexity reduction of DEMO. 17 We consider here exclusively risk related to business procedures, human actions and communication, truthfulness, sincerity, responsibility, competence, assigned to human actors.
We do not state anything about financial and similar risks, which is outside our scope. Essentially, the followed approach is radically different from state of the art methods and best practices in four ways.
1. The first difference is the solid and systematic “engineering approach”,
provided by the discipline of enterprise engineering with its scientific, formal
foundations and engineering methodology.
2. The second deviation from the state of the art is the top-down approach, we
start with modeling the ontological enterprise. This is based on the
recognition that an enterprise is essentially a social system, composed of
human actors who collaborate (production) and communicate together to
produce some (valuable) service of production for an external 'customer'.
3. The Greek Philosopher Protagoras18 stated “Man is the measure of all
things”, which is considered to be applicable here too. Key notions are
human qualities such as responsibility (a relation from an actor to all other
actors), authority ( a relation from all other actors to a specific actor) and
competence (the assumption that a specific actor has all the required
competences needed). In addition, actors are assumed to act and
communicate in a truthful and sincere way with each other. We start with the
human qualities. Human stakeholders and actors design their optimal “way
of working”, and supporting IT systems, using DEMO. They regain freedom
over their work. This is totally opposed to for example state of the art ERP
systems that squeeze humans into their rigid application structure.
4. We abandon in this engineering approach the state of the art approach of
starting modeling business processes, in a bottom-up way using Petrinet
modeling. We also abandon the OMG approaches for BPMN and CMMN.
Three major benefits and advantages:
The first and far most important benefit is considered to be the human oriented
approach where individual humans are provided with a clear description of their tasks,
their responsibilities and competences. In addition the humans provide the essential
domain knowledge to design their enterprise. Our human-oriented approach makes
Weber-type19 of machine bureaucracies and fat layers of managers obsolete.
The second benefit is the fact that state of the art problems in IT system engineering
are addressed [
The third benefit is the strong overall reduction in complexity that can be achieved. In its current implementation the DEMO engine is not yet fully mature, some programming shortcuts have been taken, not all four DEMO aspect models have been implemented completely, and the user interface must be improved.
It should be noted that this business case is the first professional IT system case of this kind, that this approach needs much refinement and that many more business case studies are needed. The theoretical foundations of enterprise engineering are very well defined but the applied methodologies, except for DEMO itself, are still young and immature.
The application domain of DEMO enterprise operating system, combined with a case management system, may challenge to a substantial degree state of the art ERP systems and be the core production environment for financial services. We consider IT projects comparable and potentially suitable for this approach if most of the following conditions apply: 1. There is a demanding customer who demands a unique tailor-made service (or product). Within a generic type definition for the service, the provided service is a unique instance, which goes further than a selection of values for a set of parameters, such as the color and features of a car. An example is the legal requirement for the service producer to assess the personal situation of a customer, “does this service, as requested and selected by the customer, beneficial or involve potential risks and disadvantages for him?”. Part of the service is the assessment of risks, value for the customer. 2. The customer is active co-producer of the service. This extends much further than the provision of customer data. There is a dialog between customer and producer to configure the service in the best way, investigate alternatives, and eventually decide to recommend the customer not to take the service. 3. There is a set of legal requirements that have to be met. In addition, convincing evidence that the legal requirements have been met in operation for each production instance must be supplied. The same applies to (similar) governance principles that apply to the operation of the enterprise. 4. The production is business process driven, where the processes are not trivial or execute exclusively a simple happy flow of a fixed sequence of steps. When sub-contractors or the customer are involved any process is already complex and unmanageable using BPMN -type technologies. 5. The production is event driven, where events originate from many sources, sometimes in random sequence. There are many different process execution paths possible. 6. The production is document-based, optionally accompanied by specific actions, such as for example a medical treatment in a hospital.
Comparable projects can be found in financial services, legal, litigation, government services, medical treatments etc.
Formetis expresses it gratitude to Eduard Babkin, National Research University, Higher School of Economics, Nizhny Novgorod, Russia; to Sergio Guerreiro, Lusofono University, Lisbon, Portugal; and Jan Verwaest, Verwaest.biz, Westerlo, Belgium, with whom we cooperated very well and gained better understanding of this approach. 9 References 16. Krouwel, Marien and Op 'T Land, Martin, “Using enterprise ontology as a basis for requirements for Cross-organizationally Usable applications” (2012). MCIS 2012 Proceedings.
Paper 23. 17. Nuffel, van D., Mulder, H., Kervel, S. van.: Enhancing the formal foundations of BPMN using
Enterprise Ontology. In: CAiSE CIAO. (2009) 18. Mulder, J.B.F.: Rapid Enterprise Design. PhD. Thesis, Delft University of Technology. (2006) 19. Nicolas Racz, Edgar Weippl, Andreas Seufert; A Frame of Reference for Research of Integrated
Governance, Risk & Compliance (GRC), 2010. ( http://www.grc-resource.com/ ) 20. Nicolas Racz, Edgar Weippl, Andreas Seufert; Governance, Risk & Compliance (GRC)
Software – An Exploratory Study of Software Vendor and Market Research Perspectives 21. Sauer, C., Cuthbertson, C.: The state of IT project management in the UK. Templeton College,
Oxford University. (2003) 22. Standish Group,: CHAOS Summary 2009. Online:
http://www1.standishgroup.com/newsroom/chaos_2009.php (2009) 23. Vicente, P.F.O, A Reference Architecture for Integrated Governance,Risk and Compliance,
CAiSE 2011. 24. Verwaest, J. “Towards a comprehensive methodology for the implementation of Enterprise Governance & Assurance of IT, based on COBIT5, using the discipline of enterprise engineering”. 2013. MSc. thesis, Antwerp Management School.