No-Code and Progressive Activation in Government Resource Planning
One of our customers, a few years ago, said to me: “all governments think that they’re different, but we’re really different!” If there’s one thing that we’ve learned after almost 40 years exclusively dealing with the public sector, it’s that government processes are different. Different among governments. Different within governments. Very different from businesses. And, constantly changing.
Adapting Commercial-Off-The-Shelf (COTS) software to operate in government organizations can be a very unsatisfactory experience. Enterprise software projects in government are fraught with failure and complex implementation methods. Many in the technology industry views these travails as the “cost of doing business.” “It is what it is”, etc.
Why does it have to be this way? Why can’t COTS software adapt easily to changing requirements?
This blog entry describes our journey to a “progressive activation” and “no-code” approach.
Most COTS software used for Government Resource Planning (GRP) requires significant code customization. Software development, typically using proprietary programming languages, enables governments to support custom requirements. But, at a cost.
Many Public Financial Management (PFM) experts who did not see much of a difference between configuration or customization – often referring to any adaptation as “customization”. We’ve been talking about the difference for some time. And, the industry has caught up to us by defining configuration as “no-code” customization. The use of helper software to facilitate code development is now called “low-code” development. I prefer the term “configuration”, but this no-code to full code spectrum is a useful model.
Enterprise Compounding Software Technical Debt
Code customization comes with high costs and future adaptability challenges. Customization generates technical debt.
Generic software, like Enterprise Resource Planning (ERP) is highly adaptable using proprietary programming languages like ABAP and PL/SQL. It’s true that ERP software is not a configuration wasteland with:
- Configuration of standard parameters like fiscal years, currencies, vendors etc.
- Vertical market quick starts to facilitate implementation, although there are few applicable for public sectors
- ‘Best-practices’, primarily from the private sector, built into software that might be applicable to some government functions, as long as legal reform is not required
Governments acquire significant and compounding technical debt via full code customization. Low-code customization also increases technical debt.
Technical debt includes:
- Implementation Complexity of fully articulating requirements and deploying similar to fully custom development, requiring coordinating programming teams, and instituting comprehensive quality assurance
- Maintenance Complexity after implementation increases because there is orphan code that must be supported through internal resources, not the manufacturer’s responsibility
- Upgrade Complexity when leveraging functionality from new releases because the custom code needs to be examined and rationalized with the new version
- Change Complexity through needing to understand the orphan code before embarking on change
Code customization can create not only technical debt. Technology can limit reform opportunities. We call this the “technology gap“.
Signs of the technology gap in play are:
- Poor time-to-results for implementations
- Poor time-to-change for systems
- Many high-cost contract personnel to manage systems
- Frequent system errors and quality problems
- Limited ability to leverage data for other purposes because of alack of openness because of proprietary technology lock-in
- Limited sub-system integration, even among products from the same manufacturer
A Gartner Group analysis found that software not designed for future adaptation cost organizations about 50 times original investments over 15 years.
Government Resource Planning Technical Debt
Governments are faced with more complex implementations than businesses.
Government enterprise software implementations are more complex from:
- Many more lines of business across a national or sub-national government, than business conglomerates
- High human capacity constraints in technology, project, and functional knowledge
- More complex performance management structures and planning, because government does not have a bottom-line like “profit or loss“
- Higher practice diversity because of legal requirements
- More complex planning through multiple-year budgets that create controls in systems for commitment accounting
- Significant political concerns for public sector implementations
Governments also experience a broader change footprint than private sector organizations:
- More reorganizations after elections, and from cabinet shuffles
- More legal reform because many system procedures are set in law, and laws change – for example: move to accrual accounting, support for Treasury Single Account, procurement reform, public service reform
- More process change in addition to legal reform
- More international standards like MTEF, IPSAS, COFOG, GFS, and SDGs, in addition to supporting some private sector standards
- Broader organizational constraints including vested interests opposed to change
- Higher use of legacy technology in government making change expensive, although saddled with high operations and maintenance costs
Design out Government Resource Planning Technical Debt
Product design drives technical debt or technical value-add. Effective design results in elegant solutions to customer problems. Our focus on government has freed us from many enterprise software constraints.
The design for the web-native FreeBalance Accountability Suite™ began in mid 2006. We examined many of the constraints facing enterprise software manufacturers and made some conclusions:
- Government Functions: Software manufacturers lacked comprehensive government functions because of the need to sell software to many industries, or vertical markets, across many software classes (ERP, CRM, SCM, HCM etc.), or horizontal markets, and throughout the software stack (database, application server, middleware etc.)
- Budget Cycle: Software manufacturers lacked full support for the full government cycle of policy, budget planning, commitments and obligations, for all spending and revenue applications
- Adaptability: Software manufacturers relied on code customization because software was often designed originally for businesses
- Metadata: Software manufacturers had significant data definition problems within product suites that compromised integration and controls, often from company acquisitions, while providing rigid localization, especially for languages
Our first decision was to develop a government-specific platform with a unified design. The product suite was developed based on our Public Financial Management Component Map.
We took the opportunity to address legacy technology constraints by rewriting our software for the web. We had learned a lot from migrating our previous software from Canada to other countries:
- Government Functions: Our focus enabled us to build comprehensive government functions across the PFM Component Map because, with appropriate horizontal functional, ignoring other markets, and developing on an open system that could support many software stacks
- Budget Cycle: Our focus enabled us to support the entire budget cycle, making all applications budget-aware
- Adaptability: We understood government technical debt, and extended configurability significantly from our previous releases
- Metadata: We realized that metadata needed to be unified, and integrated with configuration – we also realized that there had to be a better way to localize
Configuration and Progressive Activation
FreeBalance had become successful at implementing software quickly. Our first implementation, in Kosovo, took 26 days. The operational system at the time including budget controls, cheque printing, and a chart of accounts structure. Accounting functions came later. As did treasury, and decentralized controls. The configuration approach in previous versions of FreeBalance software facilitated quick wins. We realized that we could “progressively activate” any government to advanced public finance functions as enjoyed in the Government of Canada.
Since the completion of the first version of our web-based FreeBalance Accountability Suite modules in 2009, we have seen an increasing need for progressive activation.
Governments seek progress and modernization, supported by GRP systems for:
- Governance Reform: PFM, audit, public service, procurement, and tax reform
- Open Government: budget, fiscal, procurement, revenue, and results transparency with participatory mechanisms
- Decentralization: agency and sub-national fiscal decentralization, devolution
- Technology Automation: automation efficiencies, exception alerts, artificial intelligence
- Digital Transformation: migration of systems of record to systems of engagement, to systems of intelligence, and to systems of innovation
- Performance Modernization: program budgeting, performance structures, outcomes and results
Product and Services Integration Advantage
I met a senior government treasury official from an African country using a Tier 1 ERP system for financial management. The system was still in pilot phase after 2 years. He accused me of being from one of those “Western companies” that demand millions of dollars a year from poor governments just to pay for software maintenance. Software maintenance for software that was not yet implemented. I explained how our system used a configuration approach to accelerate implementations. He just laughed. Complete disbelief that it was even possible. He knew all about the way it was for ERP implementations in government.
FreeBalance has benefited from a single-minded focus on government. Our software can be massively configurable, when compared with generic software.
There’s another unique FreeBalance characteristic. Many of our early international customers contracted major systems integration firms. We were a software provider, with some sub-contracting responsibilities. We discovered that our project involvement was proportional to project success. We also found that many government requests for feature changes had not been forwarded by our partners. Our product roadmap was not aligned.
The traditional approach to enterprise software product roadmaps is via integration partners with a second channel through product support. Software manufacturers are often disconnected from customer requirements. Manufacturers that support many vertical markets often lack expertise, so the “feature lottery” will often favour some markets over others.
Our approach is much different.
Our policy is to be involved in all implementations. We understand the government market. We work with systems integration companies. Our product and services teams are integrated in such a way that we do any product customization required. And, this customization becomes part of our commercially supported code in the next release. There is no orphan code.
Traditional enterprise software manufacturers build up long-term product roadmaps. This is an accepted approach. It makes no sense, but “that’s the way it is.” Customer needs and technology changes so much, that mapping out product features over the next 3 to 5 years, is more like gambling. Especially with any level of detail.
I know – customers are conditioned to roadmaps. Prospective customers want to see our 5 year roadmap. Our 10 year roadmap. I guess it’s to see whether any missing needed functions could be in the pipeline. We show governments the PFM Component Map and explain that we will do anything here, and adapt software to meet their needs. (As long, as it isn’t a bad practice.)
Our approach is to build a 3 year detailed product roadmap based on our in-depth customer experiences. And, our government and technology research. We present this to our FreeBalance International Steering Committee (FISC) every year. FISC attendees change the roadmap priorities, and add items.
This includes products and services.
Progressive Activation Smashes Technical Debt
FreeBalance is a social enterprise. Our mandate is to build smart country prosperity through technology-enabled governance. Governments cannot build prosperity when under technical debt from information systems. Technology should enable governance reform.
This configuration approach, that enables progressive activation includes:
- Business rule parameterization
- No-code workflow
- Multiple year configured chart of accounts
- Unified metadata
- Additional data fields
- Single language file (rather than rigid language sets)
- Terminology configuration
- Adaptable help through integral content management system