September 16, 2011Doug Hadden
Doug Hadden, VP Products
Companies that achieve “economies of scale” have a competitive advantage: ability to offer lower costs. The consolidation of the Enterprise Resource Planning (ERP) market gives the remaining vendors this advantage.
Or does it?
ERP companies have not achieved economies of scale.
What’s the proof point?
The burden on customers to customize ERP software to meet requirements.
Vertical and Horizontal Solutions
ERP companies provide solutions in multiple vertical markets (or industries) and horizontal markets (business functions). This can be shown in a diagram.
The larger ERP vendors provide solutions in almost all of these markets. It’s true that it’s easier to build a product for a particular market when one has a product in an adjacent market. This provides extensibility – the ability to extend into other markets at a reduced cost because much of the work has already been accomplished.
Yet, economies of scale have not been effectively achieved by these ERP companies. Why?
- Product portfolio size is so much larger that coordination problems are introduced. The larger the portfolio, the greater the communications problem in product development adding layers of coordination among product managements and software developers.
- Legacy software languages are used rather than modern object-oriented languages. This reduces the ability to re-use functionality. “Re-factoring” is often necessary.
- Acquisitions by large vendors reduces economies of scale because these ERP vendors are supporting more than one technology in many markets, sometimes up to 6, each with different legacy technology. This also adds to the intra-suite integration burden.
- Size of code base and databases increases because of product portfolio making it more difficult to manage.
- Infrastructure support for operating systems and databases adds complexity because of the need to port legacy technology and integrate with new platform.
ERP companies also develop proprietary middleware. This can also be shown in a diagram.
Middleware technology is needed to deploy enterprise-class applications. ERP vendors have built or acquired middleware technology often providing a complete proprietary “software stack”.
Yet, economies of scale have not been fully achieved by this approach. Why?
- Open source technology has replaced most of the software stack. The perceived value of proprietary stacks has waned. ERP companies are faced with upgrading and maintaining software in the wake of open source advancements. Open source has much better economies of scale.
- Legacy software increases the burden for supporting open technology standards. And, scalability becomes difficult as ERP vendors attempt to find ways of scaling legacy technology.
- Multiple markets makes it impossible to design middleware optimized for every customer context. Hence, the resulting ERP software tends to be bloated because it has to adapt to every context.
FreeBalance has achieved some interesting economies of scale. Primarily by taking the “route less traveled.”
The laser focus on government, in what many observers call “Government Resource Planning” (GRP) reduces portfolio burden on FreeBalance.
Some economies achieved include:
- Configuration rather than customization approach makes the software easier to implement, adapt, upgrade and progressively activate.
- Budget-aware applications are tightly integrated for the government context. Human resources, grants management, procurement, asset management etc. applications respect budget controls and commitments.
- Government metadata like the chart of accounts is shared across the portfolio.
- Hands-on approach to implementation means that FreeBalance builds products based on direct government customer experience including using implementers in product design. This eliminates confusion in product design and achieves clarity.
The FreeBalance middleware approach is also different.
This middleware approach achieves economies of scale by:
- Modern software language, Java Enterprise Edition, is the only language used. Java EE is an object-oriented language. FreeBalance develops software based on a Public Financial Management Component Map whereby extensibility is planned in advance.
- Government Entities or reusable business objects have been designed. These objects are easily extended and reused across the portfolio. (And, also available for 3rd parties building government-specific applications.)
- Open source middleware that is proven in enterprise-class implementations is used. Of course, some assembly is required – but not to the extent of building this from scratch.
- Government design in the platform has been achieved by choosing effective middleware and adapting that middleware for the government context. This builds from the “non-functional” requirements that enables deploying software with an optimal footprint and complies with Green IT concerns.
FreeBalance has learned from best practices in software design. (Our processes are ISO-9001/2008 certified). Software developers who begin working with FreeBalance are pleased about the elegance of the platform design – what we call the FreeBalance Accountability Platform. Especially relative to the leading Integrated Development Environments (IDE) used by very large enterprise software vendors.
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