Skip to main content

ESB As An Application Architecture

Printer-friendly version

How Cheap Is Cheap Enough?
This is clearly a question with different answers in different contexts. If CI is doing an application transformation of a large suite for several hundred thousand dollars, then spending $10,000 for a tool is almost certainly not a problem, unless the tool needs to be deployed across 20 sites, in which case the benefits may or may not be sufficient to obviously justify the price. However, if a customer is implementing a pilot project, then $10,000 might well exceed other costs for the project and be perceived as an excessive investment, blocking the implementation from getting started.

It is an old truism that the best pricing is in relation to perceived value. While often difficult to implement because the substance of which value is composed may be difficult to measure and value to different companies can be different qualities, when pricing relates to value the user has difficulty in not seeing the price as appropriate, even if they wish it was less. Conversely, when the price greatly exceeds perceived value, it is difficult to make the sale. For the case of entry level prospective users of Sonic ESB products, the perceived value is likely to be quite low, especially if the immediate project is little more than a replacement of existing functionality with a new technology. But, this same prospect may well grow into more extensive use and then see greater value.

For example, during the period in which Progress was reselling Actuate and for a brief period had a minimum 2 user license available, I sold Actuate to two of my customers. In one case, the customer was replacing Query/Report, which had not been very useful to them, and they were a customer that was disinclined to spend money for enhancements. They only ever implemented a single Actuate report in production. While they value that report, their perceived value of Actuate is limited to that report. Whereas, the other customer had a keen sense of ROI and implemented many reports and forms replacements using Actuate. When the Actuate-Progress relationship ended and Actuate substantially raised the maintenance rates, the first customer naturally discontinued the maintenance, although they have thus far continued to use the one report. The other customer recognized the growth in the user base served by Actuate in their company and anticipated further growth and thus accepted the new higher figure, despite it being a rather dramatic jump.

The difficulty, therefore, is in arriving at a license basis that can be used to provide an entry level pricing option or to create other, more limited versions. I would suggest that it is generally undesirable to create versions that differ only in some fixed limit on a metric like a user count limit since it is certain that some percentage of the customer base will need slightly more than the limit and will thus be highly annoyed if there is a sharp price increase. For creating different versions, it is better to have a difference in features. This difference in features may correlate to ability to accept load, as it does with Enterprise and Workgroup databases, but this is easier to accept if it is a question of performance or capability than if it is just crossing an arbitrary limit. User or volume count licensing is attractive because it scales so uniformly, but is admittedly more difficult to administer and it is not entirely obvious what metric would be used for scaling in a Sonic context.

I understand that it might be possible for CI to negotiate something akin to the percentage of sale option as was used with Forté, but this is not really appropriate to our current focus on application transformation since this is all services, not product. Moreover, we feel that there is a broad need, not just one limited to CI, and therefore this is an opportunity for PSC that should not be limited to a special deal with an individual company.

ESBAsAnApplicationArchitecture.pdf99.45 KB