Gregor's Ramblings

No Escape From Integration

January 5, 2004

Gregor HohpeHi, I am Gregor Hohpe, co-author of the book Enterprise Integration Patterns. I like to work on and write about asynchronous messaging systems, service-oriented architectures, and all sorts of enterprise computing and architecture topics. I am also an Enterprise Strategist at AWS.
ALL RAMBLINGS  Architecture (12)  Cloud (10)  Conversations (8)  Design (26)  Events (27)  Gregor (4)  Integration (19)  Messaging (12)  Modeling (5)  Patterns (8)  Visualization (3)  WebServices (5)  Writing (12) 

My blog posts related to IT strategy, enterprise architecture, digital transformation, and cloud have moved to a new home:

I had never thought about having guest appearances on my ramblings, but this e-mail response from my friend Hyon made me laugh hard enough that I think it would be a waste not to share it with the community:

Okay, so I"ve read the first chapter of the book... and sorrowfully and sympathetically (and somewhat gleefully by the evil twin side of me that needs others to share in my pain and misery) appreciated all the integration challenges that the poor Mom-n-Pop's Widgets & Gadgets R Us were faced with.

So what's the moral of the story? Simplify your life? Go find a deserted island somwhere, build a shack for shelter and grow vegetables and go fishing for food? That is... until you realize you need fresh water and you can only get it from Waters R Us in the mainland... so you build a pipe to transfer the water from the Waters R Us in the mainland to your island, a basic point-to-point integration... but then realize that you have different channels that can request water (kitchen faucets, ice maker, bathroom shower, bathroom sink, bathroom toilet, etc, etc) and each channel only wants to have to pay for the water it consumes so your point-to-point pipe branches out into parallel processing branches to each water requester source, turning it into a publish (the Waters R Us) and subscribe (the different water requesting channels) model with a control bus connecting to a management console so we can monitor how many times water is requested (and received) for measuring quality customer satisfaction purposes and in what amounts are actually consumed by each water requesting channel. Then the water requesting channels decide it requires different water format, the kitchen faucet water requesting channel needs clear water format while the bathroom toilet decides it needs blue water with bleach format and the shower head wants pale creamy peachy water format to match the complexion of its end user so you place a water translator at each water requesting channels to apply the correct water transformation. And with so many people fleeing to their deserted islands and requiring water, the Waters R Us is having problems keeping enough inventory of water to fulfill all their water requests so you must now query their inventory system to ensure there is water in its inventory before allowing the water request order to continue... and the bathroom sink has become delinquent in its payments and been ignoring the harsh 'Pay NOW or you will be CUT OFF' letters (which is handled through a different integration pipe that we won't get into here)... so now you must check inventory to make sure there is enough water in Waters R Us inventory system to fulfill the water request and make sure the water requesting channel has good credit standing so you build a publish-subscribe channel to send out parallel async request to the credit system and to the inventory system to make sure all's OK with the world, build an aggregator to aggregate the responses and a content based router to determine whether to send the water request to the Waters R Us for fullfillment or to send the water request to the 'water request fallout' system for future manual intervention. Then with all this overabundance of activity and increase in demand and single source of supply and increase in water request fallout, you decide to build a process manager to help with management of all your water requests, so the water request messages can be stored/persisted and track the progress of your water requests and etc, etc. And then finally... realizing that you have no idea what the hell you are doing anymore and have perhaps applied the wrong tools to perform the required task and life has just gotten a bit too complicated and can't afford the high consulting fees charged by Water Consulting... so you leave the deserted island and buy a ticket to the Mars Settlement Colony to simplify your life...


Hyon Kyong Na


Follow:       Subscribe  SUBSCRIBE TO FEED


Gregor is an Enterprise Strategist with Amazon Web Services (AWS). He is a frequent speaker on asynchronous messaging, IT strategy, and cloud. He (co-)authored several books on architecture and architects.