The Value of a Government FMIS Solutions Architecture

Updated October 2021

What is a Solutions Architecture?

Ali Hashim, a well-known FMIS expert, recently tweeted about the architecture of Public Financial Management (PFM) digitization. 


FreeBalance follows a similar approach. But what is a solutions architecture and why is it important for implementing a government Financial Management Information System (FMIS)?

There are multiple definitions of Solutions Architecture (SA) with nuanced variations, but perhaps the most authoritative are from The Open Group:

  • A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks.

And Gartner:

  • An architectural description of a specific solution. SAs combine guidance from different enterprise architecture viewpoints (business, information and technical), as well as from the enterprise solution architecture (ESA).

The important point to remember is that a solutions architecture is NOT THE SAME as an enterprise architecture (which describes the full IT infrastructure, business structure, goals and objectives) or a technical architecture (description of the structure and interaction of the platform services, and logical and physical technology components).

GRP Solutions Architecture

Why is a Solution Architecture Important for FMIS Implementations?

Effective solution architecture for a government FMIS system requires integration:

  • Subset of relevant organizational goals from the Enterprise Architecture that applies to the PFM project
  • Integration with, and adaption of, the Technical Architecture, to achieve PFM project objectives

FreeBalance Solution Architecture

Why do we use a FMIS Solution Architecture?

Government FMIS projects are transformational. An FMIS implementation is not a back-office technical initiative. It’s a project that will transform government and thus requires a properly scoped solution architecture.

FreeBalance’s Solution Architecture stack incorporates multiple ‘views’ across all facets.

FreeBalance Solution Architecture

Objectives View

  • Government Goals: government and line ministry goals
  • Donor Objectives: provided if the project is donor funded
  • Project Objectives: gathered from tenders and our understanding from similar situations
  • Expected Outcomes: may or may not be explicit in an RFP, usually describing improvements
  • Expected Impact: how the project improves governance, citizen wellbeing, sustainable development, PFM maturity

Organization View

  • Main Stakeholders: specific line ministries like the Ministry of Finance in an FMIS implementation
  • Directly Affected Ministries: organizations who will be implementing the solution
  • Involved Stakeholders: donors, oversight agencies, civil society

Logical View

  • Core Functionality: typically core financial management functions
  • Major Subsystems: such as payroll, assets, procurement, debt that should integrate with core
  • Functions Supported: functions like audit, transparency, decision-making

Application View

  • Core System: typically the core financial system, although could be more than one  system
  • Major Subsystems: actual applications used, can include current environment contrasted with future
  • Supported Applications: supported by systems like portals, dashboards

Integration View

  • To: the systems to which the systems provide information
  • From: the systems to which the system receives information
  • Type: the integration method like API, web services, RPC, flat file, database, ETL, screen scraping

Information View

  • Systems and Subsystems aligned with the Application View
  • Data Migration shows data coming from systems to be replaced
  • Information Sources for data, metadata, task management, controls, organizational structure

Technology View

  • Presentation Layer: user interfaces to be supported
  • Business Logic Layer: Application servers, middleware, programming languages to be used
  • Data Layer: actual databases to be used

Project View

  • Coordinate with a single project view
  • Identify dependencies within views and across views
  • Align projects with high government, donor, line ministry, and project goals
  • Generate game plans, agile boards, and traditional project plans

Topics