Loose Coupling

The title is not meant to be click bait, it’s a term central to software design that imparts resiliency and adaptability during an application’s life span. This term, however, can be expanded to include any system or solution built with interdependent subsystems. How does this apply to banking infrastructure you ask? Well, banking IT infrastructure is built on layers of subsystems, such as networking, routers, switches, cables and software. These support protocols for data transfer, communications and application services, which then support other bank services such as websites, imaging, access management and many more. In this regard, loose coupling is a philosophical approach towards managing the entire infrastructure. As interdependence within systems grow in complexity it decreases ones ability to proactively manage the infrastructure, and limits business continuity and disaster recover options. Loose coupling, as I’ll demonstrate, is just another way of saying “all things in moderation”. In this article I’ll list the challenges of managing interdependent systems and how loose coupling can help mitigate those challenges and return control to the bank’s operation’s team.

There are 3 systems; system A, system B, and system C. Data flows from A -> B -> C. Each system applies processes to the data in a unique way before sending the output to the next one. All works well until one day when the operation’s team finds that the output of system C needs to be enhanced, or worse that systems A or B need to be replaced due to exigent circumstances. In either case it’s found that a change is fraught with significant challenges, increased migration costs, and disruptions to the operations. As you’re reading this I’m sure you’ve already conjured up past experiences of this ‘tightly’ coupled interdependent scenario. The loose couple philosophy seeks to diminish these types of deployments early on so that enhancements, remediation and resiliency are factored into the system(s).

The primacy of loose coupling is the establishment of sever-able interfaces between two systems, such that their reliance on each other is tenuous (purposely so). This design approach means that decisions to swap out or upgrade technology becomes less of a dilemma and more of a formality. Additionally, a loose coupling practice contributes favorably to an institution’s risk management process by addressing vendor-lock-in, system adaptability and resiliency, and business continuity and disaster recovery plans.

There are several tenets that contribute to a loose coupling philosophy and management style.

• Standards – select solutions that comply with standards for that industry or technology. This ensures that a replacement is easy to find and deploy. Vendors will know the standard and are able to support it. However, like most things in life, standards do stagnate over time. The file transfer protocol (FTP) is still considered a standard technology, however it fails to meet cybersecurity requirements and should be avoided. There are other protocols that are better options. This is another reason for replacing end-of-life hardware after the vendor ceases to support it.
• Data Exchange – select solutions that output data and can accept data in formats commonly used today, such as the extensible markup language (XML) or Javescript Object Notation (JSON). Every industry has one or two file formats that are universally adopted by the vendors for their industry. This will facilitate the replacement of a system if the output remains the same, since systems down stream won’t need to be altered or replaced.
• Role Adherence – Attempt to constrain a solution/system to a specific role in the operation. Be leery of vendors promising all-in-one solutions; this is the opposite of loose coupling. The product or application should excel in it’s particular role; a firewall does not attempt to be a web server, and Microsoft Excel does not attempt to be an audio player. Some balance needs to be struck when applying this tenet, it’s possible to go to extremes, which imparts it’s own set of problems. In general the solution or system should stay in its own lane from an operational view point.
• Middleware – Sometimes a system/solution can act as a go-between two systems to add loose coupling to the operations, especially when the two systems don’t lend themselves to the loose coupling tenets. Middleware can help convert non-standardized data from system X to a file format that is easily digestible by other systems or applications.

Loose coupling is an art. No two people are going to agree on the proper configuration or design for the best outcome. And going too far leads to growth and complexity in systems as the team seeks to abstract and lower interdependence between them. Perhaps it’s best to focus and target those systems in the operations that lack many of the loose coupling tenets and present the biggest risk to the organization. As stated earlier, “all things in moderation”; loose coupling speaks to the heart of this idea when it comes to systems design and operations.

I hope you found this article informative, thought provoking or somewhat interesting. I strive to produce content that imparts the most value to those in the IT trenches. I’m happy to hear if you have a different take or additional information that could benefit others.

Best of luck and feel free to suggest other topics you would like to me address.

Abel Sanchez (abel@staidworks.com) – BankSafeTech Contributor and Moderator