February 14, 2011Doug Hadden
Doug Hadden, VP Products
Enterprise technology is obsolete. Take the icing off the technology “wedding cake” to find legacy client/server code. You’ve seen these very elegant diagrams with lots of boxes and arrows.
Should we care that the majority of software technology used by enterprises and governments is based on legacy technology? Some contend that technology no longer matters.
Here’s the argument: governments will have to customize the code anyway to meet unique requirements. Regulations, laws, national standards. And, governments will have to continually change the software code to reflect public financial management changes. So, the best thing is to develop coding expertise to keep legacy software alive.
And, by “customization”, I mean: writing and maintaining software code. (Ok- there are various levels of coding from “call-outs” and workflow scripting to down-and-dirty coding.)
A Sad State of Affairs
There seems to be a general acceptance of this expensive state of affairs. The frequent failures for private sector software in government is blamed on the customer (i.e. blame the victim) or systems integrator for not having the right process, governance methodologies, project commitment. It’s rarely blamed on the orignal vendor who provided the software in the first place.
Should government customers accept this state-of-the-art of:
- High customization and maintenance costs
- Adapting government proven-processes to so-called industry “best practices”
- Product sunsetting and high upgrade costs
- Perpetual outside consultants who understand the underlying legacy technology
- Complex software requiring significant training
Building special modules for unique needs because the functionality is missing in private-sector software
There is an Alternative
FreeBalance and the approach that we’ve taken is an alternative.
Don’t get me wrong: major enterprise software vendors have problems that I don’t want to have. Multiple acquired applications each using different programming languages. Multiple vertical and horizontal markets. That’s the advantage of being agile: you avoid these problems. Here’s the FreeBalance approach:
- Rebuild software using the latest architecture good practices (and make it open) so that there is no client/server translation layer, no legacy code constraining options. In other words, technology matters.
- Design with government exclusively in mind – the government domain for all functional and non-functional needs (i.e. GRP, not ERP).
- Software designed for shared services rather that re-purposed with brute force.
The Pendulum Swings the Other Way?
The enterprise software industry changed in the late 90s. The most successful vendors moved from single industry solutions to multiple industries. These vendors acquired other vendors. It was thought that it was less risky to buy from the very largest vendors.
Things have changed in the early 10s. For one thing, customers feel unheard by the largest vendors. And, there are alternative models such as cloud computing. This has caused many to reconsider the state of affairs. Especially when it is easier for agile vendors to create product suites using proven components and following standards. (Rather than proprietary middleware that is used to lock customers into legacy suites.)
Of course, some observers are incredilous.
How can FreeBalance have better technology? These larger vendors are very large – but their business is built on old technology, existing supply networks and they require the economies of scale to make middleware equivalent to open source.
How can FreeBalance meet needs through configuration? A single domain-government. (And, our platform has government-functionality built-in, so customers and consultants can build custom solutions for government fast too.)
How can FreeBalance win competitive tenders? Most of these tenders are 5-Year total cost of ownership. Lower hardware cost through an optimal footprint, ease of implementation and maitenance through configuration, less training – you get the point.
How can FreeBalance have more successful implementations? We have a track record of more on-time, on-budget, government-sustainable implementations than alternative solutions. It’s because of domain focus, including adapting our implementation methodology exclusively for government.
In my view, it is time to question the assumption that “bigger is better” in software. It’s time to question technology. To look at what really works.
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016