Skip to main content

ESB As An Application Architecture

Printer-friendly version

What Needs To Be Included?
There are a number of ways to limit a Sonic offering for use on a single CPU for a single application suite in order to avoid giving away what one would be justified in charging for in an EAI environment. Let us tentatively refer to the desired product as the OneCA Edition for 1 CPU and 1 Application, although application would need to be defined in terms which could cover a tightly integrated application suite (see below for additional options).

The first and most obvious area of limitation is in which products are included or excluded. Products that could clearly be left out of any entry level offering would be:

  1. Any Continuous Availability version, although this should be available for a reasonable increment;
  2. Sonic XML Server;
  3. Sonic Collaboration Server; and
  4. Sonic Database Service5.

Note that while these products could be omitted from the OneCA Edition, it would be a more attractive licensing model overall if there were no painful steps. See discussion below about entry level versions of other products.

One of the more problematic components is the Orchestration Server. While a small company implementing the OneCA Edition on their own in a piecemeal fashion might not immediately think of implementing the Orchestration Server, a company who used our forthcoming transformation service would be strongly oriented toward externalizing workflow into a business process management tool. Not only I would tell them that they should do this, but I would be wanting to create the MDA model so that this happened. At a $25,000 entry price point, I would probably be forced to offer an open source BPEL engine instead. However, it is also almost certainly the case that the complexity of logic managed by an installation in one of these customers would be very modest compared to the logic managed by the typical existing Sonic Orchestration Server installation. Were it possible to have one or more “junior” or “standard” edition versions as well as the existing “Enterprise” edition like with some of the other products, it would be easier to get companies started on this path.

Other than excluding products and providing more limited editions of products, the other obvious way in which to provide lower entry pricing is to limit products according to some metric such as users, message volume, connections, and the like. This is, of course, far from easy to do in a way that is widely viewed as fair, as is evidenced by the unhappiness about licensing sites that involve web access.

Entry Level Versions of Other Products
To create a licensing context in which there can be a graceful transition from a readily affordable entry point to full use of the product range, one also needs entry level offerings of products not included in the core entry package. For example, a company with no supply chain partners who implemented the OneCA Edition and then added a supply chain partner would find an additional price of $35,000 for Collaboration Server to be rather shocking. Of course, with only one partner, they might also find the Collaboration Server to be unnecessary, but at that price the requirement needs to be substantial before the product becomes attractive. Similarly, having to spend 4 to 10 times the price of the entry level system in order to obtain Continuous Availability would be highly unpleasant unless the Sonic ESB Continuous Availability edition also had other features which were seen to be of value.

User based pricing has this attractive character of allowing small incremental increases in licensing cost in relation to small incremental increases in usage. Of course, this varies according to the definition of “user” and its relationship to the business value of additional users, but if these are reasonably in sync, it is a license model which provides for graceful growth.

ESBAsAnApplicationArchitecture.pdf99.45 KB