What is The Value of a Government Financial Management Information Systems (FMIS) Solutions Architecture?

Coordinate leaders, managers, users, providers, and external stakeholders

It all started last week when Ali Hashim, a well-known FMIS expert [see links below to some stellar papers], tweeted about the architecture of Public Financial Management (PFM) Reminding me of the FreeBalance approach to FMIS and PFM projects through the use of a “solutions architecture” template.


It’s one of 200 FreeBalance tools designed for more predictable and flexible project management organized in categories: 

  1. Preparation
  2. Country Analysis
  3. Technology Analysis
  4. Project Governance
  5. Product Governance
  6. Sustainability

The solutions architecture is part of 1. Preparation 
Why do we use a solution architecture?

  • Coordinate our proposal responses to communicate to all staff and decision-makers
  • Align our project team with government stakeholders during project kick-off
  • Communicate value of initiatives with users and decision-makers
  • Create a common language to facilitate communication

What is a Solution Architecture? Solution architecture is a practice of defining and describing an architecture of a system delivered in context of a specific solution and as such it may encompass description of an entire system or only its specific parts

  • Differs from enterprise architecture that describes the full IT infrastructure, business structure, goals and objectives
  • Differs from technical architecture that describes the full IT infrastructure, and rarely not articulate goals and objectives


Effective solution architecture 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

We call the layers of our solution architecture “views” (as shown in the header diagram):

  1. OBJECTIVES VIEW captures government and project priorities
  2. ORGANIZATION VIEW describes stakeholder and government organization involved in the project
  3. LOGICAL VIEW describes functions affected and how affected by the project
  4. APPLICATIONS VIEW describes all GRP applications affected and how affected by the project
  5. INTEGRATION VIEW describes how the GRP applications will be integrated
  6. DATA, CONTROLS, & INFORMATION VIEW describes sources of data and metadata
  7. TECHNOLOGY VIEW describes the middleware, networks and hardware required by the project
  8. PROJECT VIEW summarizes project requirements, adds success factors & project deliverables

Deeper drive:
A. 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

B. 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

C. LOGICAL or FUNCTIONAL 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

D. 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

E. 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

F. DATA, CONTROLS & 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

G. 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

H. PROJECT VIEW

  • Objectives are linked with A. Objectives View
  • Deliverables are summary of views B through G
  • Project Deliverables describe artifacts that need to be delivered as part of the project
  • Program Management describes methodology to be used & any productized services
  • Critical Success Factors should be included

What are the advantages of this approach?

  • 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

Important FMIS Papers 

Authored and co-authored by Ali Hashim

Topics