Skip to main content

ESB As An Application Architecture

Printer-friendly version

Sonic “Lite”
In discussing this topic with a John Green6, he said:

“I like "lite" products, as a vendor, because they serve to confuse the market. If a prospect thinks that they just want a low end solution, then they go get a low end solution, and they are done. If you have both low and high end solutions, then when evaluating your low end solution (for comparison to other low end solutions), they invariably also do a comparison of your low end solution to your high end solution, just out of curiosity. More often than not, that curiosity leads them to the decision that what they really want is the high end solution.”

This alone, I think, makes a good argument for having entry level versions of all of the Sonic products, but I would add to this that there are many additional customer profiles for which having an entry level product is also desirable. These include:

  1. Someone who has a pilot project with modest ROI, but which could serve as the springboard for a whole series of projects. An entry level product allows them to get started within the budget constraints of the pilot, but then to grow into full use of the full product when the technology has proven its value in multiple cases;
  2. Someone moving into a new area, e.g., supply chain integration where the known benefits would not justify a large expenditure, but there is possible growth to greater scope;
  3. Someone whose initial needs are only for Message Oriented Middleware for reliable communication, but who could find other benefits if they made that implementation on a platform which allowed for easy and modestly priced additions; and, of course,
  4. Someone looking at application transformation to an ESB/SOA architecture for tightly coupled applications, but no immediate EAI requirements.

In all of these cases, there are likely to be budgetary concerns that will push the prospective customer in the direction of low end or open source products. If they move in that direction, they are unlikely to return to Sonic, even if their requirements then grow, unless their selected technology fails them in some substantial way. Alternatively, if they select Sonic from the beginning, they will remain “in the family” and, in many cases, will grow to more complete use of full-featured versions and additional products over time.

Don’t make the mistake that Actuate made of limiting growth by shutting out all but the high end customers ready to make large commitments.

Written 29 May 2006 and presented to a group from Progress Software at Exchange 2006

  • 1. A classic case of time-dependent routing is placing a service request in the queue of a credit representative and then moving it to the queue of the credit manager if not handled within a particular time span. One of the more interesting and complex examples of workflow routing was seen in a scheduling system for TransCanada Pipeline where there were many independent computers involved in scheduling traffic through the pipeline. Many of these computers were old and unreliable, making manual access for scheduling tedious and lengthy. A Fusion application automated the scheduling process and included logic that could even restart a non-responsive server and summon tech support if a server could not be reached in an appropriate time
  • 2. Ironically, deciding to move to Forté as a technology platform meant that I no longer had the “sizzle” of SDD by which to distinguish CI from other YACSDS. Our second effort at recruiting financing and officers never got past this perception problem.
  • 3. OpenEdge Reference Architeture
  • 4. As an alternative to multi-threaded sessions, PSC could consider providing a mechanism for extremely rapid interprocess communiction. This would not be as desirable as true multi-threading, but would, at least, provide a better foundation for closely cooperating separate lines of execution such as are needed for fine-grained connection of components
  • 5. At this time I am not very familiar with the Sonic Database Service. My expectation that it can be omitted is based on the assumption that it is acceptable for this product to rely specifically on an OpenEdge database or, if another database is required, that this is already covered by a DataServer license. It is possible that, with greater familiarity with the Database Service, I would argue for an OE-only version as an entry level product and for pricing which depended on the number of databases as well as the number of CPUs.
  • 6. Private communication 5/27/2006.
ESBAsAnApplicationArchitecture.pdf99.45 KB