Recently, I’ve thinking a lot about bridges. I participated in a team building exercise that involved a group of us building a bridge. We had 30 minutes to design a structure that would span over 4 feet, and then we were split into two separate teams in two separate rooms to construct two halves of a bridge that was to be connected and support five pounds of weight. Our materials were limited to some dowel rods, foam board, and of course the Delightfully Universal Correction Technique (DUCK Tape).
Take a look at the picture here of the Golden Gate Bridge as it was being constructed in 1936. I find these pictures fascinating, because they are visually analogous to a situation IT architects, developers, and project leads find ourselves in quite often. Note how the vertical towers are constructed before the roadbed, how the suspension cables are draped between the towers and how temporary support structures are used before the bridge can become self sustaining.
In other words, the usefulness of the bridge is significantly degraded - it cannot even support itself - until long after the initial elements are put in place. The second picture here is of the Hoover Dam By-pass Bridge (Colorado River Bridge bypasses the Hoover Dam). Not that the cables you see holding up the arch were temporary - they were all removed as the the road deck was laid down on it. Construction on this bridge began in January 2005 and was completed five years later - October of 2010.
Five years. For five years this bridge provided no value at all. It consumed thousands of man-hours, millions of dollars of investment, and no doubt traffic detours and congestion. Yet, few would argue that the two lane road that caps the top of the Hoover Dam was insufficient for the growing transport needs of the region. Nevada outgrew what had been a suitable solution.
Application developers have been using the equivalent of two lane roads for many years; we call them point-to-point connections. Need to send data to another application? Open a socket, a port, a queue; invoke a remote method, or call a Web service. It works. It’s well understood, and we have a lot of infrastructure to support point-to-point conversations.
Our Architecture Review Board recently reviewed a solution that involved adding 20+ connections between 24 existing applications. This would be on top of the connections that already existed - and make no mistake, this system will continue to grow as business requirements expand. Continuing to use point-to-point connection in an environment where the population density (number of applications) is increasing along with a desire to capitalize on reusable components (more points of connection) calls for adoption of forward thinking - like a bridge builder.
A Service Bus, is an IT construct in which applications connect to other applications indirectly. Rather than application ‘A’ calling application ‘B’ directly, ‘A’ makes a call to an intermediary (the Bus), which then routes the message to the appropriate end-point (application ‘B’). The value of this architecture is that what you loose in directness and simplicity you more than make up for in manageability. Bus architectures allow for improvements in understanding traffic flow (critical in problem determination scenarios), aggregation, security, data transformation, time to market, and while counter-intuitive - performance.
Like building a bridge, the full value of a bus architecture is not readily apparent right away. Unlike bridges, you don’t have to wait five years - buses can provide value from the very first implementation, even if only one connection is implemented. As additional connections are added or migrated to the bus, the value proposition increases.
If you are managing a complex application environment, with multiple, real-time point-to-point connections - you should be moving to a bus infrastructure. The total value won’t be realized right away, and you may even have to employ some digital DUCT Tape along the way - but the end result will be an environment with better scale, management, and flexibility.