It’s high time for government organizations to consider enterprise-class software as an asset, a public investment. Government organizations, all too often, seem to acquire software to fill a governance gap like acquire an e-procurement system to increase competition to save money on acquisitions. Yet, these stand-alone systems increase the chance for governments falling into arrears because of the loss of commitment controls in many standalone procurement, payroll and grants software. (I once saw a presentation where it was suggested that it was impossible to integrate commitment controls with a grants management system.)
The Nature of Software Investments
Fixed assets have value that depreciates over time. Software investments have two additional characteristics: technical debt and extensibility. These characteristics need to be considered across the portfolio of software public investments.
Technical debt is characterized by the use of legacy and custom-developed software in government that restricts change. This is particularly problematic in government where there is a need for on-going Public Financial Management reform. Information systems that cannot easily adapt to change become financially unsustainable. Another sign of technical debt is when a significant portion of the IT budget is associated with keeping the “lights on”.
Technical debt is compounded through the use of many standalone systems in the software portfolio. Metadata tends to be different and commitment controls are lost. Integration is difficult. Management information is often late or inaccurate.
Extensibility is about leveraging the software asset. Effectively designed software enables functional reuse to support change and new features and modules. This is accomplished through a platform that enables functional reuse across many modules. It also provides a single source of management, a unified platform where a change to the chart of accounts or workflow occurs once and is cascaded across applications.
Many software vendors do not provide governments with the full value of extensibility. In this case, software vendors charge governments for duplicated functionality – underlying software code that was acquired in another module.
Software Portfolio Management: Extensibility vs. Technical Debt
How can you determine where your software assets represent the opportunity of extensibility or the burden of technical debt?
- Coverage: Vendors with point solutions do not have extensible software. Buyers should be wary of vendors who fill Public Financial Management (PFM) functionality with private sector software particularly in areas like budget planning, payroll and procurement where government requirements differ from significantly from those in business.
- Reusability: Modern software design uses object-oriented programming for reuse. Small components are assembled to provide functionality. This differs from legacy design where large or monolithic objects were created with duplicate functionality that cannot be easily assembled.
- Metadata: Unified design means the ability to change something once. Many vendors have acquired applications and require complex metadata management tools to ensure that definitions remain consistent.
- Integration: Full support of industry standard web services simplifies reuse and extensibility. Proprietary and flat file integration methods introduce technical challenges.
- Openness: The more open a system is designed, the easier it is to extend. Open systems reduce lock-in. Some vendors attempt to lock-in buyers with proprietary databases, operating systems and programming languages.
- Adaptation: Systems that are not designed for easy change increases cost when attempting to support PFM reform. The need to contract highly-priced consultants or the original software development vendor increases technical burden.
- Platform: There are many vendor definitions of a “platform” from a technology platform to a full business platform. A full Commercial Off-the-Shelf (COTS) business and technology platform like the FreeBalance Accountability Platform the necessary reuse among components.
- Language: Many enterprise software vendors use proprietary programming languages, often developed during the client/server era. This limits choice to a narrow group of consultants who are able to develop new features and take advantage of any extensibility in the software.
The FreeBalance Approach
We designed the FreeBalance Accountability Platform to be extensible and financially sustainable. An extensibility vs. technical debt scorecard for FreeBalance Government Resource Planning software should consider:
- Coverage: FreeBalance has almost complete coverage across the Public Financial Management Component Map. We’re using the extensibility of our platform to extend in these areas.
- Reusability: FreeBalance uses a component SOA approach.
- Metadata: FreeBalance provides a unified design.
- Integration: Integration with FreeBalance software uses industry-standard web services
- Openness: FreeBalance software is platform agnostic thanks to the Java EE support.
- Adaptation: FreeBalance supports configuration and progressive activation to reduce technical debt.
- Platform: The FreeBalance Accountability Platform is a full business and technology platform.
- Language: There is no legacy technology, no wrapping of client/server code as done by major enterprise software vendors FreeBalance software is built on Java Enterprise Edition, an open system. Java EE is also the most popular choice for enterprise-level web applications.
In addition, FreeBalance pricing considers underlying business objects, that we call “government entities”, so that additional modules become less expensive.
How to Confront Technical Debt in Software Portfolio Management
It is likely that most government organizations have accrued significant technical debt. Legacy ERP and custom-developed software are rampant in many governments. We’ve seen situations where panic ensues when software developers are retiring from government organizations. A realistic upgrade path from “rust” to modern includes:
- Highly customized proprietary core systems for commitment controls and accounting with numerous logical integration points represents the highest technical debt.
- Non-core systems that operate with little need for integration (except at the end of a period) and have not been significantly customized represents the lowest technical debt.
- Replacing the core system can improve management and integration. Reuse of functionality enables the replacement of small sub-systems that were created because of unique mandates. These can be migrated to the core system.
- The need to support citizen-facing functionality is often where the burden of technical debt is realized. Citizens expect a seamless operation that often means talking to many back-office systems.
Unified Design
The unified design of software platforms enables a holistic view of public finance operations including:
- Common metadata to form a single version of the truth to enable decision making, audit and government transparency
- Common controls to prevent arrears and ensure compliance with financial practices
- Common system management to enable change in a single area to cascade across all modules