Every once and a while someone captures the enterprise IT zeitgeist. Frank Scavo, president of Strativa has done so in a blog post: Time for a Declaration of Independence from Software Vendors? (and a Diginomica podcast with an interview by Dennis Howlett). Frank has witnesses an increase in businesses developing custom software from scratch. Has the build vs. buy calculus changed? Should organizations declare independence from Independent Software Vendors (ISVs) like FreeBalance?
It’s not so much that organizations should declare independence from ISVs, as that ISVs should declare dependence on customers.
[find a ten-point Software Vendor Customer Declaration of Dependence below, skip over the government content if you’re not interested]
Government market build vs. buy
The government IT market is distinguished from the business market by larger proportions of custom-built and legacy software. We see this in our core market: Government Resource Planning (GRP), particularly in developing nations and emerging economies. Public Financial Management (PFM) experts have taken the view that building custom government Financial Management Information Systems (FMIS) is a legitimate option:
- How to Design a Financial Management Information System : A Modular Approach from Gerardo Uña, Richard I Allen and Nicolas M Botton published by the International Monetary Fund in May 2019
- Technological Opportunities and Recommendations for Modernizing Integrated Financial Management Information Systems in Latin America and the Caribbean from Carlos Pimenta and Antonio Seco published by the Inter-American Development Bank in January 2019
- Financial Management Information Systems : 25 Years of World Bank Experience on What Works and What Doesn’t by Cem Dener, Joanna Alexandra Watkins and
In the podcast, Scavo points out that organizations “should not build a general ledger”. Yet, the general ledger is core to government financial management. This is further complicated by the fact that governments operate using commitment accounting.
I know how complicated it is to build a general ledger with multiple levels of aggregate commitment controls, and reporting the budget “free balance” in real time. I remember a conversation with a consultant from a well-established country development consultancy when I told him that FreeBalance fully supported commitment accounting. He asked me if I was sure because commitment accounting is very complicated.
Why do so many respected PFM experts take the view that governments should consider writing custom commitment accounting systems?
How did it come to this?
- Asymmetric Power
- Scavo describes how ISVs wield enormous power once software has been installed
- Governments can be locked into Enterprise Resource Planning (ERP) technology stacks of proprietary databases, middleware, and programming languages (not to mention hardware for in-memory computing)
- Custom-developed software limits vendor power over governments, although this can be an illusion of control
- Bad ISV Behaviour
- Scavo describes how some ISVs leverage asymmetric power for bad behaviour, called “wallet cracking” (coined by Brian Sommer), including suing customers, charging for indirect access, and increasing maintenance prices
- Governments have the responsibility for spending public money effectively, to achieve “value for money” where rent-seeking behaviour by ISVs should not be tolerated
- Custom-developed software reduces opportunities for vendor rent-seeking, although governments cannot avoid technology providers altogether
- High Profile ERP Failure in Government
- ERP failures in government range from small million dollar to large billion dollar boondoggles like the Phoenix Pay System in Canada and many from the United States Department of Defense
- Governments are under political scrutiny for large IT projects – it’s one thing when a corporation squanders money, it’s a completely different thing when governments do so (blame for the Phoenix Pay System is a political hot potato lofted between the Liberal and Conservative parties)
- Custom-developed software gives governments the ability to roll-out software in small modules to avoid big failures, yet there are significant numbers of custom-developed failures in government like healthcare.gov, and we’ve seen many governments go to tender to replace unsuccessful custom software with new custom software (also see points 1 and 5)
- Code Customization
- Scavo points out that much of the Commercial-off-the-Shelf (COTS) available is “inflexible” requiring significant customization to meet needs (and the Gartner Group has gone so far to deem this software as “legacy”)
- Government requirements differ significantly from business needs meaning long cycles of code customization (to the point when many PFM experts call it “Customized-off-the-Shelf”), resulting in quality problems, with the additional cost to maintain and upgrade orphan code
- Custom-developed software seems to have the same complexity footprint for governments as ERP (although, I argue below, GRP is far less complex)
- Software Predictability
- Detailed requirements are described in government tender documents for core and peripheral FMIS systems
- Government processes are often unique because of legal requirements and complex processes that are well-understood by public servants
- Custom-developed software seems to have high predictability where expertise lies within governments, although, in practice, these projects are rarely predictable and the waterfall concept of fully-planned projects are often the source of failure
- Poor SI Behaviour
- Scavo also points out that large Systems Integrators are often at fault for implementation failures, often driving unnecessary customization in order to increase revenue – it’s a phenomenon that Michael Krigsman calls the “Devil’s Triangle“
- Governments often prefer to contract with large systems integrators as a mechanism to reduce risk
- Custom-developed software can take large systems integrators out of the mix, although many custom-developed application projects are outsourced to SIs
Do governments face two ugly alternatives?
It’s not either ERP COTS or custom developed FMIS for governments. There is the GRP alternative, like our FreeBalance Accountability Suite. Government Resource Planning is software designed exclusively for government. FreeBalance is the first global GRP with implementations in about 30 countries.
Some observers assume that GRP has inherited all of the evils of COTS. Other observers assume that GRP ISVs cannot compete with major ERP vendors. I’ve learned a few lessons in this GRP business:
- Single Domain Software
- A senior government finance ministry official once laughed at me at a conference when I told him that FreeBalance software was mostly configured to meet requirements – it is this configuration that accelerates implementations, reduces project costs (especially compared with ERP solutions), and enables future flexibility for change, something we call “progressive activation“
- Some observers see very little difference between “configuration” & “customization” , yet there is a significant difference, where some vendors incorrectly call programming scripts as configuration and code generators and workflow suites are often presented as “configuration”
- The laser focus on government gives us insight into the domain lacking in many large companies, such as the large ERP vendor who tells public sector customers that line-item budget controls are a “best practice”
- Economies of Scale
- The ERP market took off in 90s bolstered by Y2K concerns combined with ISVs leveraging functionality from one market to similar market, offering higher quality & better support achieving economies of scale compared to “best-of-breed” vendors, yet today multiple-market software has become bloated
- Economies of scale diminish as new markets are entered – many vendors have been acquired to fill up product portfolios, creating what Ned Lily of xTuple calls the “ERP graveyard” where major vendors face staggering complexity to maintain so many acquired technologies
- Large vendors leverage proprietary databases, middleware, and programming languages to lock customers into technology stacks – this requires significant investment at a time when agile ISVs leverage open source alternatives
- Integral Product and Process
- Many ISVs seek to scale through partner VARs and Systems Integrators to the point where customer knowledge is lost, and implementation success rates are diminished putting ISVs out of touch with customer realities
- On the other hand, ISVs often seek consulting contracts with strategic clients in order to drive product priorities, and I often wonder how the majority of customers feel when deemed not strategic
- We see all customers as strategic, because as our President and CEO, Manuel Pietra often says: “we have only one customer per country – the government, and we’re in it for life”
Declaration of Customer Dependence
Many of the points were inspired by the Time for a Declaration of Independence from Software Vendors? blog post including Web APis, open source, low-code/no-code.
Independent Software Vendors (ISVs) should admit and commit to serving customers first to build financially sustainable businesses.
- Corporate Social Responsibility: ISV codes of conduct should recognize that customers are the primary community for social responsibility efforts, and should ban egregious rent-seeking behaviour
- Executive Accessibility: ISV executives should be accessible to customers to improve product support, company procedures, and customer understanding
- Build Value: ISVs should focus on building value as the main vehicle for customer retention, and recognize that value may not come from adding features and may come from something outside of products like services or process changes
- Domain Expertise: ISVs should not enter new vertical or horizontal markets unless building domain expertise in product development and product management
- Implementation Governance: ISVs should be part of the program governance structure for important implementations, rather than take a “hands-off” approach, in order to mentor partners and customers
- Flexible Adaptability: ISVs should reduce the burden of code customization through no-code configuration and low-code techniques to accelerate implementations, improve future changes, and reduce customer costs
- Feature Management: ISVs should commit to reducing implementation code customization needs with a clear framework of how important features will be added to product roadmaps
- Cooperative Innovation: ISVs should commit to customer-led innovation with a clear framework of how cooperative innovation and development will be enabled
- Open Systems: ISVs should commit to supporting and using proven open systems, including open source, to give customers more technology choices while reducing proprietary lock-in
- Business Platforms: ISVs should seek to provide APIs and reuse from product platforms to enable custom development when it is justified, while eliminating charging customers for functionality already paid for
My thinking on the declaration rose from my guest blog from 2014 at ZDNet: IT failures, power shifts, and social media edited by Michael Krigsman. Customers can band together leveraging social media. I pointed out some interesting behavioural changes in leading enterprise software companies at that time:
- SAP and Infor have adopted design thinking to become more customer-centric
- Microsoft added a concurrent licensing option for the Dynamics product line.
- Negative customer reactions forced SAP to change pricing policies on premium support and the Fiori user interface upgrade.
- Salesforce.com was rebuffed in its attempts to trademark the term “social enterprise”
Since that time, SAP has changed their “indirect access” model.
Is it only a build vs. buy world for governments?
Scavo points out that business platforms from application suites, like the FreeBalance Accountability Platform, can be leveraged to develop custom software. It’s far from a build vs. buy binary choice. There are hybrid build and buy alternatives.
Many governments seek to build software using a standard Integrated Development Environment (IDE) using a technology. A “governance platform” is a hybrid approach by including all build aspects of technology platforms with reuse of buy functions used by the GRP COTS. And, low-code/no-code can enable what was once custom development on GRP Suites as a more buy than build alternative.
How can governments make the right build vs. buy decision?
Scavo identifies a number of factors that can help governments make better build vs. decisions that I’ve tried to diagram.
- Industry-Specificity: Many ISV 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
- 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
- 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