Have a look at this object model.  This is our modeling design pattern that Barry and I figured out after designing and constructing 25 application integration solutions over a 4 year time frame.  This design pattern raises the level of abstraction for designing and constructing application integrations into a fully automated process that is predictable and repeatable.

 

 

How does it work?  We have taken our design pattern and implemented it as a drawing/modeling tool, much like AutoCAD, where you can draw your application integration scenarios on a canvas.  The modeling tool produces a full-fidelity or complete design specification output in which a code generator can read the completed specification and automatically produce (i.e. code generate) the solution, wrapped as an installation package, much like using an installation wizard to install a program on your computer.

 

At run-time, there are several administrative, operational and monitoring tools that are provided to manage the solution that are installed on a pre-configured technology stack, including a middleware engine.  In fact, everything can be pre-installed onto a DELL server and delivered as a complete integration appliance.

 

Here is another view of the object model as represented by the layers or levels in our modeling/drawing tool.  This is how we visualize size and complexity.  Just like how AutoCAD has many levels of detail, we do too.  We can view the upper most level to see the big picture (which may contain dozens of application integration scenarios across several business entities) and yet drill down, level by level, to the lowest level of detail of an individual data element that is being mapped for example. We can see the entire size and complexity of the business process problem being solved.

 

 

Another key to our invention is the Intelligent Messaging format.  The intelligent messaging format is intended to be used as a standard wrapper for all messages flowing through an integration at run-time.  The actual message content (i.e. data) is contained within the envelope as a payload.  The envelope also contains a number of other fields used to control its flow through the business process and to record the route and activities undertaken during that process.

 

The use of a standard schema allows a higher degree of abstraction within a business process as this standard schema contains (i.e. encapsulates) all business process rules and state information necessary to execute the business process integration without any knowledge of the rest of the system and vice versa (i.e. fully abstracted).  The word standard is very important in our software world as there are few standards.  We invented a standard messaging format for executing application integrations in addition to a standard object model (i.e. drawing tool) that allows business analysts to fully design and describe application integrations in hours/weeks that are code generated and installed in minutes. 

 

You would think an invention like this would help, in some small way, industrialize our software world like AutoCAD did for the engineering design world in the early 80s.  However, as with most inventions, including AutoCAD, getting to market is an entirely different story which I will describe in tomorrows post.