DTGov: Digital Transformation of Government Business Processes

Nuno Marques and Andr

e Vasconcelos

INESC-ID, Instituto Superior T

ecnico, Universidade de Lisboa, Portugal

Keywords:

Digital Transformation, Government, Processes, Low-Code, Reference Architecture

Abstract:

Today, companies cannot rely on outdated systems, governments being no exception. There are multiple

beneﬁts when performing the digital transformation (DT) of its processes, but also several downsides such as

costs. This paper presents ﬁrst the main use cases: resolve a procedure, send a notiﬁcation by hand, reclassify a

procedure, and create a request, and then the reference solution divided into 3 components. First, the Domain

Model and Lifecycles related to the main entities. Second, the Reference Architecture adds the remaining

projects’ modules (Roles,...), and also the dependencies between them. Third, the Implementation presents

how to implement the information in a real-world case using “low-code” technology, especially useful to

mitigate several issues. Lastly, an evaluation of the proposed solution is also presented.

1 INTRODUCTION

Digital Transformation is crucial in today’s world, as

seen in the biggest companies like Amazon (Kimber-

ling, E., 2021), and governments are no exception.

One possible way to diminish many of the existing

problems is through the usage of low-code technolo-

gies, since they focus on the feedback approach, and

simpler development methods. One issue, however, is

that since this technology is relatively new, informa-

tion regarding its implementation in real-world sce-

narios is scarce.

With that in mind, the goal here is to explain how

to implement the DT of government processes using

Enterprise Information Management (EIM) systems

and low-code solutions. The work presented here

focuses on the employees’ application and is based

on a real-world implementation using OpenText Ap-

pWorks (OpenText, nda).

This paper ﬁrst presents the related work contain-

ing a Systematic Literature Review (SLR) that identi-

ﬁes the principal modules used in similar DTs. From

that, and the real-world implementation mentioned,

the main use cases are identiﬁed. Following that, it is

created the solution proposition, divided into 3 parts:

entity models and their lifecycles, reference architec-

ture, and implementation using low-code technolo-

gies. Lastly, there is the work’s evaluation and conclu-

sion, mentioning this paper’s main contributions and

possible improvements in future work.

2 RELATED WORK

2.1 Background

Before the presentation and explanation of the SLR

performed, some main topics, mentioned in this pa-

per, need to be acknowledged.

2.1.1 (Business) Process Management

Business Process Management ”is essential to under-

stand the steps that are ... part of a business process, ...

the people who are involved in these steps, the infor-

mation that is being exchanged and processed ..., and

the technologies that are invoked when executing the

various steps.” (Reijers, H.A., 2021) In other words,

it uses activities, tasks, and others, towards a speciﬁc

goal, for example, the payment of a procedure. Addi-

tionally, it also comprises the management, technolo-

gies, and people related to the process.

2.1.2 Low-Code Approaches

Low-code, as mentioned before, is a ”visual approach

to software development, ” (mendix, nd). This means

that programmers do not need to be highly special-

ized, which can be hard to ﬁnd and costly, and the

development of the application is usually faster, more

interactive, and more agile. Due to the visual aspect,

stakeholders can better understand what is being cre-

ated and propose changes accordingly.

Marques, N. and Vasconcelos, A.

DTGov: Digital Transformation of Government Processes.

DOI: 10.5220/0011715700003467

In Proceedings of the 25th International Conference on Enterprise Information Systems (ICEIS 2023) - Volume 2, pages 101-108

ISBN: 978-989-758-648-4; ISSN: 2184-4992

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

101

2.2 SLR: Modules Present in the DT of

Government Processes

This SLR aims to respond to the question, what are

the main modules, used by Enterprise Information

Management Systems, in the Digital Transformation

of government’s procedures/processes/functions?

The steps performed were search process (query

”((Enterprise AND Information AND Management)

AND (System OR Solutions)) AND Government

AND ((Digital AND Transformation) OR (Process

OR Automation) OR Digitalization OR Low-Code

OR (Low AND Code))”), ﬁltering process, data ex-

traction and quality assessment.

State of the Art

From the SLR performed, the information obtained

(and presented in Table 1) is used to create the fol-

lowing state-of-the-art:

Table 1: Modules present in each paper from the second

SLR.

1. Each web page should have different secu-

rity/permissions, (Aysolmaz, B. and Demir

ors, O.,

2014), to restrict each employee to their speciﬁc

task/role. The majority of the papers contain the

portal/user page, such as (Mazumder, A., 2020)

that mentions an ” eGovernance application soft-

ware that is accessible through a portal by citi-

zens” or (Paul, A. and Paul, V., 2012) that ex-

plains that the stakeholders interact with the Na-

tional portal through the internet and that portal

connects to the service providers. Another com-

mon trait is that most of them do not mention em-

ployee’s application.

2. Some entities contain a lifecycle, and documen-

tation (which can also be stored independently).

(Aysolmaz, B. and Demir

ors, O., 2014) mentions

the necessity of ”automatically generate user re-

quirements documents”. This automation is im-

portant and should be incorporated into the pro-

cess entity’s lifecycle.

3. There are also other components, such as web

components, that should be stored in a different

directory. Examples of communication technolo-

gies are web services, which are vital in busi-

ness process management, and low-coding ap-

proaches, such as when sending emails or com-

pleting payment, as cited by (Mazumder, A.,

2020) that mentions a payment service done

”through e-payment receipts portal”.

A brief comparison between EIM systems is also

performed and from it, it is understood that most low-

code solutions use the same components, (leaving up

to each government which to choose).

3 USE CASES

Each government is different, having different ways

to resolve and deal with its processes. Because of this,

and since there are multiple use cases possible, this

chapter only presents the ones deemed most relevant,

given the SLR and the original real-world implemen-

tation.

Figure 1: Use Case Diagram 1: Resolve a Procedure.

The use case Resolve a Procedure, Figure 1, is

the main one, appearing the most in the papers iden-

tiﬁed from the SLR performed, such as (Mazumder,

A., 2020), which mentions it when performing and re-

solving the marriage certiﬁcate. The goal is to resolve

a procedure. First, the employee (Revision Group)

needs to ﬁll in the necessary information and send it

to another employee (Resolution Group). This em-

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

102

ployee will then decide if the resolution is positive or

negative, ﬁnalizing with various automatic activities.

Figure 2: Use Case Diagram 2: Reclassify a Procedure.

The other use case is Reclassify a Procedure, Fig-

ure 2 which is when a procedure is not created or

classiﬁed correctly. In this case, the Revision Group

Employee sends the procedure to the Reclassify state,

where it will be changed and sent back to the Revision

state.

Figure 3: Use Case Diagram 3: Create a Request.

Create a Request, Figure 3, is the use case where

more information is necessary, for example from the

citizen or an employee. In this case, the Revision

Group Employee creates a new request, opening the

Creation Request Form and choosing the type of re-

quest (internal, external, or citizen), ﬁlling in the nec-

essary information. Upon receiving it (such as docu-

mentation), the request is completed by the employee.

The last use case identiﬁed is the Send a Notiﬁ-

cation By Hand, Figure 4, which is when the no-

tiﬁcation needs to be sent through mail or a carrier

instead of digitally. After the procedure’s resolution

is completed, a notiﬁcation is created automatically.

Figure 4: Use Case Diagram 4: Send a Notiﬁcation By

Hand.

If the citizen chooses to receive that notiﬁcation by

hand, the Notiﬁcation Group Employee will claim it

and proceed to its sending, by ﬁlling in the neces-

sary information. Upon receiving the conﬁrmation,

the Notiﬁcation Group Employee ﬁlls in the remain-

ing information and completes the notiﬁcation.

4 SOLUTION PROPOSITION

This chapter presents the solution proposed in this pa-

per, which is divided into 3 parts: Domain Model and

Lifecycles, Reference Architecture, and Application

Implementation.

4.1 Domain Model and Lifecycles

This section is divided into two, the domain model,

explaining the main entities and their relationships,

and the entities’ lifecycles, detailing the different

states and transitions.

4.1.1 Domain Model

The Domain model, Figure 5, contains four main

projects which are Common Parts, Procedures, No-

tiﬁcations, and External Entities.

They are named projects because it is the name

given by the low-code application used, AppWorks,

to designate the different parts (directories).

The Procedures Project contains the entity Proce-

dure Parent. This is the main entity, which is abstract,

and refers to the government procedures. It contains

the main properties such as procedure ID, type, and

the different departments.

The Procedure Child inherits the Procedure Parent

and adds a few new properties such as procedure child

ID and type.

DTGov: Digital Transformation of Government Processes

103

Figure 5: Domain Model.

To simplify future mentions of Procedure Child

and Parent, they will be referred as one, Procedure.

There is also the External Entities project, which

contains the information relative to each Request

from the Procedures entity. External Entities contain

the entities External Entity, Contact, and Direction.

Both the Common Parts project and Procedures

contain Standard Application Entities, which are en-

tities not created by the developers but by the applica-

tion, internally.

In the Notiﬁcations project, there are two entities,

Notiﬁcation, and OriginSystem. OriginSystem repre-

sents the system from which the notiﬁcation was ini-

tially created. The Notiﬁcation entity refers to the no-

tiﬁcations created.

4.1.2 Entities’ Lifecycles

Some entities can contain a lifecycle, which com-

prises their different states and transactions, espe-

cially if they have tasks that need to be completed,

either manually or automatically. Regarding the ones

mentioned, only Procedures (Procedure Child), Fig-

ure 6, Request Entity, Figure 7, and Notiﬁcation, Fig-

ure 8, contain them, which will now be mentioned.

Figure 6: Procedure’s Lifecycle Model.

The Procedure starts in the Initialization state,

which is where the process to initialize a procedure

is done. It comprises the retrieval of the procedure ID

from the citizen’s application, the payment conﬁrma-

tion, and others.

From this state the procedure goes to the Revision,

where the Revision Group employee veriﬁes the in-

formation referent to the procedure, adding new in-

formation if necessary. From this state, the procedure

can go to various paths, including the main one, Res-

olution, and the alternatives, such as Reclassiﬁcation.

In the Resolution State, the employee from the

Resolution Group decides the procedure’s resolution.

From this state, the procedure can go to the Post

Payment one (if further payment is required), the

Documentation state (where the documentation re-

lated to the procedure is created), or the Incomplete

state (Resolution Group employee identiﬁes missing

information, sending it back).

In the Notiﬁcation state, a notiﬁcation is created

and sent to the citizen. In the Completion State, the

procedure is completed (in the Citizens’ application),

notifying that the procedure was completed correctly

or incorrectly, and performing the last property up-

dates such as date completion.

The last two states, common to almost all states

are the Notify Citizen Application state, which is

where the citizen is notiﬁed of the (previous) state

(for example, if an error occurred which cannot be re-

solved, the citizen is notiﬁed of that) and Finalization

where the procedure in ﬁnalized in the Employees’

application, removing the ability to modify the proce-

dure and its documentation (converting all its permis-

sions to read-only).

Figure 7: Notiﬁcation’s Lifecycle Model.

The Notiﬁcations entity starts similarly to the Pro-

cedures (Initialization) but branches into 2: or it can

go to the Send state, where the notiﬁcation is prepared

to be sent to the citizen or the Send by Hand if the

communication preference chosen is to receive notiﬁ-

cations by hand.

From the Send state, it goes to the Sent, where the

notiﬁcation is conﬁrmed correctly sent and its lifecy-

cle ﬁnished.

In the Send by Hand, the Notiﬁcation Group em-

ployee revises and conﬁrms the sending of the noti-

ﬁcation (use case 4). From there, it goes to Receive

Read Conﬁrmation, where upon receiving the conﬁr-

mation that the notiﬁcation was read, the employee in-

puts the ﬁnal values such as read date and conﬁrms its

completion. The following and last state is the Com-

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

104

pleted state, where the notiﬁcation is conﬁrmed read,

and completed, ﬁnishing the lifecycle.

There is also another state, achieved from the Ini-

tialization and Send, which is the Error state, signal-

ing that some error occurred and aborting the sending

of the notiﬁcation.

Figure 8: Request’s Lifecycle Model.

The Request’s lifecycle also starts in the Initializa-

tion state, where the identiﬁcation of its type is done.

If Internal, it goes to the Pending Internal state, which

communicates with the employee or chosen group. If

External, it goes to the Pending External, where is

done the communication with the external entity. Fi-

nally, if Citizen, it goes to the Pending Citizen, which

will communicate with the citizen related to the pro-

cedure.

If no error occurred, the request, from all the

Pending states, goes to the Completed state, which

represents the request sent, ﬁnishing the lifecycle. If

not, the request goes to the Error state, ﬁnishing its

lifecycle and not performing the request.

4.2 Reference Architecture

This reference architecture contains, Figure 9, ﬁve

projects, the four already mentioned and the (Exter-

nal) Citizen Application

4.2.1 Common Parts

The ﬁrst project, Common Parts, was created with the

goal of having all the components that are common to

the various projects in a single location, in a way that

eases their usage and avoids circular dependencies,

(Russo, M. and Ferrari, A., nd). This project con-

tains the module/directory Entities, presented in the

previous chapter. It also contains the Business Pro-

cess Models (BPMs), which are the models used to

implement the government’s business processes.

The BPMs use the Web Services module, which

contains 4 types of web services, internal (created by

the application), external (from other applications),

Figure 9: Reference Architecture.

java (from the Java Metadata module), and BPM

(from the BPMs created).

Web Services use the Libraries (”collections of

prewritten code that users can use to optimize tasks”,

(Ryan, 2020)) and Schemas modules (”a formal de-

scription of the structure or organization of a partic-

ular database”, (Dearmer, A., 2021)). These can be

internal if predeﬁned by the application or external.

Another module present is the Java Metadata,

which contains the java deﬁnitions. Every pro-

gram/service that is created externally in Java (or an-

other language if that is the case) is stored here. Nor-

mally, these web services are created only if they do

not exist in the application used.

Finally, there is the Roles module, containing the

roles created, and grouping the employees. In this

project, Common Parts, there are two, the Admin-

istration Role which receives more permissions, and

Common Role which contains more generalized ones.

The following projects will not be explained in so

much detail, only being presented the differences and

important points.

4.2.2 Procedures

Regarding the Procedures project, they have the same

modules as the Common Parts but now the Web Ser-

vices module does not contain the java BPMs (since

they are in the Common Parts). This project also

presents a new role, Procedures Role, which gives

permissions related to procedures (read, write...).

DTGov: Digital Transformation of Government Processes

105

This project also contains two modules that were

not present in the previous one, which are the Web

Components and Home Pages.

Home pages are the front end of the application,

where the employees can create and resolve proce-

dures. It contains two home pages, Administration

Page, reserved only for administrative tasks and the

Administrative Role, and the Procedures Page, ac-

cessed by the Procedures role users. These home

pages can use web components which are, for exam-

ple, images related to the government.

4.2.3 Other Projects

The Notiﬁcations project contains a new role, the No-

tiﬁcations role which is responsible for the notiﬁca-

tions, and two new home pages, the Administration

Notiﬁcations Page and Notiﬁcations Page (which is

where the tasks to complete the notiﬁcation’s lifecy-

cle are done). Notiﬁcations also do not contain exter-

nal web services because they are already created in

the Common Parts.

External Entities project contains a new home

page, Administration and External Entities pages, and

does not contain Roles or BPMs (especially because

it does not have an entity with a lifecycle). The only

web services present is internal.

Lastly, there is the (External) Citizen Application,

which is a project not created in the employees’ ap-

plication but refereed in this reference architecture to

represent the citizens’ application. Here, only the web

services are relevant, being used in the other projects.

4.3 Application Implementation

Before explaining how to implement the information

presented using low-code technologies (in this case

AppWorks), ﬁrst, it is necessary to mention two other

EIM solutions, which are Active Directory (regard-

ing OpenText is called Directory Services, OTDS, and

Content Management (in this case Content Server,

OTCS, (OpenText, nda)).

OTDS allows users, in this case the employees, to

have a single sign-on on all the OpenText Applica-

tions. More importantly, it contains the possibility to

group the users and transfer that information to App-

Works, relating it to the roles module.

OTCS refers to content management. Every doc-

ument created is stored in this application, which is

connected to AppWorks.

Since the majority of the EIM solutions contain

both these applications, what is mentioned here can

be applied to them.

Regarding AppWorks, to create the various

projects, ﬁrst, it is necessary to conﬁgure and cre-

ate an organization which contains various modules

such as entities. Inside an organization, it is possible

to create a Collaborative Workspace, which is where

”all modeling activities are done” (OpenText, ndb),

the development platform.

Following that, it is necessary to create the dif-

ferent modules, which is done through a ﬁle system

where each sub-folder, from the project, corresponds

to each module mentioned.

The folder Entities contains all the entities present

in the Project, with each one containing various build-

ing blocks.

Explaining a few of them, web services include

the ones related to the entities, BPMs, or other com-

ponents/modules, and business workspace enables the

storage of associated documentation.

The transformation from the Domain Model to the

AppWorks is direct, only requiring the creation of the

Entity and the necessary building blocks.

Regarding the BPMs module, the information pro-

vided does not go in-depth because they are usually

very speciﬁc to the Government in question.

From the Web Services module, the four types and

the information on how to create them (except for the

Internal ones which are created through the Entity)

were already provided.

Other modules present are the Home Pages and

Web Components. AppWorks is divided into the App-

Works Platform, which is where the projects, external

web components such as Maps APIs, and others are.

This is the developing/administration part (the back

end). There is also another part called AppWorks Ex-

perience (the front-end), that corresponds to the inter-

face that employees interact.

The last module is Roles. Each user can be as-

signed one or more roles in the application through

a speciﬁc component called ”User Manager”. This

component contains the roles standard in the App-

Works (administrator, user...) but can also contain the

ones created inside the projects. These can have cer-

tain permissions, which can restrict the actions that

the user performs (such as access to the entity).

The idea here is also to show that low-code tech-

nologies allow the development of applications faster

and easier than using ”traditional software”, which

can help mitigate the various concerns that govern-

ments have regarding DT.

5 EVALUATION

Since the development of the software was done in

a anonymous government context (which comprised

the testing of the application), the evaluation had to

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

106

be limited. Given this and other limitations such as

the topics mentioned being niche, there are not many

participants that can evaluate what is proposed.

Mentioning that, it was divided into 3 parts.

5.1 Experts/Juniors Evaluation

This ﬁrst part was performed by doing an interview

with ﬁve participants (three experts in the ﬁeld of DT

and usage of low-code, and two juniors), where they

answered ﬁve open questions, present in the table 2:

Table 2: Experts/Juniors: Summary of the Findings.

In summary, experts mention that the information

presented allows scalability and ﬂexibility enough to

mold speciﬁc use cases. Although the information

presented is not enough, it is useful to prevent various

problems, help juniors create project demos for gov-

ernments, and to better explain the government per-

sonnel what are the goals of the project.

5.2 Developers Evaluation

This evaluation focuses on the developers (four par-

ticipants, two experts, and two juniors) responsible

for the creation of the application, that similarly to the

participants from the previous sub-section, answered

ﬁve open questions in an interview (table 3):

Summarizing, developers report that the major

problems were related to limitations, such as bugs.

Since the development was faster and could be done

in real-time with an interface, clients were satisﬁed

because they felt included and could provide direct

feedback. This, in turn, lead to more changes over

time. Both groups agreed that using low-code soft-

ware was very useful and they would choose to use

it again if given the choice, because it was faster,

easier and despite the learning curve, allowed ju-

niors to work semi-autonomous and without major

ﬂaws/errors. They note, however, that the ”tradi-

tional ways” allow a better understanding of the pro-

Table 3: Developers: Summary of the Findings.

cesses behind the development and, sometimes, a bet-

ter identiﬁcation of the existing errors. A balance be-

tween using low-code technologies and ”traditional

methods” would be ideal.

5.3 Related Work Assessment

In this ﬁnal sub-section, the goal is to compare this

paper to others (from the related work) that mention

similar DT, and, as mentioned, understand if they

could take advantage of the solution proposed here.

The only two papers chosen were (Mazumder, A.,

2020) and (Liu, C. and jun tao, X. and Lu, B., 2016)

because they are the most similar to this one, con-

taining a DT of processes and development of a real-

world application. The idea was to:

1. Compare the theory and development to the other

papers and extract the relevant information.

2. Understand if this paper could have beneﬁted

them.

3. Understand if low-code software could have ﬁxed

or mitigated issues that occurred.

The goal is to understand if this paper is useful to

other scholarly papers and real-world scenarios, and

if not, identify those ﬂaws and correct them in future

work. There are a few important parts that can be re-

trieved from the papers, such as from (Liu, C. and jun

tao, X. and Lu, B., 2016) which mentions a B/S ar-

chitecture that comprises various tiers or (Mazumder,

A., 2020) that mentions that their application follows

speciﬁc practices and standards.

Regarding this paper’s contributions to those pa-

pers, they would have allowed not only a faster and

simpler development but also improved the feedback

approach. Several concerns, such as data encryption

or network security, could all be dealt with had the

authors followed the information presented here.

DTGov: Digital Transformation of Government Processes

107

6 CONCLUSION

6.1 Main Contributions

In conclusion, from the results obtained, this paper

provides valuable information regarding the DT of

government processes, by providing a ”template” that

can be used by developers to ease and speed the de-

velopment phase. It can also help clients visualize

the work done, allowing a better understanding of the

project scope and earlier feedback. The mention of

low-code technologies also can provide mitigation of

issues that can come from ”traditional methods” such

as high complexity or time.

However, since this project was based in a govern-

ment that wants to remain anonymous and the topics

mentioned are niche in the ﬁeld of IT, a full statis-

tical quantitative evaluation was not possible. Nev-

ertheless, it was realized as a qualitative one, which

comprised a few interviews with experts and juniors

in the ﬁeld of DT. Juniors are especially useful be-

cause their answers can be extrapolated to the gov-

ernment personnel, which also lacks technical knowl-

edge. From the results, there were major takeaways.

First, the models and reference architecture presented

are easy to understand and follow from an expert per-

spective but also a junior/low knowledge one. Sec-

ond, the information here, despite not presenting new

knowledge to the experts in the area, allows them to

conﬁrm their development, systematize the DT, and

mitigate errors. It is also useful to explain this type

of DT to people not knowledgeable with these topics.

Third, the usage of low-code technologies eases the

DT and allows the mitigation of related issues.

Given these conclusions, it is safe to assume that

what is here proposed helps develop applications in

this scope, such as a ticket system that resolves vari-

ous government procedures, requested by the citizen.

6.2 Limitations and Future Work

Regarding the limitations, several were already men-

tioned, such as the information not going in-depth

which, even if it was done on purpose since the

idea was to provide a generalized view that could be

adapted to other situations, meant that it was is not

that relevant to the experts in the area.

Regarding the future work, an improved evalua-

tion should be performed. As mentioned before, it

was limited because it was speciﬁc to a niche ﬁeld,

making participants scarce, and done in a anonymous

government. Also, quantitative evaluation should be

performed (such as evaluating the response time or

number of clicks).

ACKNOWLEDGEMENTS

This work was partially supported by the EC through

project 870635 (DE4A – Digital Europe for All), and

by national funds through Fundac¸

ao para a Ci

encia e

a Tecnologia (FCT) with reference UIDB/50021/2020

(INESC-ID).

Also, a special thank you to VILT and Prof. Andr

for allowing the realization of this paper.

REFERENCES

Aysolmaz, B. and Demir

ors, O. (2014). Deriving user

requirements from business process models for au-

tomation: A case study. In 2014 IEEE 1st Inter-

national Workshop on the Interrelations between Re-

quirements Engineering and Business Process Man-

agement (REBPM), pages 19–28.

Dearmer, A. (2021). Complete guide to

database schema design. Available:

https://www.integrate.io/blog/complete-guide-

to-database-schema-design-guide/. [Accessed

September 10, 2022].

Kimberling, E. (2021). How amazon is a roadmap

for digital transformation success. Available:

https://www.thirdstage-consulting.com/amazon-

roadmap-for-digital-transformation-success/. [Ac-

cessed July 13, 2022].

Liu, C. and jun tao, X. and Lu, B. (2016). Toward in-

tegrated and automated management of government

affairs. International Journal of Hybrid Information

Technology, 9:267–278.

Mazumder, A. (2020). Marreg – marriage registration [for

a better cause]. In 2020 IEEE Integrated STEM Edu-

cation Conference (ISEC), pages 1–8.

mendix (n.d.). What is low-code? Avail-

able: https://www.mendix.com/low-code-guide/. [Ac-

cessed August 19, 2022].

OpenText (n.d,a). Opentext appworks platform. Avail-

able:https://www.opentext.com/products/listing. [Ac-

cessed July 15, 2022].

OpenText (n.d.b). Opentext appworksplatform architec-

ture. Available: https://developer.opentext.com/. [Ac-

cessed July 21, 2022].

Paul, A. and Paul, V. (2012). The e-government interop-

erability through enterprise architecture in indian per-

spective. pages 645–650.

Reijers, H.A. (2021). Business process management: The

evolution of a discipline. Computers in Industry,

126:103404.

Russo, M. and Ferrari, A. (n.d.). Avoiding cir-

cular dependency errors in dax. Available:

https://www.sqlbi.com/articles/avoiding-circular-

dependency-errors-in-dax/. [Accessed July 21,

2022].

Ryan (2020). What are libraries in programming?

Available: https://www.idtech.com/blog/what-are-

libraries-in-coding. [Accessed August 25, 2022].

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

108