The genesis of many application software products is a great idea. Someone conceives a better, newer way to achieve a business outcome, complete a process, etc. That idea gets codified and becomes an application. In some cases, it becomes a process-wide collection of applications (e.g., how ‘Financials’ can contain several discrete applications like general ledger, accounts payable and accounts receivable).
Yet, the purveyors of these solutions will want more. They will want more customers, more applications and more revenue. To achieve these goals, the vendor will either create additional applications or buy them from other firms. In the former scenario, a smart vendor will make all these applications from one common architecture, use all of the same development and execution tools, have the same user interface, etc. These new applications will be extremely well integrated to each other and to the architecture that they share. A customer will assume these new applications were always part of the vendor’s original product suite.
In contrast, the acquisition path may present a faster way to achieve certain financial goals but could create longer-term issues. In the acquisition model, acquired applications are often lightly integrated to the vendor’s legacy applications. These products are stitched together. They often look like they originated from different vendors and with different underlying tools/architectures. Vendors may promise that future versions will eventually coalesce into a single unified solution but that may take many years to occur.
Like the Frankenstein monster of film, the stitched together product suite looks like something that could terrorize villagers everywhere. And, like the film monster, the stitched together product suite looks odd. Some acquired applications will be overkill. Some will be underwhelming. Some could possibly be rejected by the host body. But, with enough of your maintenance monies, a powerful electric jolt could bring this monster to life.
Yet, the ultimate manifestation of ERP’s Franken-soft occurs when a vendor continues to expand their solution via more, redundant application parts of cadaver software firm donors. These acquirers may possess several redundant applications of most everything in their product line. Need a CRM solution? They have three of them. Need a general ledger? Pick one of the six they have available.
These massive product suites may generate maintenance revenue for the vendors. They may even create some additional in-fill sales opportunities. But, they also dilute the research and development budgets of these vendors. Why? Vendors will need to sprinkle a bit of R&D spend on every acquired product line and application to appease these customers and have some sort of story that proves that their maintenance monies are going to enhancements.
What’s behind the creation of Franken-soft ERP firms? I suspect that some software firms may acquire adjacent solutions (e.g., a financial software firm acquiring an HR product line) to gain more customers, more maintenance revenue and more in-fill sales opportunities.
But, when software companies start acquiring redundant products or product lines, they’re just out for short-term revenue and sales gains. They’re putting short-term shareholder concerns over those of their long-term customers. They’re also throwing in the towel on innovation, too. They’d rather buy more customers than earn them.
When a vendor possesses so many redundant applications it could also slow down their progress to the cloud, their approach to adding analytic capabilities, their mobility solutions development, etc. Why? Each of these new technology directions (e.g., cloud, mobile, social, video, analytics, etc.) requires an existing application (and its attendant process design, data model, etc.) to be re-thought. If a vendor only has one of each application, the effort can be big. If a vendor has dozens of redundant applications, the effort grows arithmetically.
A vendor with a history of stitching together acquired or new technologies to existing products will see new tools like analytics, cloud, mobile, etc. as merely something else to append to the Franken-soft creation. That’s a mistake. Some things, like a new application, can be bolted to the existing suite and may, in fact, deliver value to customers. Other items require platform changes, data model changes and more.
At Workday’s recent user event in Las Vegas this week, analysts saw the following:
- Workday management expressed zero interest in acquiring other technology firms, especially in the recruiting space (a space that Workday announced it is building a new solution within). While Workday might acquire a specific tool, any acquired application would have to be re-written to fully exploit Workday’s architecture and to maximize the application’s usefulness with other applications and users. That signals that Workday does not want to pursue a Frankensoft strategy.
- Dave Duffield (co-CEO) spoke of the power of one. In the context of his remarks, he spoke of how having all customers on one release, one code base, one tech stack, etc. was permitting customers to spend less on software maintenance and to take advantage of the latest functionality as soon as it was available. But, there’s another part to this. Workday’s power of one also applies to the singularity of their product line and architecture. There is only one set of applications, one user interface, one mobile solution set, etc. It is this singularity that permits Workday to move at least as fast as businesses and technological innovations occur. Franken-soft solutions cannot move that fast.
- Workday has added analytics to their product set. While one level of these analytics was designed to utilize data within the four walls of the existing Workday application suite, we also saw that Workday has re-configured their architecture stack to include big data capabilities, Hadoop processing and more. The results of this mix of structured and unstructured data will be immediately visible to users of the Workday applications. This is interesting as they’ve gone beyond setting up a separate data store to crunch big data. They’ve fully integrated the world of non-Workday data and Workday data. They’ve made it simple for Workday users to develop crushingly cool analytic results from within Workday apps. And, most importantly, they did these architectural changes without impacting any of the existing customers. By not being a Franken-soft monster and by using a multi-tenant cloud solution (that powers the ‘power of one’ concept), they can make a massive change to the product with no disruption and no cost incurred by customers. That’s impressive.
The Workday event was quite a positive event. Some of the announcements, like the analytic one above, were possibly lost on the mostly HR attendees in the crowd. But, for those who care about the structural stuff of software solutions, the difference between Workday’s offerings and those of the Brand X folks is startling.
Disclaimer - Workday provided airfare and hotel accommodations to their conference. No other consideration was offered.
Join Discussion for: ERP’s Franken-soft and how Workday avoids...