David Frankel wrote an excellent article called, Software Industrialization and the New IT, that describes what software abstractions are and why we want to raise the level. First we started with 1s and 0s, which is ultimately what the computer understands, but as David points out, there has to be a better way. There is, it was assembly language, ha ha, then third generation languages (3GLs) and then
Model Driven Architecture (MDA) which represents the highest level of abstraction today. As described in David's article, we continue to push the envelope with the next level of abstraction called, Computer-Assisted Business Process Management (CA-BPM) in which
Barry Varga and I have invented one of these for the application integration world.
Ultimately, we want a drawing/modeling tool that allows a business analyst or a person that is not necessarily a programmer, to draw and describe the software to be built. Since we are talking a virtual world here, the construction process (i.e. writing the code) can be fully automated using code generators that know how to read the output format of the drawing tool and code generate the solution to run on a target business process engine or server platform. Therefore turning our incredibly labor intensive and error prone software development process into one that is predictable and repeatable.
Why dont these CA-BPM tools exist today? There are several reasons for this, as discussed in earlier posts, but mostly due to the newness of our industry compared to other engineering disciplines. I would like to introduce you to a CA-BPM tool that can fully describe size and complexity in the application integration domain.
The need for application integration arose from executing business processes across software applications because no one application can do it all (unless it is SAP, right George
For example, when you order your computer from DELL, there are several business processes that are executed. Placing the order, credit card transaction, procurement, inventory and order management, scheduling, back-orders, assembly, test, burn-in and finally, delivery. I may be missing a few steps, but you get the idea. It may come as a surprise that there could be a dozen computer applications/programs used in this end-to-end business process, with each application communicating data to one or more applications. Or at least trying to communicate data, which is where all the integration issues are.
Application integration is considerably more complex, abstract and error prone then straight application development. The
middleware engine is what controls message flow (i.e. data) and
orchestrates a business process (or multiple processes) between these applications. Application integration development is very difficult to understand as it is akin to trying to connect wires together in a wiring closest that has thousands of colored coded wires, yet there is no wiring diagram with numbers or labels or an obvious meaning to the color codes. This leads to a process of discovery that is long, painful, expensive, mostly trial and error and with an end result that may be less than the 20% success rate discussed in the
CHAOS Study.
However, over time, eventually you figure it out and if you do it enough times you get good at it and the more you do, the more you see the
patterns on how it is done and how to do it better each time. This is how we evolved our invention, which after 25 application integration projects over a period of 4 years, Barry Varga and I arrived at
BRIDGEWERX. And by all accounts, it appears we were first to market with this invention.
Tomorrow we reveal our design pattern to show how we can model any application integration scenario that scales to any size or complexity.