A Microservice-Based E-Government Service Management System Framework Using Fast Collaboration Competencies 2.0 Model

The Indonesian private sector, particularly large enterprises, already implements service management using information technology. Local governments in Indonesia are still far from fully implementing an information system for service management, particularly in the use of microservices. This research aims to develop a microservice-based e-government service management system (M-EGSMS) using microservices for the Department of Communication and Informatics in Sampang, Madura. It supports the 16th Sustainable Development Goal (SDG), Peace, Justice and Strong Institutions, with a focus on Governance. The research also aims to improve the software development methodology from Fast Collaboration Competencies (FCC) 1.0 to FCC 2.0.

The theoretical contribution of this research lies in developing the M-EGSMS framework and refining FCC 1.0 into FCC 2.0. The proposed M-EGSMS provides a conceptual basis for organising e-government service management functions within a microservices architecture, particularly for complaint handling, monitoring, reporting, notification, and user management. Furthermore, FCC 2.0 extends the original FCC 1.0 model by incorporating microservices or Application Programming Interface (API) development and API testing as explicit stages. Therefore, this research contributes not only at the implementation level, but also at the conceptual level by linking microservices, service management, and e-government development in an integrated framework.

The research question that addresses theoretical depth on service decomposition and governance principles is: Does the proposed framework offer a novel service decomposition method, new governance principles, or an integrated contribution that encompasses both?

This work offers both theoretical and practical implications by broadening the understanding of microservices, service management, and e-government domains. In practice, the Department of Communication and Informatics in Sampang, Madura, as well as other practitioners, could use the M-EGSMS for complaint handling.

Some literature related to this research analyses and discusses various opportunities and obstacles related to the adoption and deployment of microservices, given the paucity of empirical data on the subject. The paper's findings are based on in-depth interviews with 19 Information and Communication Technology (ICT) architects with substantial backgrounds in middleware, large-scale corporate systems, service-oriented architectures (SOAs), and, to a lesser degree, microservices [1]. Furthermore, this paper presents the concept of an Infrastructure Intelligent Service System from an information-flow perspective to enable intelligent infrastructure management. It is based on research on infrastructure digitalisation and the integration of construction and maintenance [2]. Additionally, the research outlined six specific research challenges to get things started: (1) feature identification; (2) variability modelling; (3) variable microservice architectures; (4) interchangeability; (5) deep customisation; and (6) re-engineering a Software Product Line (SPL). Our goal is to avoid reinventing concepts from one area of study to another by using these issues as a springboard for future research in this area of study [3]. Furthermore, Universitas Muslim Indonesia (UMI) has created many applications to facilitate internal and external management of the campus's digital information and management systems. However, these apps were not well-suited for continuous use due to their complexity and lack of integration. Thus, by applying microservices, UMI hopes to develop a fully connected and well-managed campus information system. Using the microservices concept, large applications are broken into smaller, networked components [4]. This project aims to use the web service implementation methodology to develop an e-course learning management system that uses web services to enable online learning. MySQL is used for the database. Eventually, this application will serve as a tool to support online education; members, or users, will act as student actors and administrators, handling mentor and course data that will be visible [5]. This research described the SigSaude information system, used in student-run clinics to administer health services and store electronic medical data [6]. In this research, a new microservice reliability model (MSRM) for health information system (HIS) is proposed, based on the Predicate Petri net (PrT net) formalism [7].

This study proposes a distributed microservice-based architecture. This design is scalable because it breaks down complex professional analytic functions into microservices that can be deployed across multiple machines in various locations [8]. The website provides access to the certification data procedure. Often constructed using a monolithic approach, which entails a large package including an application [9]. To make the enterprise's original enterprise resource planning (ERP) system compatible with the new system and progressively upgrade its functional modules, this study employs Docker [10]. This study aims to provide a preliminary system design, along with a thorough description of the specification criteria, so that the decision support system can be designed as expected in the space science centre environment [11]. Additionally, the goal of this research is to highlight the primary security features of this architecture in the current cost-effective period [12]. This research describes the system's primary realisation and approach. Front-end and back-end decoupling has significantly increased the system's load capacity, and the system performs well, demonstrating the benefits of microservices and front-end/back-end separation in design [13]. The research then delves into the growing security solutions enabled by microservices, namely for legacy systems already in place, as well as the latest technical trends as seen through the organisational perspective of new development components [14]. This study aims to systematically identify, classify, and compare the body of research on microservices and cloud applications. We have conducted a systematic mapping of 21 selected studies published between the last two years and the end of 2015, since the microservices pattern first appeared [15]. This paper presents a systematic mapping study on microservices. It aims to identify emerging trends, potential research gaps, the motivation for microservice research, and current trends in this field [16]. This paper presents a classification framework for research studies in microservices architecture, a systematic map of the current research landscape, an assessment of the potential for industrial adoption of research outcomes, and a discussion of emerging findings and implications for future research [17]. This study aims to conduct a structured literature review concerning current research on Information Technology Service Management (ITSM) and Information Technology Infrastructure Library (ITIL). The review results indicate that motives, critical success factors, implementation status, and benefits are the most frequently investigated topics and warrant further investigation [18]. This paper presents a systematic mapping study on microservices architectures and their implementation. Our analysis focuses on the architectural challenges, architectural diagrams/views, and quality attributes related to microservice systems [19]. This paper presents an integrative review of the literature on the quality of e-government services, providing a basis for further development of related models and ontologies. We consider 18 approaches concerning the quality of service in the broad public sector and specific areas of e-government. We then categorised those as introverted and extroverted depending on their focus of interest on either organisational matters or the front end of service [20]. The research results showed that a microservice-based API could enable data interoperability among e-government services and be developed using multiple programming languages and base codebases. This API can be further enhanced by adding more data objects, using Amazon Web Services (AWS) Cognito for managing authorisation, integrating AWS Elastic search to load and filter data, and showing real-time data objects on the front end [21]. This paper presents a method for objectively evaluating the change in service quality resulting from implementing e-government projects. We specifically propose the Analytical Hierarchy Process as a tool to assess e-government-induced alterations in public service quality [22]. This research aims to develop a service design for an e-government framework that supports the Indonesian government in addressing issues arising from platform and application diversity. This paper presents the conceptual services of the Travel System using a SOA with Enterprise Service Bus (ESB) technology. It comprises a variety of services and business activities that can be combined [23]. This study aims to assess Data Quality Management (DQM) maturity, offer best practice recommendations, and develop a practical improvement plan with organisation-tailored indicators, a gap not addressed by earlier research. This study proposes three plans to enhance DQM by addressing 49 identified weaknesses. These are to be adopted progressively and sequentially over three years [24]. This research developed an IT service system in line with the company's requirements. This result can serve as the foundation for IT service development at an outsourcing security company. During this research, stakeholder involvement has been most significant; all deliverables have been validated and verified by stakeholders [25]. The suggested method can improve the reusability of microservices and thereby increase the application's concurrency, thereby improving performance [26]. This project proposes redesigning the official SBD website to improve the quality of information dissemination and the user experience. Web development is founded on the user-centred design (UCD) methodology. UCD also allows for the identification of the user and the respective requirements more comprehensively. One example is the inclusion of specific requirements for people with colour blindness and dyslexia on the new SHD website [27]. The research explored factors that influence e-government adoption in Indonesia. Policymakers and government institutions need to enhance the system [28]. This study seeks to analyse the impact of government intervention. The influence of unemployment and spending on the Indonesia Human Development Index (IHDI) in Indonesia between 2010 and 2013. The method of analysis employed in this case is fixed-effects regression [29]. There is also a reference to the FCC 1.0 model [30]. Also, there is research on measuring effectiveness using the revised DeLone and McLean IS success model [31]. Additionally, research examines factors and social media in digital government [32].

Table 1. Categorization of the literatures

The literature review could be categorised into five main groups according to the focus as shown in Table 1:

1. Microservice architecture, technical transformation, and adoption.

This literature examines the concept, architectural benefits, implementation challenges, adoption, and transformation from monoliths to modularity, scalability, and reusability of microservices. Microservice architectures facilitate integration across distributed systems.

2. Applications of microservices in specific domains.

Furthermore, domain-specific implementations address operational challenges in education, healthcare, and public administration.

3. Public digital services and their interoperability.

The reviews capture e-government systems, interoperability, citizen-centeredness of digital services, and service quality,

4. IT service management and quality governance.

The referenced studies cover service management and handling data quality. Furthermore, the studies examined monitoring, evaluation, and management dimensions of the systems.

5. Microservices as the supporting systems.

The studies capture the role of microservices as supporting systems in the governance and coordination of public service systems.

Moreover, the critical analysis of the literature is presented below. The literature captures implementation, architecture, service quality, interoperability, and IT governance. Therefore, microservices are part of broader digital transformation, not only a technical architecture. However, some studies capture microservices, while others examine web services, data quality, IT service management, SOA, public service quality, and digital government. These are related areas, but they are not interchangeable.

The literature focuses on architecture rather than operational aspects. Also, the studies examine the benefits of microservices on scalability, modularity, interoperability, maintainability, decoupling, reusability, and system improvements. Therefore, microservices are the solution for integration and disconnected problems. However, there are limited studies to prove that microservices improve service performance and outcomes after deployment.

Reviews show that microservices are promising; however, the field is still developing in various aspects, including methodological ones. Furthermore, microservices are applied in some domains, such as education, healthcare, enterprise systems, science, and others. However, there is a problem of transferability. The microservices system that works well in a non-government organisation might not automatically work in the same way in a government system. Government systems have higher security and compliance concerns, broader citizen-friendly and accessibility requirements, stricter accountability, and more complex stakeholders. The literature shows that interoperability in microservices applications is not only a design problem but also a governance and institutional coordination problem. Microservices security is important, as an attack could happen across multiple services, APIs, containers, and communication channels. However, it seems security is still a supporting issue in the literature. Overall, microservices are a widely promising architecture for addressing complexity and integration problems nowadays. Furthermore, they require service coordination and interoperability when applied across domains to improve service quality and effectiveness in government systems.

This work includes an introduction, literature review, research methodology, results, discussion, and conclusion.

This research developed an M-EGSMS for the Department of Communication and Informatics in the Sampang region, as shown in Figure 2. Previously, the department lacked a service management system to handle hardware, software, network, and other infrastructure issues in the Sampang government.

2.png

Figure 2. Interface of microservice-based e-government service management system (M-EGSMS)

First, the existing conditions have been identified based on interviews with staff of the Department of Communication and Informatics in Sampang, Madura, and the results are:

(a) There are ICT services, which are not yet detailed.

(b) There is no procurement or data collection for the application yet.

(c) Application issue reporting exists; however, instant messaging integration (e.g., WhatsApp) is lacking.

(d) Report on network service.

(e) There was no add or remove application feature.

(f) There is a need to prepare a form of response as evidence.

(g) There is a need for a special application from the Department of Communication and Informatics in Sampang, Madura, that can be reported if there is trouble.

(h) Data collection or backup of all new application procurements from the Department of Communication and Informatics in Sampang, Madura, or other departments.

(i) Application onboarding procedures currently rely on informal messaging channels.

(j) Application development needs a formal letter signed by the Head of Department.

(k) The report should be for every department, application, issue, week, month, and year.

(l) There are existing data, such as related departments, application data, and network complaint data.

The system also requires additional features, such as WhatsApp notifications, an API, and the ability to upload action evidence or progress updates until completion.

Furthermore, Figure 3 presents the system use case diagram. The system includes actors such as the super admin, the operator or admin of the Department of Communication and Informatics, the head of the Department of Communication and Informatics, and other departments. Moreover, the super admin has access to the right data, registered applications, registered department data, and login. The operator or admin can log in, view the number of reports, manage complaint data and reports, and view registered accounts. The head of the Department of Communication and Informatics can also log in, view report notifications, and submit complaints. Additionally, other departments can log in to manage account registration, reports, and complaints.

3.png

Figure 3. Use case diagram

Moreover, Table 2 presents the system requirements of the system, where the super admin manages all system and application registration, and the admin of the Department of Communication and Informatics can delete, update, and search for all application data and see the number of complaint data for each day, month, and year, as well as statistics of data submission and registered applications. Additionally, the Head of the Department of Communication and Informatics can search application data, view complaint data, and report on applications. Other departments can also search existing application data, select the complained application, enter complaint data, and submit the complaint-related report.

Table 2. User requirements

Furthermore, Figure 4 presents a sequence diagram of the input reporting data, which consists of logging in with a registered user account, then navigating to the user dashboard and opening the report menu. The user can then add a complaint report and enter evidence data into the report form. The system then submits the new data with a new report status.

4.png

Figure 4. Sequence diagram of input reporting data

5.png

Figure 5. Sequence diagram of the management of report data

Moreover, Figure 5 shows the sequence diagram for managing report data. It starts by opening the operator user’s dashboard. Then, the operator enters the incoming report data. This stage includes adding a complaint report, viewing report details, and viewing report history.

Additionally, Figure 6 shows a sequence diagram for reporting. It starts with the incoming report, and then the system validates the complaint data. If the data is valid, the admin or operator reviews the report. Additionally, if the report is accepted, the system follows up on the complaint with related actions and continues to resolve it. Moreover, if the report is not accepted and the data is invalid, the admin or operator will update the report data and synchronise the statistics.

6.png

Figure 6. Sequence diagram of reporting

Table 3 presents the API key as one of the service security measures, shared with permitted third parties to access the service through the API. Technically, when a client requests to post/get data through the API, it uses the previously obtained API key. After that, the server checks the API key; if it is valid, the process continues. However, if it is not valid, the process will be refused.

Table 3. Application Programming Interface (API) key

When the API is accessed successfully, the log is saved to the API request log, including the API key, request method, endpoint, and creation date. Figure 7 presents the JSON format for the API response.

7.png

Figure 7. JavaScript Object Notation (JSON) format for Application Programming Interface (API) response

Moreover, Table 4 shows the API request log, which includes API key data such as ID, API key, request method, endpoint, and creation time. The API key will be updated periodically and randomly. The user periodically retrieves the API key and stores it in the system for security reasons. Although API logging has been implemented to support service monitoring and traceability, this research has not yet carried out a statistical analysis of the generated log data, as the current log records were captured primarily during the functional testing phase rather than over a sustained period of real operational use.

Table 4. Application Programming Interface (API) request log

Therefore, interpretation of system behaviour based on API logs remains limited and preliminary. Future research is expected to analyse the log records quantitatively once sufficient operational data has accumulated, examining:

(1) Request distribution, such as the frequency of calls per endpoint and per time interval, to identify usage patterns and peak-load periods;

(2) Response characteristics, including the proportion of successful versus failed responses per endpoint;

(3) Error patterns, such as the most frequent error types, invalid API key, malformed request, and whether errors cluster around specific endpoints, time periods, or client sources. This quantitative log analysis would complement the architectural and functional evaluation presented in this study by providing empirical evidence of actual API usage behaviour under real deployment conditions.

Moreover, Figure 8 presents an API test that simulates an action performed by an external system to access the API and view complaint data previously entered in the main system. In addition, Figure 9 illustrates the complaint data results in graphical form. Figure 10 shows the API for retrieving user IDs and their metadata, including category, application name, complaint, status, and other relevant fields. Figure 11 presents the API test results, including user ID, token, ID, creation date, category name, application name, complaint, file, and status.

8.png

Figure 8. Application Programming Interface (API) test to view the existing complaint data

9.png

Figure 9. Data statistics from testing

10.png

Figure 10. Application Programming Interface (API) testing with user ID = 5578

11.png

Figure 11. Data analysis from testing

Additionally, Figure 12 shows API testing for retrieving complaint data across several applications, such as application name, address, institution, and other related information. Figure 13 presents the retrieved complaint data, including ID, application name, platform, address, and department name. Furthermore, Figure 14 shows API testing for adding complaint data, including user ID, complaint content, category ID, and other required fields. Figure 15 presents the results of the add-complaint test, including user ID, application ID, institution ID, category ID, and other relevant information.

M-EGSMS is essential for managing IT services, especially when using microservices. Furthermore, the system provides some core services as follows:

•Incident management: Manages knowledge management, assignment, reporting, and resolution of incidents.

•Problem management: Identifies and fixes underlying issues by analysing incident patterns.

•Change management: Controls IT service modifications to ensure no disruption.

•Service request management: Responds to routine service inquiries.

12.png

Figure 12. Application Programming Interface (API) testing to retrieve complaint data in each related institution

13.png

Figure 13. Data analysis from testing

14.png

Figure 14. Application Programming Interface (API) testing for adding complaint data

15.png

Figure 15. Added data analysis

Moreover, the core components include incident, problem, and change management, as well as configuration management and reporting and data analytics to support decision-making.

Microservices-based systems offer benefits such as scalability, resilience, flexibility, and cost efficiency. Scalability means services can scale independently and utilise resources efficiently. Moreover, resilience means one service failure does not affect others. Additionally, flexibility means it allows diverse tech stacks. Cost efficiency also means resource optimisation reduces operational expenses. However, challenges and complexities remain, including managing distributed systems, ensuring data consistency, testing complexity, and the overhead of maintaining service interdependencies and security.

Two testers tested M-EGSMS on 25th October 2024. The M-EGSMS was also tested, and a sample of the report is presented in Table 5. There are five test cases of testing as follows:

1. Register as a guest
2. Simulation of an application complaint
3. Simulation of an application request
4. Simulation of an application feature addition Log in as an operator to give a response

Table 5 indicates domains that need refinement and defect detection. Conflicting or duplicate data processing can occur due to concurrent operator logins from multiple devices. Therefore, defect reporting should be followed by root-cause analysis, corrective response, and post-fix validation. It is necessary to validate that the login/session management mechanism avoids conflicting parallel access and duplicate input.

Table 5. Sample of testing report

16.png

Figure 16. Microservice-based e-government service management system (M-EGSMS) framework

Based on this research, the M-EGSMS Framework is developed as shown in Figure 16. The system starts receiving incoming complaints from the external system. It then adds, stores, and manages complaint data on the server and in the existing system. The existing system can also access the complaint data through the microservice/API.

The proposed framework adopts a layered microservices architecture for e-government service management, where citizens submit complaints and public service requests through a unified API Gateway that serves as the main entry point for request routing, security control, authentication, and access management. Within this architecture, the system is decomposed into independent microservices, including complaint management, user and profile management, workflow coordination, notification handling, and analytics, so that each service can operate, scale, and evolve according to its own business function. To support dynamic interaction among distributed services, the framework incorporates service discovery to enable automatic service registration and instance lookup, improving flexibility, interoperability, and fault tolerance. The framework also applies data partitioning through a database-per-service approach, where each microservice owns its data repository to reduce coupling, strengthen autonomy, and support independent maintenance and scalability.

Under the database-per-service approach, each microservice exclusively owns its schema and data store, enforcing encapsulation and preventing direct cross-service database access. Consequently, inter-service data consistency is maintained via API-mediated communication through the Unified API Gateway, balancing strict ACID consistency with service autonomy and scalability.

Beyond access control, microservice governance in M-EGSMS also encompasses API versioning to manage backward compatibility as services evolve, service-level policy enforcement at the Unified API Gateway (e.g., rate limiting and request validation), and lifecycle management for service registration and deregistration through the service discovery component. These governance mechanisms are essential to maintain consistency, traceability, and controlled evolution as new services are added or existing ones are modified.

In addition, the deployment topology organises the architecture into client, gateway, service, and data layers deployed on container-based infrastructure or orchestration platforms such as Kubernetes, which enhances system availability, resilience, and operational efficiency. Within this deployment topology, the orchestration layer handles container scheduling, horizontal scaling of service instances based on load, health-check-driven fault recovery, and rolling updates without service downtime. This orchestration capability is essential for the microservices layer, where independently deployed services (complaint management, user and profile management, workflow orchestration, notification, and service discovery) must be coordinated reliably despite operating as separate deployable units.

Overall, integrating API Gateway control, service discovery, domain-oriented microservices, partitioned data management, and a scalable deployment topology provides a modular, implementation-oriented foundation for modernising e-government service management and integrating it with existing government information systems.

Service decomposition in M-EGSMS follows three operational criteria. First, functional cohesion groups operations that share a single business purpose and are frequently invoked together into one service; for example, complaint intake, validation, and status tracking are cohesive functions kept within the Complaint Management Service rather than split further, since separating them would introduce unnecessary inter-service calls for a single logical operation. Second, business capability boundaries align each service with a distinct organisational responsibility rather than a technical layer; for instance, user authentication and profile data are grouped under the User and Profile Management Service because they represent a single capability (identity and profile ownership) independent of how complaints or workflows are processed. Third, autonomous service design requires each resulting service to own its data exclusively and be independently deployable and scalable; this criterion drove the separation of Workflow Orchestration from Notification, since workflow state transitions and outbound notifications have different scaling profiles and failure characteristics and therefore should not share a deployment unit or database. Applying these three criteria to the department's core functions yields the six services shown in Figure 16 and Table 6: Complaint Management, User and Profile Management, Workflow Orchestration, Notification, Service Registry, and Service Discovery, each corresponding to a distinct business capability with minimal inter-service coupling.

Table 6. Service decomposition mapping

The deployment strategy of M-EGSMS follows a container-based approach, in which each microservice, such as Complaint Management, User and Profile Management, Workflow Orchestration, Notification, Service Registry, and Service Discovery, is packaged into an independent container image with its own runtime dependencies and configuration. Each service is containerised using Docker and deployed to a Kubernetes cluster managed by the Department of Communication and Informatics. The deployment workflow proceeds in stages: (1) building and versioning the container image for each service after implementation and API testing are completed; (2) deploying the image to the target environment, where the Unified API Gateway is updated to route requests to the new service instance; (3) performing a health check to confirm the new instance is responding correctly before directing production traffic to it; and (4) retaining the previous container version to allow rollback in case the new deployment introduces errors. Services can be deployed and updated independently, allowing individual services, such as notification, to be redeployed without affecting the availability of others, such as complaint management. While the current implementation runs on the existing setup, the architecture is designed to be compatible with container orchestration platforms such as Kubernetes for future production-scale deployment, supporting automated scaling and fault recovery.

In M-EGSMS, a single business process, such as complaint submission, spans multiple independent services: the complaint management service, which records the complaint; the workflow orchestration service, which routes it for review; and the notification service, which alerts the relevant staff. Because each service owns its own database under the database-per-service approach, this process cannot rely on a single atomic transaction spanning all services. Instead, M-EGSMS manages cross-service transactions using an orchestrator-coordinated Saga pattern via the workflow orchestration service, in which each service performs its local transaction and publishes an event indicating success or failure, allowing the next service in the sequence to proceed accordingly. If the notification service cannot deliver an alert after a complaint has been recorded and routed, it triggers a compensating action rather than attempting to roll back the entire distributed transaction. This approach favours eventual consistency over strict atomicity: each service's local data remains consistent immediately after its own operation, while overall workflow consistency across services is achieved progressively as compensating or corrective actions complete.

The testing in this research should be regarded as an initial functional validation of the M-EGSMS prototype. The evaluation primarily emphasised API testing, feature validation, and defect identification through representative test scenarios conducted by two expert testers. Although this testing was adequate to confirm the basic functionality of the proposed framework, it is insufficient to provide a comprehensive assessment of performance, scalability, and concurrency within a distributed microservices environment. In particular, the scope of the present research did not include stress testing, load testing, or systematic multi-user concurrency evaluation. Therefore, future research should broaden the evaluation by expanding the range of testing scenarios, involving more participants, and incorporating quantitative performance analysis under realistic workload conditions.

Furthermore, to strengthen the empirical validation of the proposed M-EGSMS framework, the evaluation should include performance metrics covering response time, throughput, and scalability. In particular, response time should be measured in terms of the average, median, and 95th percentile response time, and should be recorded separately for each core endpoint, such as complaint submission, complaint retrieval, user login, and reporting, so that performance can be examined per functional service rather than as a single aggregate figure. Moreover, throughput should be evaluated in requests per second and completed transactions per minute, along with the error rate under load, to indicate the system's request-handling capacity and reliability as demand increases. Additionally, because M-EGSMS adopts a microservices-based architecture, assess scalability by observing performance under increasing numbers of concurrent users (e.g., 10, 50, 100, and 200 users) and by examining whether adding service instances improves throughput or stabilises response time. Where available, CPU and memory utilisation should also be recorded to provide further insight into resource consumption under varying workloads. These metrics matter because they show not only the framework's functional correctness, but also its operational feasibility for deployment in real e-government environments.

The present research mainly focuses on the architectural design, system performance measurement, and functional validation of the proposed M-EGSMS framework. The study has not yet obtained quantitative user feedback through a structured evaluation instrument. The current testing instead relied on expert-based functional validation, which is appropriate for confirming system correctness but does not capture end-user perceptions of usability, satisfaction, or perceived usefulness. Therefore, the findings on usability and user acceptance remain limited and should be considered preliminary. Future research is expected to include a questionnaire-based user evaluation involving both citizens submitting complaints and staff of the Department of Communication and Informatics who operate the system, using a validated instrument such as the System Usability Scale (SUS) or a Technology Acceptance Model (TAM)-based questionnaire covering perceived usefulness, perceived ease of use, and behavioural intention to use. A minimum sample of 30–50 respondents across both user groups would allow descriptive statistical analysis, such as mean usability scores and item-level ratings, to complement the functional and architectural evaluation presented in this study and provide a more complete assessment of M-EGSMS from both technical and user-centred perspectives.

Table 7. Comparison between FCC 1.0 and FCC 2.0

This research also improved the FCC 1.0 Diagram into FCC 2.0, as shown in Figure 17. The proposed FCC 2.0 consists of several stages: user requirements, system design, mock-up/prototype development, implementation, system detailing, microservices/API development, user feedback, system testing, API testing, deployment, and maintenance. As shown in Table 7, additional stages include microservices/API development and API testing.

17.png

Figure 17. Proposed Fast Collaboration Competencies 2.0 (FCC 2.0) model

Furthermore, Table 8 compares this research with other research. The four studies represent distinct approaches to advancing e-government services, differing sharply in research focus, architectural design, and treatment of interoperability as explained below:

1) Research focus: M-EGSMS is implementation-oriented, centred on building a working microservices-based complaint management system and generalising the development process itself through FCC 2.0. This contrasts with study [33] and study [34], which are technology-adoption studies that examine how and to what maturity level blockchain and AI, respectively, have been applied in e-government contexts, rather than delivering a new system architecture. Study [35] departs furthest from the others, focusing entirely on citizen behaviour rather than any technical system.

2) Architecture: M-EGSMS is the only study among the four with a concrete, layered technical architecture, such as client, gateway, service, and data, backed by an explicit service-decomposition rationale and a defined deployment model, such as containers/Kubernetes. Study [33]'s architecture is structural but domain-specific to blockchain components, such as network, consensus, and ledger, and study [34]'s is similarly technology-specific, centred on AI/deep-learning infrastructure. Study [35] has no technical architecture at all.

3) Interoperability: Three of the four studies treat interoperability as a core design concern, but through different mechanisms. M-EGSMS achieves it via API-based integration and service discovery; study [33] achieves it via a shared blockchain ledger enabling trusted cross-agency data exchange; study [34] achieves it via a centralised AI-enabled hub connecting heterogeneous systems and legacy platforms. Study [35] is the outlier as it does not address interoperability at all, since its unit of analysis is the individual citizen, not the system.

Overall, the comparison shows that e-government research spans a spectrum from purely behavioural/adoption studies [35] to technology-specific architectural studies [33, 34] to a full implementation-and-methodology contribution (M-EGSMS). This positions M-EGSMS's contribution as distinct in scope: unlike studies [33, 34], which centre on a single enabling technology (blockchain, AI), M-EGSMS proposes a general-purpose architectural pattern (microservices) paired with a reusable development methodology (FCC 2.0), making its contribution both technical and methodological rather than technology-adoption-focused.

Table 8. Comparison with other studies

Moreover, there were some challenges in the M-EGSMS development process, such as:

•Junior programmers with minimal experience, who have slowed M-EGSMS development and have difficulties writing efficient and bug-free code, as well as not understanding basic principles of a good software development process

•Slow input of data from the staff of the Department of Communication and Informatics in Sampang.

Furthermore, there are some proposed solutions to overcome the challenges above as follows:

•Code review regularly, as junior programmers need to be monitored and send a daily report to mitigate errors earlier

•Manual and beta testing by the quality assurance team and selected users to detect bugs

•Detailed and complete testing scenarios to anticipate various situations that are experienced by the system