What is a Solutions Architecture?
Ali Hashim, a well-known FMIS expert, 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).
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.
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