04.04.08
Duct Tape Integration
An information delivery product was developed. But, just before the product was to roll out, the project team ran into a snag. The information which came from all across the U.S. needed to be manually approved for release for each area of the country. It appeared the team might miss their deadline.
Two heroes then emerged. They were on another team that tracked the manual approval steps. The heroes put a message queue in their application that would notify any other application subscribing to the messages. When a manual approval was made, a message was sent to the queue. All was saved. The new product application subscribed to the queue and the information was delivered when the approvals were given. The heroes were honored at an IT gathering for their quick thinking and react time when it was needed most.
The queue was such a good idea, other applications began using it. All that was required was a subscription. Of course all applications do not always run successfully. Consequently, each application using the queue also maintained a history of messages already received. This way, if the application was rerun, it would not wait on a message that had already been sent.
This duct tape seemed to be working well until a major change was needed in the approval process and the application containing the queue was scheduled for retirement. The queue was like a nail on the wall that everyone kept hanging things on until one day…
If the queue was external of the application, the application could be retired and the queue could receive messages from another source. But, since the queue was part of the application and every subscriber had replicated the message history, it was not so easy to peel back the duct tape.
The quick fix to save the information delivery product was probably unavoidable even though it was a duct tape solution. Following the implementation, there should have been an immediate follow-up to improve the process and totally decouple the two applications. The common need for history should have been built into the messaging process so as additional applications needed to subscribe, they would not replicate this logic.
