Technology Solutions for Decentralizing Government Financial Management Information Systems (FMIS) class=

Technology Solutions for Decentralizing Government Financial Management Information Systems (FMIS)

FreeBalance white paper explores the advantages and disadvantages of 3 technology solutions for decentralized implementations: how best to support remote access capabilities in governments experiencing low population density and sub-optimal connectivity

Introduction

Unique FreeBalance Experience

FreeBalance is a global integrated provider of Government Resource Planning (GRP) software and Public Financial Management (PFM) services. In addition to providing both products and services, something few vendors do, the company developed the comprehensive FreeBalance Accountability Suite specifically for governments. The experience with this first global Commercial-Off-The-Shelf (COTS) GRP deployed in 30 countries, and the laser focus on government gives the company a unique perspective.

As a social enterprise and UN Compact member, it is the FreeBalance mission to bring robust technology and focused consulting to help governments achieve sustainable growth. Many Emerging Market and Developing Economy (EMDE) countries leverage the FreeBalance Accountability Suite to improve PFM outcomes.  This enables FreeBalance to understand technology and PFM linkages in a variety of situations.

Integrated public finances across low density large territories is one of less common situations encountered. Many advanced and middle income countries enjoy excellent and redundant telecommunications bandwidth. The FreeBalance experience in Mongolia and the Canadian Territory of Nunavut is valuable for any government with constrained telecommunications. It is also beneficial for decentralizing public finance functions.

There are four main approaches for governments to acquire Financial Management Information Systems (FMIS):

  1. COTS GRP: enterprise-class software, like the FreeBalance Accountability Suite,  developed exclusively for government and public financial management, often referred to as “Best-of-Breed”
  2. COTS ERP: Enterprise Resource Planning software developed for the private sector with add-on functions to support the “public sector vertical industry”
  3. Government Custom: Custom software designed by governments who take on the entire Software Development Life Cycle (SDLC) responsibilities 
  4. Custom Software Consultancy: Custom software designed by a third party on behalf of government requirements

Although the trend is for governments to adopt COTS solutions that are more robust, adaptable, and comprehensive than custom options, technology architecture selected plays enabling or inhibiting roles. All options have technology architectures. Technology architectures differ within options.

Technology Architectures Matter in Public Financial Management

Some technology firms have expertise in deploying complex decentralized systems on effective telecommunications backbones. These firms have less understanding of the PFM implications of decentralized technology solutions with constrained connectivity. Governments seek cost-effective technology architectures aligned to telecommunications and public finance realities. 

A cost-effective and efficient technology infrastructure for most enterprise software requirements like procurement or Customer Relationship Management may lack cost-effectiveness and efficiency for financial ERP. Record locking, transaction confirmation, duties segregation, data validation and integrity, among other factors, are more critical in financial management when deployed in a decentralized fashion. And, effective financial ERP technology infrastructures for the private sector may not be effective in public finance because of the addition of budget and commitment controls. For one thing, any latency in confirming commitments and obligations across governments could result in invalid transactions. This latency would not negatively affect private sector accounting integrity. 

Enterprise-class COTS software systems, whether ERP originally designed for the private sector or GRP designed for the public sector, are built on software stacks. A software stack includes databases, programming languages, transaction management, and other forms of middleware. These cover the data, logic, and presentation layers for any enterprise-class software application. And, these software stacks have decentralized technology implications. In other words, choices made by COTS enterprise class software vendors help or constrain government decentralization in telecommunications-constrained environments. 

White Paper Objectives

This paper examines the need for decentralized Financial Management Information Systems (FMIS) to support public finance reform. Evaluation criteria for technology architecture and network solutions are provided. Three main alternatives are evaluated.

Government professionals can leverage this paper to identify advantages and disadvantages for technology network architectures in context to country telecommunication conditions. 

Why do some governments need to support technologically decentralized government Financial Management Information Systems?

Why is fiscal decentralization a growing trend?

This significant trend has been driven by the need to improve citizen services especially in large countries. Local public servants are more likely to understand the citizen context to make better decisions. Effective FMIS systems provide automation and fiscal controls to handle routine tasks. This reduces the burden on finance ministries who can leverage analytical capabilities to understand the fiscal impact of policy suggestions, build better budgets, forecast budget and cash surpluses and deficits. Decentralized budget entities like line ministries, agencies, and sub-national governments can take on intermediate fiscal tasks in line with capacity building. For example, line ministries and sub-national governments in Kosovo are able to make routine budget transfer decisions bound by rules and controls. Central treasury in Kosovo handles more complex, and far less frequent, budget transfer requests. That leaves more time for cash management and budget planning tasks.

The public finance approach to decentralization differs among countries. Some countries have unitary governments like in Mongolia. Other countries, like Canada, operate with a federal system. Many regions (states,  provinces, territories), like the Territory of Nunavut (2,038,722 km2), are larger than many countries. These sub-national governments seek to improve the stewardship of public funds within the telecommunications context. 

Improvements in many telecommunications infrastructure in bandwidth-constrained countries and sub-national regions are expected in the future. This will change the cost/benefit analysis of technology architecture decisions. Much like PFM reform, telecommunications architecture is more of a path than a destination.

Why does poor connectivity limit many governments from supporting fiscal decentralization through FMIS technology? 

The digital divide: digital and computing divide among countries and within regions in countries, restricts PFM reform aspirations 

Government offices in EMDEs experience sub-optimal connectivity, particularly in countries with low population densities. Also, many advanced economies have poor internet coverage in large areas with low population densities like Australia, Brazil, Canada, and the United States. 

Even with good telecommunications infrastructures in countries, COTS software architecture can increase costs unreasonably.  That is because these vendors adjust technology infrastructure design to support “use cases” including:

  • Small to large bandwidths
  • Few, occasional to major losses in connectivity
  • Variability in user activity where peak activity can be slightly higher to orders of magnitude higher than average activity 
  • Minimal computing infrastructures to redundant infrastructures
  • Open systems to support a broad range of technology infrastructures to significantly proprietary systems with a limited range of infrastructure options

While the technology architecture for the FreeBalance Accountability Suite, the FreeBalance Accountability Platform, was designed for limited computing infrastructures, many COTS systems require significant network and computer resources. Costs remain high to provide the high bandwidth services needed by many COTS systems. COTS systems leveraging public cloud infrastructures rarely support the government financial management needs in larger countries with low population density.

What are the implications of the global digital divide for governments?

Lack of equitable access to high availability broadband

Lack of equitable access to high availability broadband

Source: https://submarine-cable-map-2019.telegeography.com/ 

Lack of internet capacity


Source: https://ourworldindata.org/internet 

Difficulty to Support Electronic Government

What are the Public Financial Management implications to remote connectivity?

Some observers see significant similarities between government and large business requirements. Those of us in the PFM domain find this notion as close to absurd. It is the differences between PFM and private sector financial management that need to be understood. These differences have significant technology architecture implications:

  • Robust coverage: PFM covers the largest portion of GDP in most countries, with the largest number of employees, and the largest wage bill
  • Comprehensive coverage: PFM covers all citizens and all businesses in a country, government does not have the luxury of firing unprofitable customers
  • Financial complexity: PFM covers far more “lines of business” than any global conglomerate, 
  • Technology variability: PFM covers all regions in a country, government does not have the luxury to focus exclusively in cities with excellent technology infrastructures
  • Budget management: PFM uses budget-driven commitment accounting, where budgets are the law so there is a need to know the “free balance” in near real time
  • Decentralization variability: PFM decentralization means a wide range of possible local financial autonomy yet a need for an integrated and consolidated view for fiscal transparency, reporting and planning
  • Practice variability: PFM operates with a wide variety of practices adapted over time through modernization meaning that technology architectures often have to change to reflect process improvements and legal reform 

There are few, if any, established PFM “best practices’. This means that fiscal decentralization in countries rarely follows the same sequence of events. This is further complicated by other PFM reform with technology architecture implications. 

How can governments evaluate FMIS technology solutions for decentralized deployments?

Many COTS vendor solutions  assume reliable and persistent broadband connectivity. Others require synchronization among network nodes.  These represent unrealistic and overly-engineered options for many contexts.

Why is understanding the link between PFM and network connectivity important?

Linkages between PFM decentralization, and available telecommunication infrastructures forms the context for government technology architecture decisions:

  • Extent of decentralization: coordination and consolidation burden increases with fiscal decentralization
  • Connectivity variance: technology choices depend on the most vulnerable regions with the lowest bandwidth and poorest resilience
  • Transaction footprint: network and coordination infrastructures depend on transaction volumes, and peek times

Why do total costs differ significantly among solutions?

There is a view that software costs, whether COTS licenses or custom-developed services, represents the largest part of a government financial system Total Cost of Ownership (TCO). The reality is that implementation (costs related to code customization) and sustainability (support, upgrades, and training) represent the highest percentage of costs. Accurate TCO pricing should include public servant costs.

There is also a view that the technology infrastructure necessary to support COTS options are roughly similar. However, TCO for equipment and data centre maintenance differ widely based on software design constraints, especially in decentralized scenarios:

  • Hardware: additional computers and network equipment may be required for distributed data centres, synchronization and reliability
  • Middleware: additional licenses for databases, operating systems, application servers, metadata managers, and transaction processing may be required
  • Bandwidth: the minimal expected connectivity for some solutions may require upgrading telecommunications infrastructures
  • Maintenance: information technology skills requirements for distributed data centre approaches requires paying more for those skills

What are the advantages of the web-based approach?

FreeBalance provides web-native government financial management systems. Many established vendors provide web-enabled systems that translate client/server functions via the web. Public cloud offerings are also available. FreeBalance supports on-premises, government shared services, and public cloud options using the identical technology. 

Very few pure client/server government financial systems remain in use. Web approaches overcome many government information technology problems from the client/server days:

  • System management: ability for shared services groups for systems and network management that do not require local information technology people
  • Software management: ability for shared services groups to manage system-wide upgrades to that all systems operate with the same business rules, controls, and workflow
  • Equipment costs: web systems do not require significant computing power for user workstations
  • Cyber security: lack of local code operating reduces opportunities for hacking, viruses, and financial corruption
  • Environmental sustainability: web and cloud systems typically require less power than traditional infrastructure

What are the information integrity implications in decentralized deployments?

The consequence of inappropriate technology architecture methods for decentralized deployment include: 

  • Loss of data integrity
  • Increased need for bandwidth
  • Information contention during consolidation
  • Invalid transactions in complex processes
  • Cybersecurity vulnerabilities

How does FreeBalance summarize the key advantages and disadvantages of decentralized and remote options?

There are five important architectural considerations to consider for technology infrastructure options in decentralized and remote contexts. This relates to the extent to which the technology infrastructure supports:

  • Reliability: reliable transaction and data integrity in the context
  • Validation: effective validates transactions and budgets
  • Maintainability: ease of system, network, and software management
  • Adaptability: changes to technology infrastructure to support PFM reform and connectivity upgrades 
  • TCO: cost control, over five or more years, with the proposed technology architecture

What are the advantages and disadvantages to decentralized and remote connectivity FMIS technology solutions?

What are the three most common solutions?

  1. Centralized 
  2. Redundant
  3. Distributed

1. Centralized Deployment Option

This option includes a central data centre, typically provided as a government shared service or through a public cloud platform. Redundant systems for fault tolerance and availability in government data centres is a good practice while public cloud providers often have built-in redundancy.

PFM users connect to systems via secure simple internet connections using encryption through local and wide-area networks that leverage the public internet. Private networks and satellite communications can also be supported

Typical Configuration

Typical Configuration
Data Centre

  • Single data centre consisting of scaled systems with load balancing and/or virtualizations
  • Government Resource Planning (GRP) logic deployed via an application server or combined application and web server
  • Database management system
  • Data layer (database management) separated from business logic layer
  • All business logic resides in the data centre supporting a single point of management
  • Central sites can also have disaster recovery infrastructures, and storage arrays 

Communications

  • Minimal communications across fibre optics network

Local Sites

  • Computers connected through routers

Advantages

  • ✔ Low cost of deployment on remote sites with a router for internet access
  • ✔ Low cost of maintenance and operation with no software or network maintenance in regions
  • ✔ Low cost of communications in most context by using commercial internet services

Disadvantages

  • ✘ High exposure to internet connection reliability,  systems cannot be used remotely when communications fail

Summary

  • ✘ Reliability: requires high availability connectivity, typically with high bandwidth to support all distributed users, meaning that any connectivity problem will result in transaction failures
  • ✔ Validation: transactions are centrally validated with a single set of rules
  • ✔ Maintainability: central maintenance by a single team
  • ✔ Adaptability: difficult to adapt to different technology infrastructures
  • ✔ TCO: controls cost for local equipment, and local information technology professionals

2. Redundant Deployment Option

This option includes a central data centre, typically provided as a government shared service or through a public cloud platform. Redundant systems for fault tolerance and availability in government data centres is a good practice while public cloud providers often have built-in redundancy.

PFM users connect to systems via secure simple internet connections using encryption through local and wide-area networks that typically leverage the public internet. Unlike the fully centralized version, Option 1, this supports multiple, redundant, internet connections, operated in a fault tolerant configuration. Variations of this approach include failover backup to different Internet Service Providers (ISP), dial-up phone connections, cellular data,  or Very Small Aperture Terminal (VSAT)  technology.

Typical Configuration

Typical Configuration

  • As with option 1 but with redundant internet connections

Advantages

  • ✔ Low cost of deployment on remote sites with a router for internet access
  • ✔ Low cost of maintenance and operation with no software or network maintenance in regions
  • ✔ Low exposure to internet connection reliability/quality – multiple ISP circuits guarantee that at any time there is connectivity between the remote location and the central GRP Platform

Disadvantages

  • ✘ Higher cost of communications depending on need for failover
  • ✘ Unrealistic if there are no alternative ISPs or dial-up connections and if occasional use VSAT is too expensive

Summary

  • ✔ Reliability: reliable transaction and data integrity through redundant connectivity
  • ✔ Validation: transactions are centrally validated with a single set of rules
  • ✔ Maintainability: central maintenance by a single team
  • ✔ Adaptability: adapts to changes thanks to backup connectivity
  • ✔ TCO: some additional costs for leveraging backup connectivity that ✘ could be expensive in some contexts

3. Distributed Synchronization

This option includes a central data centre and many regional data centers. Information is synchronized among servers on all the data centers. The option of migrating to the public cloud is unrealistic in most circumstances. Fault tolerance is supported through the use of multiple servers in multiple locations. Significant bandwidth is required because software, and database synchronization means that every transaction travels to every server.

PFM users connect to systems via secure simple internet connections using encryption through local and networks while synchronization among servers typically operates using the public internet.

Variations of the approach include distributing the business logic required to local and regional servers rather than full synchronization. Another approach is to distribute databases across nodes so that local servers only contain local data.

Typical Configuration

Typical Configuration

Data Centre

  • Similar to previous options 

Communications

  • Addition of synchronizing of data and functions across all remote servers and central servers with fiscal control validation and transaction completion validation that can often mean all-to-all communications where additional servers and sites adds significant bandwidth requirements

Local Sites

  • Addition of local data centre with servers that include database management systems

Advantages

  • Low exposure to internet connection reliability because of redundant regional and local servers 

Disadvantages

  • ✘ Unrealistic where there is poor connectivity among regions that prevent synchronization because this approach requires orders of magnitude more communications
  • ✘ High cost of deployment because computing infrastructures required on remote sites, including hardware, network equipment, and additional middleware and  software licenses 
  • ✘ High cost of maintenance and operation because of the need for local staff and coordination processes among sites
  • ✘ Data validation complexity  because data needs to be synchronized between remote and central sites to validate business rules, processes, segregation of duties, and controls
  • ✘ Distribution complexity that combines data contention from distributed functionality or distributed databases with validation and automated features like auto numbering
  • ✘ Limited functional capabilities based on realistic synchronization among servers.
  • ✘ Cybersecurity vulnerability through local servers, specialized clients, and access to database management systems

Summary

  • ✘ Reliability: requires significant bandwidth through synchronizing servers, databases, and transactions that is vulnerable to any connectivity failure combined with cybersecurity risks
  • ✘ Validation: requires validation at every server node requiring high availability connectivity
  • ✘ Maintainability: requires system, network, and software management personnel at every synchronization server point
  • ✘ Adaptability: no ability to adapt to different technology infrastructures
  • ✘ TCO: high cost through multiple servers, high bandwidth, and local information technology resources

Conclusions

Decentralization and remote access were design criteria behind the  FreeBalance Accountability Platform. Applications built for the FreeBalance Accountability Suite benefit from openness and lower bandwidths experienced by the governments of Mongolia and Nunavut who had used VSAT for the client/server version. Engagement with PFM experts from large countries in Asia Pacific, South America, and Sub-Saharan Africa led to the development of “non functional requirements” for the technology platform, the FreeBalance Accountability Platform.

The traditional approach for client/server implementation of COTS ERP is through server synchronization. This has proven cost-prohibitive for many multinational companies who have deployed so-called “Tier 2 ERP” approaches. This does not entirely solve the cost problem because regional technology staff is required, and there needs to be an approach for financial consolidation.

Some large companies have transitioned to full public cloud implementations using cloud-native technologies. However, data sovereignty is often lost to foreign governments using this approach.

Web government financial management systems reduce costs significantly compared to traditional client/server approaches. There remain some constraints to this approach in some countries that have been described in this paper. 

  1. Governments with high-availability and high-bandwidth connectivity should implement the centralized option
  2. Governments with availability and bandwidth constraints should implement the redundant deployment option in most scenarios
  3. Governments should avoid the high cost distributed synchronization option

Topics

Contact