Skip to main content

ESB As An Application Architecture

Printer-friendly version

While I found this a very compelling architecture, I had one difficulty, which was that the entry price for Fusion was on the order of $75,000. In that my target market went as low as companies with $5M in revenue, this seemed to present an intolerably large base price, one that would effectively block us from a significant part of the market CI wished to target.

Fortunately, Paul Butterworth, VP Technology of Forté, was a very insightful person who quickly understood why this was a compelling architecture for a tightly integrated suite of applications. Through his offices I was able to extend my VAR agreement for the other Forté products, which was based on a percentage of the sale price of the application, to include Fusion, thus allowing me to sell to either large or small customers.

Unfortunately, I was never able to raise the investment capital2 to convert I/S to this technology and, following Forté’s acquisition by Sun, the technology has now faded from the landscape. Fortunately, Progress and Sonic are now reaching the point where a similar architecture can be contemplated in ABL, although some further enhancements such as multi-threaded sessions would make this far easier and more direct.

For the last few years, I have been simply supporting the existing customer base, continuing to evolve the product according to their needs, but making no major architectural upgrades. Recently, the two largest customers ceased to use the software, one because of an ill-conceived move to Oracle Financials and the other because it was purchased by a much larger company with existing software.

Where We Are Today
Therefore, I have refocused my business on the problem of transforming legacy applications into fully modern, OERA3 compliant, ESB/SOA enabled architectures. This will involve:

  1. Analysis tools to extract information from existing ABL applications;
  2. Constructing UML models from this information that completely describe the application;
  3. Revision of the UML to better conform to modern architecture; and
  4. Generation of the complete new application through the techniques of Model-Driven Architecture (MDA).

As a part of this effort, I will have to create an underlying framework for use by the generated applications and I will have to create the template structures to use in generation.

While these tools may be applied to I/S, it is not anticipated at this time to return to active sales of I/S, but rather to focus on the transformation of legacy applications for existing Progress customers and possibly VARs. I feel that there are a large number of Progress sites with either purchased or homegrown applications of significant age who are feeling pressures for web access, supply chain integration, and the like, but whose underlying architecture is very poorly suited to these tasks. I believe that full development of these tools will allow transformation of the entire application, thus putting these companies in an excellent position for the future, but at a cost comparable to patchwork addition of limited integration capabilities.

ESBAsAnApplicationArchitecture.pdf99.45 KB