How to Design a Financial Management Information System

Posted on February 5, 2022 in Government Technology

How to Minimize Risks in Public Finance Management and Administration

A modular approach is considered to be the best Financial Management Information System (FMIS) design according to the International Monetary Fund paper How to Design a Financial Management Information System – A Modular Approach. The paper analyzes disappointing results from over 45 FMIS implementations in developing countries and emerging economies. The authors conclude that a modular approach overcomes many FMIS deficiencies and is able to achieve long-term reform objectives.

The countries surveyed had some form of Integrated Financial Management System (IFMIS) in place but were looking to improve and modernize to link these systems with subnational platforms and related Public Financial Management (PFM) systems, such as budget planning, public procurement and debt management.

The authors questioned many strongly-held views within the PFM and enterprise software communities. They show how technology often slows PFM reform efforts. And state that “the system’s ability to meet ongoing and anticipated PFM needs is a critical precondition for FMIS success.” While technology analysts recommend the use of Commercial-Off-The-Shelf (COTS)¹ financial management systems for complex applications like general ledgers, many in the PFM community, including the authors of the study, suggest that custom developed systems are legitimate choices. We believe that Government Resource Planning (GRP) is the answer.

FreeBalance is somewhat unique in the global market with an exclusive focus on GRP COTS applications, the FreeBalance Accountability Suite™, and a COTS platform for customer financial management software development, the FreeBalance Accountability Platform™. FMIS implementations in close to 30 countries gives us a nuanced and experienced perspective on building a government financial management systems. 

We’re very much preoccupied with sustainable government success in financial management. We see FMIS sustainability as:

• Financial Sustainability, the government long-term affordability or Total Cost of Ownership (TCO)² for the full solution lifecycle including development, implementation, maintenance, and retirement.
• Reform Sustainability: the ability for information systems to adapt to future reform and modernization including accrual accounting, program budgeting, performance management, value for money, and decentralization.

This notion of reform sustainability is a critical concern in the public sector. All governments witness reform and modernization. The scale of change exceeds that in the private sector. Sustainable FMIS success comes from understanding that:

• Technology and solution design is important 
• Financial management projects are transformational with impact far beyond IT and accounting
• Project and product governance are critical ingredients

Types of Financial Management System Approaches

We would like to extend concepts introduced in the paper through the lens of enterprise software technology and implementation practices with a few recommendations. The themes of the paper expanded on below are:

1. Software Modularity – assembling FMIS portfolios using software components
2. Core First Approach –  basic FMIS functions are solidified first
3. Fiscal Interoperability – full FMIS processes integrated across modules
4. Investment Leverage – optimizing FMIS current investments and avoiding “rip and replace”
5. Agile Implementation – modern scientific techniques adapted to FMIS projects
6. Advanced Technology – extending FMIS capabilities through the latest innovative technologies
7. Performance and Transparency – leveraging FMIS to improve government effectiveness and fiscal transparency
8. Build vs. Buy – determine whether to build custom software or buy software packages across the FMIS portfolio

There is significant overlap among these themes. Modularity is the key theme of the paper, and the main dependency for the other themes.

1. Software Modularity

“Large FMIS and IFMIS applications have been shown to be less efficient in many environments than systems that focus on a few core PFM modules, [and] adopt a sequenced approach to implementation.”

Software modularity³ is required to support sequenced approaches where financial management information systems align to PFM reform and modernization needs. And, it is often difficult to contain all financial systems objectives using a single solution in a single large step using a “big bang” approach. Yet, a World Bank study, concluded that “both big-bang and gradual implementation processes for FMIS systems present challenges, and there does not seem to be an easy answer as to which is the better approach.” 

My sense is that most PFM experts prefer the quick wins approach to FMIS implementations. This can reduce change resistance. “Big bang” approaches can benefit from modular design by demonstrating working software throughout the needs articulation process. 

Implementation Perspective

Government FMIS implementations and future changes are enabled through modularity:

• Functionality can be implemented in phases without the need for the need to fully articulate all requirements before proceeding, including adapting future module requirements based on what was learned in previous stages
• Roll out of FMIS functionality can conform to organizational capacity and public finance priorities, such as implementing new modules at higher-capacity ministries with significant citizen interaction 
• Modules can be progressively activated⁴ to support ongoing reform as new functions are added in a sequence that is appropriate for government objectives

Technology Perspective

Enterprise-class software has become more modular, with important benefits for governments:

• Use of granular components in Service-Oriented Architectures (SOA)⁵ enables sharing pieces of consistent functionality across systems and can eliminate unnecessary functional duplication
• Good modular design supports extensibility⁶ by leveraging existing functionality to satisfy new requirements
• Governments can upgrade to more advanced modules with limited disruption when more modern designs are used 
• External service modules such as bank reconciliation, macroeconomic data, and exchange rates can help automate government processes

Recommendations

Successful achievement of government modularity benefits requires:

• A component perspective of functions is helpful rather than looking at silo functions as stand-alone large “modules” – in other words, payroll or procurement “modules” must consist of many identifiable components in order to be thought of as “modular:
• An FMIS design concept consisting of many modules that can integrate or be reused in many contexts

Examining the component modularity approaches by looking at whether coarse or fine-grained⁷ , loosely or tightly coupled⁸ to determine technology applicability for any component.

2. Core First

“Support the implementation and monitoring of core fiscal objectives, fiscal rules, and financial regulations, by giving priority to strengthening the FMIS’s accounting, budget, treasury, and reporting functions.” 

This modularity notion extends beyond technology concepts. Some governments attempted to automate more functions than the absorption capacity of the public service permitted. Financial system implementations could be better understood as skill-building exercises. The core-first approach enables scaling skills. Advanced PFM skills are dependent on scaling core skills.

The definition of what is core and what is non-core depends on the circumstance. The paper points out  that “a core FMIS is defined in this note as an information system that supports budget execution, accounting, and treasury and cash management functions, and generates financial reports in a timely manner.” For example, the sophistication of budget execution differ among countries. Some countries use multiple stages of commitment accounting with built-in tolerances, and budget transfer discretion. There are many advanced economies that have only recently adopted commitment accounting. 

Higher capacity public services can absorb more new functions and can exhibit lower change resistance. And, the core can depend on country circumstances where payroll, procurement, or tax administration may be vitally important to automate. These considerations provide a more nuanced analysis of “big bang” versus gradual approaches.

Implementation Perspective

The core-first approach, typically covering accounting and budget execution:

• Captures core metadata⁹, controls, and processes necessary for financial management across the budget cycle that are shared with all other functions, where getting this right has significant payoffs as modules added
• Becomes the key organizational change and human capacity milestone that sets expectations for future changes
• Provides organizational learning by enabling changes in prototype, proof-of-concept, testing and production systems while setting financial management standards
• Improves information quality to better structure budget formulation and non-core financial functions

Technology Perspective

Modularity in FMIS technology is an important consideration in the core-first approach:

• Some FMIS approaches do not support this core-first intent effectively when all functions and metadata need to be defined up-front because adjusting these after is difficult and time-consuming, such as not support a multiple-year Chart of Accounts
• Standalone modules are designed without considering the desired FMIS end-state driven by anticipated future reforms

Recommendations

Successful implementations follow a core approach that demonstrates:

• Realistic core footprint for the government context including financial management capability maturity that differs among countries – core differs based on context 
• Need to create shared budget and accounting classifications to “ensure timely and reliable accounting and budget registration of financial transactions”
• Adaptability that anticipates future reform, including decentralization, reorganization, or accrual functions that occur within core functions  
• Phases that could overlap so that design for a new phase can be accomplished in the midst of testing previous phases in some cases

3. Fiscal Interoperability

“Facilitate the exchange of information between the core and noncore modules of the FMIS, and between the information systems operated by individual ministries and agencies.” 

Interoperability¹⁰ is more than technology, and more than efficiency. Interoperability implies process integration across financial functions that are replicated and automated through technology. Government financial processes are often not logically integrated across ministries, government tiers or with state-owned enterprises. Technology integration often follows poor practices, and often focuses on expenditure and revenue execution rather than the complete budget preparation and cash forecasting cycles. Compliance, controls, and segregation of duties¹¹ are often missing in process and technology integration increasing risks.

Many COTS vendors claim to provide integration and interoperability. This is often misleading. Some large vendors have acquired so many companies with so many technology platforms that full interoperability is almost impossible. Some product suites are deployable with different metadata and controls among modules.

Implementation Perspective

Process interoperability requires process and workflow integration:

• There are often numerous sub-systems that provide specific and unique financial functions to meet legislative and legal requirements in ministries, agencies, and state-owned enterprises that need financial consolidation to show the real fiscal position of governments
• Consistent process and concept definitions enables functional interoperability even with limited software interfaces or the use of poor integration practices like direct database calls
• Legal decentralization requirements may prevent governments from achieving cross-government interoperability

Technology Perspective

Interoperability has many technology dimensions to consider:

• Mapping of metadata, or concepts, across modules to provide a consistent version of the “truth” eliminating inconsistencies
• Resilience to changes in modules through effective Application Program Interfaces (APIs)¹² or Web Services¹³ support
• Good integration practices such as eliminating direct database calls, stored procedures, manual interfaces, screen scraping, flat files, and proprietary approaches
• Product suites that provide good out-of-the-box interoperability among functions may do so using proprietary interfaces and proprietary middleware¹⁴ increasing the risk that governments are locked-into that portfolio

Recommendations

Few governments are in the position for full interoperability among systems for technology and legal reasons. Governments can improve interoperability through:

• Charting all applications in use, supporting technology in use, existing integration, integration quality, comparisons to logical integration
• Clear interoperability framework across the budget cycle such as integrating debt management with budget preparation systems for improved decision-making, with commitment controls to better forecast debt payment expenditures, and with accounting systems to manage debt revenue and expenditure transactions
• Information governance¹⁵ with metadata definitions, data cleansing, and audit procedures
• Enterprise service bus¹⁶  design that pushes all interfaces through a shared bus that improves integration consistency 
• Risk-based approaches that recognizes the level of functional interoperability need where some silo stand-alone systems may not materially impact budget consolidation
• Selected open systems¹⁷ to reduce vendor lock-in while increasing future module choices
• Innovative methods to deal with legacy applications that do not support modern integration

4. Investment Leverage

“Allow countries to make the best use of their existing systems, utilizing investments in IT and human resource capabilities that are already available, and avoiding the need to replace all or most of their existing FMIS.” 

Government IT budgets are under stress. Most government organizations support a wider range of legacy applications than businesses. This results in higher ratios of IT budgets dedicated to operations and maintenance – “keeping the lights on”. Meanwhile, governments are faced with demands to improve service delivery with declining budgets. 

The paper makes an important observation: “in the case of commercial-off-the-shelf (COTS) software solutions, for example, better and more efficient functionalities can often be achieved through improved parameterization of existing FMIS modules.” Some FMIS choices provide this configuration capability making investment more leverageable. The reality is that many government financial systems investments require significant code customization to enable change. Some government FMIS implementation use obsolete technologies increasing operating costs and reducing extensibility.

Implementation Perspective

Process considerations for leveraging current investments include:

• Extent to which efficiency or effectiveness is supported, even if full processes are not automated
• Compliance with current and anticipated public finance procedures, such as accrual accounting
• Alignment with current government capacity and foreseeable skills improvement

Technology Perspective

Technology considerations for leveraging current investments include:

• Extent to which technology is recent or legacy, including non-supported platforms, and non-supported application versions
• Adaptability to current solutions with limited cost customization, or post-modern¹⁸ in design
• Extent to which software is hard-coded and difficult to adapt to future reform
• Extent to which proprietary technology is used that restricts future choices
• Current costs to maintain and update FMIS systems
• Ability to extend current technology to support other functions
• Number of different technology platforms in use, where fewer platforms simplifies maintenance and cybersecurity
• Extent of scalability to meet government processing needs
• Extent of interoperability needs that are or are not satisfied, and the compliance risk of lack of integration
• Ability to deploy applications to virtual and cloud environments to reduce costs
• Ease of migrating data from legacy applications to less expensive modern financial applications
• Ability to migrate to less-expensive software middleware, including open source, to reduce maintenance costs

Recommendations

• Ensure that all patches to technology platform installed promptly to reduce cybersecurity vulnerabilities
• Use a risk-based approach by identifying control, segregation of duties, integration, and technology vulnerabilities when considering module or application replacement
• Effectively evaluate any replacement, making sure that all costs are considered
• Consider approaches to reduce operating costs such as cloud deployment or replacing proprietary middleware
• Do not fall into the sunk cost trap thinking that an existing investment should be leveraged when replacement costs, with projected operating costs, are lower than operating costs of current software

5. Agile Implementation

“Provide for more agile solutions in rapidly evolving environments (for example, where several PFM reforms are taking place simultaneously).” 

There’s a reason why leading web, social media, and sharing economy providers leverage agile¹⁹ implementation methodologies. 

Agile processes have become more mainstream in government. Governments use agile to develop innovative new ideas and create quick applications. This is often used in a bimodal²⁰ approach where operations of existing systems follow traditional methods but new initiatives use agile.

Our experience is consistent with the observation that “more agile software development approaches driven by automation are making such a strategy faster to implement and more cost-effective than in the past.”

Scaled Agile Frameworks (SAFe)²¹  are used when government organizations have built up agile skills. Problem-Driven Iterative Adaptation (PDIA)²² is used to uncover problems to develop effective solutions in country development that often does not include technology. DevOps²³ is used to align technology and functional priorities. DevSecOps²⁴ integrates cybersecurity into software deployment.

Implementation Perspective

Financial management systems have traditionally been implemented using waterfall techniques that are associated with difficulties that include:

• Development of complex requirements prior to acquisition that are often disconnected from actual needs
• Lengthy “as-is”, “to-be”, and “fit-gap” analysis that increases change resistance while increasing the chances of unnecessary customizations
• Rigid project management that build unrealistic milestones, rather than recognizing that original specifications are likely faulty, and agile processes are often more effective
• Focus on contract compliance including the development of unnecessary documentation

Agile effectiveness comes from:

• Problem-focus including scientific techniques to validate ideas rather than imposing solutions that are not appropriate
• Short iterations that achieve quick wins and engage users to reduce change resistance
• Adapting implementation to better meet real requirements
• Integration of domain specialists, designers, analysts and development teams to facilitate communications and prioritization

Technology Perspective

Agile is enabled through technologies such as:

• Object-oriented programming languages²⁵ that support reuse and extension
• Use of low code²⁶ and no code²⁷ methods that facilitates change and accelerate implementations
• Automated tools used for testing, prototyping, and project monitoring

Recommendations

The concept of agile is counter-intuitive for many public servants. Projects are often selected based on the predictability of outcomes. Governance projects like the implementation of a new financial system can be political. Agile approaches also change the nature of project management:  

• Design thinking²⁸ and prototyping approaches to validate meeting user needs replaces traditional top-down IT processes
• Continuous communications through process boards that show current iterations, progress, and backlogs
• Bi-modal approaches where some new projects leverage agile while maintaining current systems remains traditional
• Experimentation in small applications, often beginning with paper prototypes, generates insight 
• Test every step to discover practices and solutions, often not technology-related, that work effectively in the context

6. Advanced Technology

“Increase the flexibility to incorporate advanced technologies within the FMIS, including web-based or multi-layered systems.” 

Advanced technology is often implemented as standalone functions, or to satisfy the unique requirements of line ministries. Smart government and citizen self-service applications have significant potential returns. However, governments who struggle with the implementation of core financial functionality may be in no condition to effectively acquire and implement advanced technology. 

Most observers describe the need for developing business cases before acquiring advanced technologies, although it’s difficult to make conclusions on the utility of these.  Experimentation is encouraged, yet most blockchain and many machine learning and IoT proofs-of-concept have failed to scale in government despite so many published “use cases” by leading technology providers.

Implementation Perspective

The utility of advanced technologies to extend government financial functionality depends on the country context:

• User targets including digital infrastructure, skills, and device form factors used
• Social and cultural norms related to automation, privacy, and security
• Prioritization of domains based on country needs, such as the applicability of blockchain for property registration in countries with sufficient bandwidth that suffer from property tax avoidance

Technology Perspective

Advanced technologies often require reliable back-office “systems of record,”²⁹ such as robust financial management:

• Systems of engagement such as online citizen and business payments for licenses, permits or taxation requires integration with revenue, expenditure, case management, and banking systems
• Systems of intelligence such as online budget transparency portals require integration with back-office government accounting systems with integrated data for accurate and timely information
• Systems of innovation such as smart assets requires integration with back-office procurement systems to manage maintenance, and predict replacement needs

Recommendations

Governments should consider the use of advanced technology in a holistic manner:

• Prioritization by matching advanced technology use cases with country needs and identifying dependent digital infrastructure needs
• Experimentation using agile implementation techniques to solidify potential returns and prioritize initiatives
• Agile procurement methods to engage innovative vendors to build proofs-of-concept
• The analysis of existing systems to understand which advanced technology initiative can be better enabled
• Test solutions on the public cloud³⁰ and open source, where possible, to reduce costs
• Focus on prototypes and proofs-of-concept with less concern about which platforms used,  recognizing that implemented solutions may different platforms
• Consider the best hybrid³¹ applications of private cloud³², shared services³³, community cloud³⁴, and public cloud technologies to optimize costs and cybersecurity, recognizing that testing and production versions may be deployed with different approaches
• Most advanced technology is based on open source projects, so governments should prefer this over proprietary solutions particularly in the experimentation stages

7. Performance and Transparency

“The broad objective of an FMIS, as a key fiscal management tool, is to generate timely, relevant, and reliable financial data and reports that support financial decision making and improvements in fiscal discipline, expenditure control, and fiscal transparency.” 

The thinking about analytics in the enterprise software industry has matured over the last two decades. An example is the Four Analytical Capabilities presented by the Gartner Group of: 

• Descriptive: what happened?
• Diagnostic: why did it happen?
• Predictive: what will happen?
• Prescriptive: what should I do?

Financial decision-making requires more than traditional reporting. Statutory reporting is required in government. But, exception reporting and alerts are far more operationally important. The real decision-making value comes from forecasting, data science, analytical models and visualization.

Fiscal transparency is often supported using the same infrastructure and similar tools provided to government decision-makers. That’s because fiscal transparency enables citizen, ex-pat, business, Foreign-Direct Investment, remittance, and credit bureau decision-making. 

It should also be understood that performance management is much more difficult in government than in the private sector. Businesses operate to a bottom line – profit. Business managers know that failure to meet profit objectives when performance objectives are met is a sign of poor objectives. Yet, governments have no such bottom line. And, there are often many factors involved, outside of government control, that affect outcomes.

Implementation Perspective

There are numerous “business intelligence” and “corporate performance management”³⁵ software solutions. Implementation of these solutions depends on many non-technology factors:

• Logical performance linkages with government strategy for consistent measurement such as with procurement value-for-money and public servant performance appraisal
• Logical linkages between outcome and output goals with budget classifications to track effectiveness of allocations (what we call: integrating the Chart of Accounts with the Chart of Goals)
• Appropriate set of performance indicators to facilitate tracking while not overwhelming public servants
• Information accessibility, clarity, and usability based on the audience

Quality and breadth of information for data scientists³⁶

Technology Perspective

Integration among systems facilitates performance management and enables fiscal transparency automation. Technology considerations include:

• Metadata integration across systems, especially budget and goal classifications, using enterprise metadata management³⁷
• Increased big data footprint including unstructured data in the form of documents, audit trails, IoT devices, and social media feeds
• Increased complexity of classifying information for machine learning
• Potential need for edge computing analytics, and elastic cloud computing for very large data sets
• Self-service analytics³⁸ needs using scorecards, dashboards, and easy data queries 

Recommendations

Effective reports, analytics, and dashboards to assist decision-makers requires data integration among systems requiring:

• Use of data warehousing³⁹ technology to rationalize data from disparate systems for decision-makers in situations where there is reasonable data consistency 
• Methods of information validation to improve data quality that could include data cleansing methods
• Use of data lakes⁴⁰ and cloud computing to manage big data⁴¹ integration for financial decision-makers
• Developing appropriate IT and data science skills to build more effective analytics
• Use of visualization⁴² technologies to simplify decision-making through pattern recognition
• Adapting information output to be accessible and understood by targeted end users

8. Build vs Buy

The table at the top of this article describing the Advantages and Disadvantages of Alternative IT Solutions gives the options in-house IT solutions, Locally developed software solutions, and Commercial-off-the Shelf solutions.

The GRP Commercial-Off-The-Shelf (COTS) alternative is not specifically described in the paper. It’s our view that GRP provides all of the COTS buy benefits to governments with fewer disadvantages. And, GRP platforms provide significant build benefits. Build vs. buy is no longer a binary choice for governments.

Implementation Perspective

The thinking about build vs. buy for government financial systems has changed over time:

• Lack of government functionality in COTS software led most governments to develop custom software (“Locally developed software solutions”)  whose coverage was not always comprehensive, and development and testing was not at commercial levels
• Addition of government functionality, such as commitment accounting, in COTS software started the trend to move to COTS, particularly in developed countries, with broad coverage and higher quality code
• COTS government implementations, particularly Enterprise Resource Planning (ERP)⁴³ became complicated and overly customized leading to high cost and difficulty adapting to change
• GRP COTS software has emerged, although other than FreeBalance, most GRP providers focus on sub-national, regions or specialized functions like aid management, budget portals, customs administration, debt management, or tax administration 
• GRP COTS solutions are often more flexible than in-house or locally-developed bespoke software
• Some governments in advanced economies attempted, with limited success, to adopt ERP shared services with generic versions and standardized processes
• Many countries continue to use custom software (“Locally developed software solutions”) for core or peripheral functionality despite the complexity of doing so
• Information technology analysts recommend that core functionality, like general ledgers, should be acquired as COTS, yet county development analysts see custom software as a legitimate choice for governments

Technology Perspective

There are numerous technology considerations regardless of build or buy options:

• Flexibility, openness, adaptability, and usability of technology platforms and tools used
• Industry-wide knowledge and support of technologies and tools selected 
• Modernity of technologies used with the view of ease of support in the future
• Support of the broadest range of browsers, devices, and form factors
• Programming languages that are fit for purpose, including whether can scale to meet government requirements
• Technology and government platforms that can accelerate development
• Ability to support current country digital infrastructures

Conclusions and Observations

The paper gives practitioners more insight into the main factors for sustained success in FMIS systems:

Technology and Solution Design 

• Technology and design defines “the system’s ability to meet ongoing and anticipated PFM needs”
• Component-based modularity approaches increases reuse, adaptability, and extensibility enabling a shift from a “fully integrated set of functions and processes into a virtual system”
• Postmodern designs better support financial system interoperability, emerging technologies integration, and deployability on less expensive infrastructure to overcome “challenges in synchronizing and normalizing data from multiple sources”
• Open systems support the widest range of technology options

Transformational Financial Management

• Use of agile implementation and product development technologies support transformation change management
• Recognition that FMIS brings disruption to public services, such as increasing fiscal “transparency in the public sector”

Project and Product Governance 

• Use of agile implementation and product development technologies improves FMIS governance by better connecting with user needs
• Recognition that “strong political motivation and commitment” required for success given the incentives at play in public sector transformation and “effective change management strategy, as well as institutional arrangements to coordinate activities among the numerous stakeholders”

Recommendations

1. Industry-Specificity: Many COTS solutions were written for other markets – this has significant consequences for governments who have so many unique needs
   • Consider buy when software written for the government function – product design is important
   • Consider build when there is no software available for the government function, especially when it’s a unique statutory need
2. Product Risk: Building complex functionality, like a general ledger is risky, and flexibility for change is important – this has significant consequences for governments expecting future modernization and reform
   • Consider buy when product footprint needs are complicated and future changes are expected
   • Consider build when product footprint needs are modest, and few future changes are expected
3. Integration Risk: Software should not be considered black box silos – this has significant consequences for governments who lack metadata and controls integration across budget cycles
   • Consider buy when functional integration needs are high such as procurement, asset, and public investment management where interface mismatches can have material consequences like government arrears and illegally exceeding budgets – or information from system is critical for decision-makers and fiscal transparency
   • Consider build when functions operate stand-alone with limited need for posting to core financial systems

Footnotes Glossary

1. Commercial-Off-The-Shelf (COTS): Commercial off-the-shelf or commercially available off-the-shelf (COTS) products are packaged solutions which are then adapted to satisfy the needs of the purchasing organization, rather than the commissioning of custom-made, or bespoke, solutions. Source: Wikipedia
2. Total Cost of Ownership (TCO): A comprehensive assessment of information technology (IT) or other costs across enterprise boundaries over time. For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses and the opportunity cost of downtime, training and other productivity losses. Source: Gartner 
3. Modular Software Design: Refers to a design strategy in which a system is composed of relatively small and autonomous routines that fit together. Source: Webopedia
4. Progressive Activation: Adaptability and modularity approach in GRP systems that assumes significant future changes including adding new functions, increasing functional breadth, changing classifications, increasing automation, and supporting anticipated government reform and modernization. 
5. Service-Oriented Architecture: Service-oriented architecture (SOA) is a design paradigm and discipline that helps IT meet business demands. Some organizations realize significant benefits using SOA including faster time to market, lower costs, better application consistency and increased agility. SOA reduces redundancy and increases usability, maintainability and value. This produces interoperable, modular systems that are easier to use and maintain. SOA creates simpler and faster systems that increase agility and reduce total cost of ownership (TCO). Source: Gartner Group
6. Extensibility: A software engineering and systems design principle that provides for future growth. Extensibility is a measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The principle provides for enhancements without impairing existing system functions. Source: Gartner
7. Service granularity principle: In the context of software engineering and software architecture, service granularity is a key design concern when applying the paradigm of service-orientation for instance during service-oriented modeling. Service granularity specifies the scope of business functionality and the structure of the message payload in a service operation that is provided within a service-oriented architecture (SOA). Source: Wikipedia
8. Loose coupling: In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling. Source: Wikipedia
9. Metadata: Commonly referred to as “data about data”. In GRP systems, metadata includes common classifications such budget, organization, accounting, statistics, and performance. 
10. Interoperability: Interoperability is the property that allows for the unrestricted sharing of resources between different systems. This can refer to the ability to share data between different components or machines, both via software and hardware, or it can be defined as the exchange of information and resources between different computers through local area networks (LANs) or wide area networks (WANs). Broadly speaking, interoperability is the ability of two or more components or systems to exchange information and to use the information that has been exchanged. Source: Technopedia
11. Separation of duties: The concept of having more than one person required to complete a task. In business the separation by sharing of more than one individual in one single task is an internal control intended to prevent fraud and error. Source: Wikipedia
12. Applications programming interface (API): In computer programming, an application programming interface (API) is a set of subroutine definitions, communication protocols, and tools for building software. In general terms, it is a set of clearly defined methods of communication among various components. A good API makes it easier to develop a computer program by providing all the building blocks, which are then put together by the programmer. Source: Wikipedia
13. Web services: A software concept and infrastructure for program-to-program communication and application component delivery. The Web services concept treats software as a set of services accessible over ubiquitous networks using Web-based standards and protocols. Specifically, a Web service is a software component can be accessed by another application (such as a client, a server or another Web service) through the use of generally available, ubiquitous protocols and transports. Source: Gartner
14. Middleware: Middleware is the software “glue” that helps programs and databases (which may be on different computers) work together. Its most basic function is to enable communication between different pieces of software. Source: Gartner Group
15. Information Governance: The specification of decision rights and an accountability framework to ensure appropriate behavior in the valuation, creation, storage, use, archiving and deletion of information. It includes the processes, roles and policies, standards and metrics that ensure the effective and efficient use of information in enabling an organization to achieve its goals. Source: Gartner
16. Enterprise service bus (ESB): An Enterprise Service Bus (ESB) is fundamentally an architecture. It is a set of rules and principles for integrating numerous applications together over a bus-like infrastructure. ESB products enable users to build this type of architecture, but vary in the way that they do it and the capabilities that they offer. The core concept of the ESB architecture is that you integrate different applications by putting a communication bus between them and then enable each application to talk to the bus. This decouples systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus. The concept of ESB was born out of the need to move away from point-to-point integration, which becomes brittle and hard to manage over time. Point-to-point integration results in custom integration code being spread among applications with no central way to monitor or troubleshoot. This is often referred to as “spaghetti code” and does not scale because it creates tight dependencies between applications. Source: Mulesoft
17. Open Systems: Computer systems that provide some combination of interoperability, portability, and open software standards. Source: Wikipedia
18. Postmodern: A technology strategy that automates and links administrative and operational business capabilities (such as finance, HR, purchasing, manufacturing and distribution) with appropriate levels of integration that balance the benefits of vendor-delivered integration against business flexibility and agility. Source: Gartner
19. Agile: Development approach that delivers software in increments by following the principles of the Manifesto for Agile Software Development. Source: Gartner
20. Bimodal IT: The practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and  optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP) approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability. Both play an essential role in the digital transformation. Source: Gartner
21. Scaled agile framework (SAFe): A set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. Source: Wikipedia
22. Problem Driven Iterative Adaptation (PDIA):  A step-by-step approach which helps you break down your problems into its root causes, identify entry points, search for possible solutions, take action, reflect upon what you have learned, adapt and then act again. It is a dynamic process with tight feedback loops that allows you to build your own solution to your problem that fits your local context. Source: Harvard Kennedy School of Government
23. DevOps: Set of software development practices that combine software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives. Source: Wikipedia
24. DevSecOps: Thinking about application and infrastructure security from the start. It also means automating some security gates to keep the DevOps workflow from slowing down. Selecting the right tools to continuously integrate security can help meet your security goals, but effective DevOps security requires more than new tools—it builds on the cultural changes of DevOps to integrate the work of security teams sooner rather than later. Source: Red Hat
25. Object-Oriented programming: Programming paradigm based on the concept of “objects”, which can contain data, in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods). A feature of objects is an object’s procedures that can access and often modify the data fields of the object with which they are associated (objects have a notion of “this” or “self”). In OOP, computer programs are designed by making them out of objects that interact with one another. Source: Wikipedia
26. Low Code: Software that provides an environment programmers use to create application software through graphical user interfaces and configuration instead of traditional computer programming. The platform may focus on design and development of a particular kind of application: such as databases, business processes, or user interfaces such as web applications. Such platforms may produce entirely operational applications, or require additional coding for specific situations. Low-code development platforms reduce the amount of traditional hand coding, enabling accelerated delivery of business applications. Source: Wikipedia
27. No Code: allows programmers and non-programmers to create application software through graphical user interfaces and configuration instead of traditional computer programming. No-code development platforms are closely related to low-code development platforms as both are designed to expedite the application development process. Source: Wikipedia
28. Design thinking:  The cognitive, strategic and practical processes by which design concepts (proposals for new products, buildings, machines, etc.) are developed by designers and/or design teams. Many of the key concepts and aspects of design thinking have been identified through studies, across different design domains, of design cognition and design activity in both laboratory and natural contexts. Design thinking is also associated with prescriptions for the innovation of products and services within business and social contexts. Source: Wikipedia
29. Systems of: Framework to understand digital transformation technologies in government:
    • Systems of Record: core information systems that provide transactional data, transaction management, workflow, and controls
    • Systems of Engagement: information systems designed for two-way communications, and new forms of data collection, often called SMACT (Social, Mobile, Analytics, Cloud, and internet of Things), or what analysts, the Gartner Group calls “the Nexus of Forces”, and IDC calls “the Third Platform.”
    • Systems of Intelligence: information systems designed to make sense of information flow in new ways:
      • Sharing Economy: facilitating value transfer and sharing
      • Augmented Reality and Virtual Reality: facilitating information visualization
      • Blockchain: augmenting trust digitally
      • Cognitive Computing: augmenting human capabilities with machine learning
      • Cyber Physical Systems: enabling the “fourth industrial revolution” of unparalleled productivity and customization, particularly for smart government and smart cities
    • Systems of Innovation: information systems designed for governance breakthroughs leveraging emerging technologies of:
      • Agile Collaboration: facilitating collaboration among government organizations, citizen, non profit and business stakeholders, external governments, and international institutions
      • Microservices: facilitating integration among software programs used by governments and stakeholders
      • Low Code/No Code: facilitating configuration and customization of information systems
      • Artificial Intelligence: augmenting systems of intelligence from specialized systems like conversational UIs, chatbots, Robotic Process Automation, and domain-specific machine learning to generalized AI
      • Yet to emerge technologies, or technologies still lost in noise and hype
30. Public Cloud Computing: A style of computing where scalable and elastic IT-enabled capabilities are provided as a service to external customers using Internet technologies—i.e., public cloud computing uses cloud computing technologies to support customers that are external to the provider’s organization. Using public cloud services generates the types of economies of scale and sharing of resources that can reduce costs and increase choices of technologies. From a government organization’s perspective, using public cloud services implies that any organization (in any industry sector and jurisdiction) can use the same services (e.g., infrastructure, platform or software), without guarantees about where data would be located and stored. Source: Gartner
31. Hybrid Cloud Computing: Policy-based and coordinated service provisioning, use and management across a mixture of internal and external cloud services. Source: Gartner
32. Private Cloud Computing: A form of cloud computing that is used by only one organization, or that ensures that an organization is completely isolated from others. Source: Gartner
33. Shared services or shared services center (SSC) :A dedicated unit (including people, processes and technologies) that is structured as a centralized point of service and is focused on defined business functions. These functions are supported by IT and IT services for multiple business units within the enterprise. Shared services may come from several different physical locations, and may involve numerous business functions and IT processes. The definition, structure and scope of an SSC start within the enterprise. Enterprises sometimes engage external providers to consult with various elements of the design, structure, location options and execution options. Execution and long-term delivery may be by internal enterprise personnel or by service providers, or some combination thereof. Consequently, the definition of shared services is independent from the sourcing option for delivery. Source: Gartner
34. Community Cloud Computing: A shared cloud computing service environment that is targeted to a limited set of organizations or employees (such as banks or heads of trading firms). The organizing principle for the community will vary, but the members of the community generally share similar security, privacy, performance and compliance requirements. Community members may wish to invoke a mechanism that is often run by themselves (not just the provider) to review those seeking entry into the community. Source: Gartner
35. Corporate Performance Management: Umbrella term that describes the methodologies, metrics, processes and systems used to monitor and manage the business performance of an enterprise. Applications that enable CPM translate strategically focused information to operational plans and send aggregated results. Source: Gartner
36. Data Scientist: Critical role is for organizations looking to extract insight from information assets for “big data” initiatives and requires a broad combination of skills that may be fulfilled better as a team, for example: Collaboration and team work is required for working with business stakeholders to understand business issues. Analytical and decision modeling skills are required for discovering relationships within data and detecting patterns. Data management skills are required to build the relevant dataset used for the analysis. Source: Gartner
37. Enterprise Metadata Management: The business discipline for managing the metadata about the information assets of the organization. Metadata is “information that describes various facets of an information asset to improve its usability throughout its life cycle. Source: Gartner
38. Self-Service Analytics: A form of business intelligence (BI) in which line-of-business professionals are enabled and encouraged to perform queries and generate reports on their own, with nominal IT support. Self-service analytics is often characterized by simple-to-use BI tools with basic analytic capabilities and an underlying data model that has been simplified or scaled down for ease of understanding and straightforward data access. Source: Gartner
39. Data Warehouse: A storage architecture designed to hold data extracted from transaction systems, operational data stores and external sources. The warehouse then combines that data in an aggregate, summary form suitable for enterprise-wide data analysis and reporting for predefined business needs. Source: Gartner
40. Data Lake: A collection of storage instances of various data assets additional to the originating data sources. These assets are stored in a near-exact, or even exact, copy of the source format. The purpose of a data lake is to present an unrefined view of data to only the most highly skilled analysts, to help them explore their data refinement and analysis techniques independent of any of the system-of-record compromises that may exist in a traditional analytic data store (such as a data mart or data warehouse). Source: Gartner
41. Big Data: High-volume, high-velocity and/or high-variety information assets that demand cost-effective, innovative forms of information processing that enable enhanced insight, decision making, and process automation. Source: Gartner
42. Visualization: The illustration of information objects and their relationships on a display. Strategic visualization graphically illustrates the strength of relationships by the proximity of objects on the display. Advanced technology can make a significant difference in users’ ability to interface to large knowledge repositories. These advances use the distance between objects on the display to reflect the similarity of meaning, similarity of content or other relationships (e.g., association with a group). Source: Gartner 
43. Enterprise Resource Planning (ERP): is defined as the ability to deliver an integrated suite of business applications. ERP tools share a common process and data model, covering broad and deep operational end-to-end processes, such as those found in finance, HR, distribution, manufacturing, service and the supply chain. ERP applications automate and support a range of administrative and operational business processes across multiple industries, including line of business, customer-facing, administrative and the asset management aspects of an enterprise. However, ERP deployments tend to come at a significant price, and the business benefits are difficult to justify and understand. Source: Gartner Group