Home
 > Research and Reports > TEC Blog > Consona’s CEO Clearing the Air (about Compiere) - Part 2

Consona’s CEO Clearing the Air (about Compiere) - Part 2

Written By: Predrag Jakovljevic
Published On: July 16 2010



Part 1 of this blog series talked about Consona Corporation’s recent acquisition of leading open source and cloud computing enterprise resource planning (ERP) provider Compiere. After reading a slew of speculative blog posts (including the one from TEC’s free and open source [FOSS] buff and advocate Josh Chalifour), I had an incisive briefing with Consona’s CEO Jeff Tognoni, to give the company a fair chance to explain its strategy and the rationale behind the acquisition.

In Part 1, Tognoni first dispelled any idea that Consona’s intentions were to to copy the much larger and also acquisitive vendor Infor, as suggested by the related ERP Graveyard blog post. Thereafter, he explained that his interest in Compiere’s cloud platform coincided with (and was validated by) the recent launch of Consona’s CRM Cloud leveraging Amazon Web Services (AWS) Elastic Compute Cloud (EC2) and Simple Storage Service (S3) for the server infrastructure and platform.



It is interesting to note that only a few years ago Consona was not a major proponent of cloud-based delivery, as it saw on-demand customer relationship management (CRM) delivery as a limited tactical and departmental project, which did not mesh well with the vendor’s erstwhile strategy of enabling Total Customer Management (TCM) as a holistic enterprise-wide undertaking. What a difference in strategy a year or two of market reality can make!

Why Compiere?

As its CRM sibling does, Compiere will now enable both on-premise and AWS-based cloud offering for Consona’s ERP division, but it might even go a mile further. Namely, as mentioned in Part 1, Consona was particularly attracted to the open source concepts and low cost structure at the platform stack level. Thus, as Compiere runs on a completely open source stack (e.g., Java, Linux, Jboss Developer Studio [JBDS]ApachePostgres, etc.), Consona this way avoids dependence on any large vendor’s proprietary platform stack (e.g., Microsoft, Oracle, IBM, Force.com, etc.).

Moreover, Compiere features a functional and device-independent Web browser- and Ajax-based user interface (UI) that leverages the versatile Google Web Toolkit (GWT) without the need to hard-code every window. Perhaps most important is the fact that Compiere might have the most modern architecture of any ERP product, as its on-demand offering is a brand new product (incepted only about 18 to 24 months ago). The product was built from the ground up for cloud computing, thus overcoming some shortcomings of the software as a service (SaaS) products that were architected in the late 1990s.

In other words, Compiere’s architecture is reportedly so flexible that upgrades can be done automatically without retrofitting customizations. In contrast, most multi-tenant SaaS vendors are able to automatically upgrade their applications without affecting users, but only if these users (tenants) have not meanwhile heavily modified their product instance. Perhaps some modern platform as a service (PaaS) offerings such as salesforce.com’s Force.com will allow significant customization and creation of custom objects, but I am not certain whether any mass salesforce.com system upgrade can go entirely smoothly and without any tweaking and preparation work for the modified business logic of product instances.

Another typical issue for vendors that offer both SaaS and on-premises software offerings is that bi-directional migration paths are not typically that straightforward. That is to say that there are always nuances in these products’ codes and data schemes that require some fiddling before a customer can easily move from, say, an on-demand subscription to owned on-premises software.

Compiere made several critical architectural decisions about two years ago that led to the achievement of a possibly unique and differentiated cloud architecture. For one, Java 2 Enterprise Edition (J2EE) acts as the middle-tier language for customizations and is widely embraced as the language of the open source community. In addition, model-driven architecture (MDA) allows data structures, UI forms’ appearances, and business logic references to be all stored in the private-tenant database.

The result of these critical decisions is the creation of a reference architecture for cloud applications. In this setup, any customized form or customized form changes are described non-procedurally, while customized business logic is packaged separately from the base application logic, and only the underlying platform gets upgraded during the next product release.

Automatic Upgrade of SaaS Customizations: No Small Feat

As do most of its SaaS peers, Compiere accommodates light customizations whereby forms, reports, and workflows are defined as metadata in the database and can easily be changed by any authorized user. But the product also allows deeper customizations, whereby any type of complex logic can be added to the system. This information is coded in Java and inherits the properties from the core functionality of the application. Triggers to these customizations are also defined in metadata and stored in the database.

Both types of customizations can be upgraded automatically from any version of the Compiere platform to any other version. In that sense, while being single-tenant (or private-tenant in Consona’s lingo) at the database and infrastructure level, Compiere is multi-tenant at the application level in a sense that all customers will be on the same base product release. Thus, pragmatically speaking, Tognoni says that he has yet to have a prospect tell him:
"You know, I do like your product's functionality and price, it is both on-demand (subscription-based) and on-premise (perpetual license), and it preserves my system modifications, but, darn it, I just cannot buy it since you are not truly multi-tenant in a public cloud."

With its component assembly software development, Compiere should help Consona leap forward on its architectural vision of assembling applications. Compiere already has core horizontal functionality delivered as a base. Moreover, the product already has vertical market extensions delivered on top of that base as well as customer-specific extensions delivered on top of those vertical market extensions.

What Went Wrong at Compiere Then?

In summary, Compiere is the realization of decades of research into the proper architecture for component-based software development, but it also happens to be fully cloud- and open source-based. The unfortunate development for the previously independent vendor was that its shift to the cloud strategy came late in the venture capital (VC) cycle.

These days, it is much easier to acquire a capability than to develop it internally, especially if a company is a cash-strapped startup, which Compiere still was. In other words, Compiere needed more investment at the time when its original investors were losing patience, expecting their payday, and did not care to now hear about a new development cycle and change of course. Still, according to Tognoni, the fact that NEA IndoUS Ventures, Compiere’s initial investor, did not cash out but rather opted for stock holdings, might speak volumes about the vendor’s attractive value proposition.

Now What?

As stated in Part 1, Consona reiterates that Compiere was a technology buy and the main priority is to ramp up the distribution channel, sales, marketing, and product development in order to attract new on-premises and full-service cloud-base customers. Compiere is the world’s leading open source ERP solution, and has about 130 license-paying customers in the distribution and manufacturing industries.

Tognoni compares Compiere’s wholesale distribution-oriented functional footprint to that of NetSuite (see my recent related blog post). Compiere complements Consona’s existing ERP products, both functionally (distribution industries) and geographically (customers are primarily in Europe).

Initial global growth will thus be focused on the Compiere product line [evaluate this product] and continuing down the existing path (with an emphasis in distribution markets) with additional scale and resources. Consona admits the importance of properly addressing the product’s feature and service gaps to gain vertical market share while retaining the value proposition of open source and SaaS.

Consona’s full commitment to Compiere’s technology approach in not in dispute here. What the company plans to do now is to painstakingly discuss the product’s roadmap with its staff, partners and, most importantly, existing customers. The vendor intends to gauge these constituents’ areas of interest for features development and closing functional gaps.

Caveats Remain for Sure

I should point out here that Tognoni was not trying to sugarcoat the issue that there is still much figuring out to take place with regards to how Compiere will fit in with its non-FOSS and non-cloud ERP brethren. Tognoni and his team do not claim to have all the answers about different product development, sales, channel, and partnerships cultures between open-source and conventional commercial software companies at this stage. As one example of a possible conflict, Consona’s existing ERP solutions are not primarily sold via of indirect channel and value added resellers (VARs), which is, and will continue to be, Compiere’s prime distribution model.

In addition, delivering a SaaS solution based on open-source software is a tricky proposition. To achieve economies of scale for the vendor, and to deliver fast new feature development for customers, one must impose a strict version control.

And yet, version (revision) control becomes very complicated within a vast open source community of users that liberally modify the software’s source code. The issue can get compounded especially when one is selling software as both an on-premise and a SaaS solution. For example, how do new features developed by on-premises customers with source code get into the cloud version of the software?

To that end, Consona pledges to take excellent care of these 130 commercial Compiere customers, which are logically much easier to control and serve. But the vendor has not yet closed the door on the FOSS community. Tognoni is not averse to tapping into the “wisdom of the crowds,” but that needs to be mutually beneficial and not turn into a side show of a sort. After all, Consona is in the business of making money (and paying back its loans and debt) and not necessarily in any charity or philanthropic work.

Further extensive planning and pondering is required to determine changes to the Compiere product roadmap, to possibly implement customer-driven development processes, and to even assess all of Consona’s ERP product offerings for feature crossover. There might be the possibility of rewriting some manufacturing business logic from Consona's on-premise ERP systems for Compiere, and vice versa, "borrowing" Compiere's distribution capabilities for its on-premise brethren. Also, Consona is hoping that some existing on-premise ERP customers might opt for on-demand Compiere for their distribution needs, in a hybrid software plus services manner.

Cannot Pass on the True Multi-Tenant Debate

While I agree with Tognoni about customers not being overly concerned with the academic “multi-tenancy in the public cloud” discussion, my concern remains whether the isolated or private tenant arrangement via AWS is the best strategy in the long term. A cautionary vendor tale about the benefits of multi-tenancy vs. single tenancy is SAP Business ByDesign.

Namely, the well-publicized product started out as a single (isolated) tenancy at the database level, but is being re-architected to multi-tenancy. SAP belatedly realized that it simply could not profitably support the product and scale it up at the same time. The following quote from a 2009 article from Rainer Zinow, innovation VP at SAP Business ByDesign, sums it up:
"Everyone wants to buy it, but the issue is how we can make money. The cost of operating the system is so high that we can't meet the profitability targets that our chief financial officer assigned to us."

Indeed, in any single-tenant environment, every new stack must be separately provisioned, managed, and scaled. Conversely, in a multi-tenant environment, it is faster, easier, and more cost-effective to create development, test, staging, training, and production environments, because additional infrastructure typically doesn't need to be provisioned per customer (tenant).

As the number of customers grows, the vendor has to spend more time and money adding infrastructure and operations staff to support the individual stacks and less time focusing on delivering new applications. It also becomes harder to support customers with proliferating isolated stacks (i.e., there are sometimes a few stacks per customer as to accommodate production, sandbox and test, and other environments).

In a fully multi-tenant environment, costs decrease as usage grows, letting the service provider invest in innovation and customer success. Multi-tenancy also helps ensure that the product will meet customer needs. For example, in salesforce.com and NetSuite's multi-tenant, cloud-based services, the development team can monitor functional usage trends both in real-time and historically. This is hard to achieve when you have isolated infrastructure and separate databases.

While the cost-effectiveness of AWS and Compiere’s open-source stack are logical options for Consona now with only a few cloud customers, time will tell how that equation will work when the number of customers reaches hundreds. Certainly, in my opinion, the vendor inefficiencies and the highly skilled headcount that rapidly increases to support a growing number of isolated stack deployments might soon negate any attempts to mitigate operations costs by saving on the underlying infrastructure by choosing inexpensive open source stack.

Private Tenancy Means Customer Intimacy?

To help drive his point, Tognoni cited a new Compiere customer’s reasons the company left NetSuite in order of importance:

  • Limited customization ability and forced upgrades on the vendor’s schedule not the customer’s. (This meant they had many things break every time these upgrades came at them and caused them multiple systems outages locally.)

  • The unnamed company is a fast growing (light manufacturing and distribution industry) and the computing environment of NetSuite did not scale with them, they went from having reports taking 2 minutes to run to 20 minutes over a 6 month timeframe as their transaction levels increased.

  • There is a reason AWS calls their service EC2, the E stands for Elastic. NetSuite's internal computing facility is not very elastic because it is built pre AWS style of cloud operating environment.

  • Depth of functionality as well as NetSuite’s perceived lack of a roadmap to really address this. They got the impression that NetSuite was more interested in building a “mile wide but an inch deep” application with ease of use and attractiveness of the UI but not on deepening the functionality.  When they got below the first level of functionality, it was not robust for distribution and manufacturing and they felt this was not really important to NetSuite’s product development.

  • Lack of multi-company, multi-currency capabilities without completely re-implementing to NetSuite’s "other" version.


Tognoni then went on to say:
“All of these problems with SaaS 1.0 multi-tenancy at the application level are eliminated with our approach to cloud computing and the Compiere architecture as well as our focus on building out vertical by vertical depth as a strategy.  NetSuite will be at a serious disadvantage to Compiere in distribution and manufacturing when we scale up our sales efforts.  Also, our CRM cloud services already offer answers to these problems.

So the answer is that the strategy we came up with 18 months ago for cloud computing is going to win in application areas where you need a moderately to highly complex solution.  SaaS 1.0 (salesforce.com, NetSuite, and Concur) will work fine for simple and generic application areas.  The above confirms our strategy coming unprompted from a real customer that experienced SaaS 1.0 and found it lacking and is now moving to our approach without us even selling them on it.”

In any case, it will take some time for Consona to gather a critical mass of cloud customers where full multitenancy begins to prove more effective. I agreed with Tognoni to revisit the Consona/Compiere state of affairs in six months or so, when many of these blurry issues today should hopefully be much clearer then.

We will have to stay tuned to see how the value propositions of FOSS and cloud computing will further be explored by Consona. Your views, comments, opinions, and particular experiences with Consona and Compiere are always welcome in the meantime.
 
comments powered by Disqus

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.