There are of course many different enterprise architecture patterns, (for a good look at a few of them see e.g. http://www.enterpriseintegrationpatterns.com) however these are all built with combinations of the patterns described above in the same way that our asynchronous pattern is. Some hide the detail in the lines on the drawing, and some hide the detail behind queues or shared systems but the detail is still there at some level and you have to consider the pro’s and cons of each.
Generally, in a complex enterprise you would not want to create point to point interfaces like any of the above. You would ideally have some kind of standard service point for accepting say orders, and for receiving updates of stock levels etc. This is where we start to hit upon using ESB’s, Service Oriented Architecture Techniques, transitional architectures and the like. We will talk further on this in a later post.
These are essentially service glue, they allow simple ways to link systems that talk different languages (message structures or formats), and use different patterns (a mix of the above) together with minimal programming effort. (ETL tools do a similar role but are much more file focused). ESB’s also allow you to orchestrate services so if you have two or more systems that require updating when an order is received, that integration can be developed as an orchestration in the ESB itself instead of each order producer updating three systems. This is really useful if you decide to add another system or rationalize the 3 systems to one at a later date, as you only need to change the ESB orchestration and not re-engineer each of the order producing systems. That’s the goal, this is often done incorrectly.
This ability however, essentially gives the organization the ability to minimize impact of IT change to the business during architectural transitions. Again, more details on this will be in a later post!