System Architecture of Tax Administration Information Systems

Table of Contents

System Architecture

Once we identified the functional requirements, we should design a system architecture and chose technologies and infrastructure to put the architecture into operation. Tax administration is an extremely attractive customer for IT service providers, so there are constantly a plenty of vendors gathering around it and pitching their “greatest” solutions. Some tax administration may not have own system specialists. That makes choosing a right solution a challenging experience, and depends on studying others’ experiences, such as success stories and client references provided by vendors. Relying on this approach alone creates a risk that the project will fail amid all costs and efforts. Let us explore the primary tasks involved in designing a system architecture and choosing technologies to implement it, considering this risk.

The international standard ISO/IEC/IEEE 42010:2011 provides the following definition:

Architecture is the “fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes.”

“An architecture of an entity, expressed in one or more architecture descriptions (AD), assists in understanding the fundamental concepts or properties of the entity, pertaining to its structure, behaviour, design and evolution, such as feasibility, utility and maintainability and fundamental concepts for its development, operation, employment, external impacts, utilization and decommissioning.”[1]

Let us first list the things we do not advise to do when creating a tax administration system architecture:

Do not blindly accept technology vendors’ claims, because their objective is to make sales and get money, not to ensure that the system functions. Their bonuses depend on hitting sales targets, not on the success of the tax administration.
Do not thoughtlessly listen to your own developers. They have their own motivations for choosing certain technologies, ranging from protecting their jobs and choosing what they are familiar with, to reckless curiosity, a desire just to try something new and interesting for them.
Do not choose technologies without having solid and professional experts on your side who are committed to the project’s success. They should support, for example, in an in-house center of excellence that promotes development, implementation and maintenance of the system.

Now, we will talk about the system architecture that tax administrations should design, and the technologies required to put it into the action.

System Performance Indicators

The most important thing when designing a system architecture is to establish its purpose and performance targets:

Identify the users (internal and external), their number, and the usage profile for information systems resources (number of requests, types of requests per unit of time).
The distribution of the load on the system in terms of the number of requests per day (identify the magnitude of the maximum load and when it occurs), including the guaranteed response time.
Data volumes and data growth per unit of time, the number of records, and the increase in the number of records per unit of time. It is necessary to convert these parameters to TPS (transactions per second) values.

TPS, guaranteed system response time, and number of records are becoming the main metrics influencing the system architecture and technology choices.

System Availability Indicators

Besides the purpose and target performance indicators, a service level agreement (SLA) needs to define system availability indicators for a period (for example, 99.9%) and maximum system downtime for the period (for example, less than 9 hours per year).

We should distinguish these indicators by user groups. For tax officials who work on a strict schedule and only on weekdays, IT administrators can perform system maintenance over weekends and at night. On the other hand, taxpayers need to use tax information systems 24 hours a day, 365 days a year, and SLA indicators for them must be as high as possible.

As a result, availability indicators for taxpayers and tax officials may differ, but in both cases, we should aim for the highest values. Low availability damages the credibility of the tax administration and fosters a negative attitude for taxpayers.

Information Security Requirements

Tax administrations especially protect their data, so the system must ensure security at the infrastructure level. For example, we can create isolated network segments that interact according to certain rules. Isolated internal secure segment stores tax data. It must have no direct connection with the public-facing segment that hosts the data and application servers for interacting with taxpayers.

Information security requirements always greatly affect the system architecture and make information systems more difficult to use. This may be a tractable task for tax officials, but for millions of taxpayers it can be an exceedingly difficult and expensive problem. Accordingly, it is necessary to balance information security and convenience for end users.

Impact of the Legacy Architecture

No one ever builds tax system architecture from the scratch because every tax administration has long been using many so-called legacy applications and systems. Introducing a new system architecture is like performing surgery on a beating heart. Success requires a deep understanding of the current architecture (“as is”) and a carefully designed target system architecture (“to be”) and transition plan that does not interrupt operations or degrade existing information systems’ availability.

Check it out >

Concept of Effective Tax Administration in the Digital Era

Open-source or Proprietary Software?

When choosing technologies to implement a system architecture, the choice of software is important. Should you use technologies based on open-source software or choose proprietary software?

This should be a conscious decision by the tax administration, depending on the size of its budget and the availability of in-house experts or vendor specialists who support applications and, most importantly, support developers. It is also necessary to consider current and potential restrictions that the countries of origin of certain technologies may impose on the tax administration’s country.

This refers to general and technology sanctions imposed by national governments, as well as private sanctions when a supplier stops doing business with a certain customer.

All other things being equal, we recommend paying attention to open-source technologies, considering their growing popularity around the world.

System software

When choosing system- and infrastructure software, we should consider the following technologies:

Server operating systems.
Database management systems (DBMS), both relational (SQL) and non-relational (NoSQL) for transactional and analytical tasks.
Internet servers.
Application servers.
Message brokers with guaranteed message delivery.
Authentication and authorization, and information security systems, including support of digital signatures or their analogues.
Virtualization and containerization systems.
Application performance monitoring systems.

Open-source software is available for most of these systems. Software certified in a particular country, usually implemented to support information security. It can be proprietary or open source. Many commercial vendors provide paid technical support for open-source software.

We can recommend the following proven stack of open-source software, which we have been using in projects of varying size in terms of the large numbers of users, storage volumes, and requests per second.

	Technology	Product Examples
1	Server operating systems	Red Hat Linux
2	Relational DBMSs	PostgreSQL
3	Non-relational DBMSs (NoSQL)	Apache Hadoop (HDFS, Yarn, HBase) Apache Hive ClickHouse
4	Message broker	Apache Kafka
5	Internet server	NGINX
6	Application server	Apache Tomcat
7	Container management	Kubernetes
8	Application monitoring	Prometheus Zabbix Grafana

Table 1. System- and Infrastructure Technologies and Products Examples.

System Architecture Design Guidelines

Based on many years of experience, we recommend a centralized system architecture at the level of the tax administrations’ headquarters with territorial tax divisions using secure communication channels to access data processing centers with the computing infrastructure and information systems. To access the information systems, we recommend using a thin client and an Internet browser. This makes maintenance and deployment of software updates easier.

It is important to not design a monolithic information system architecture that will be difficult to develop and maintain. To avoid this, we suggest using a functional architecture to divide information systems into independent components that interact with each other. Such development requires more careful design, but it will pay for itself in the future.

We should carefully analyze the tax system architecture design to find all potential single points of failure and simulate the system’s behavior if any part of the system will fail. For example, when designing a centralized system, there is sometimes a desire to store all data in one physical database, so as not to bother with the organization of data synchronization.

If this database fails, there is a substantial risk of stopping all information systems. So, it makes sense to decentralize data storage during the design process.

Also, to ensure fast data access and reduce the load on central systems, it is necessary to use caching data in memory or read-write splitting. Read operations, e.g., for report-generation, can work on a read-only copy of the database.

Message queues should support interactions between architecture components. This approach saves data during system maintenance, keeps the system operational in the event of a component failure, and allows faster bringing the component back online after a failure.

[1] ISO/IEC/IEEE 42010:2022 (En). Systems and software engineering — Architecture description. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:42010:ed-2:v1:en