Loose Coupling – Unraveling that ball of Wires

I was returning from an architectural planning session with a customer who was looking to modernize a very old but very mission-critical application. They had the usual reasons to modernize – hard to leverage newer technologies, hard to find skills to maintain the legacy code, and so on. They also faced a requirement that often times only becomes obvious after some study – both the new and the old applications needed to run in tandem to avoid a “big bang” conversion. This application was so mission-critical, no one could risk that. But the current application is a tightly coupled monolith of processes and data files that has decades of extensions and hand-coded adaptors to make it the mission-critical work-horse that it is. Components would be migrated iteratively, but the tight coupling in the existing system meant the new system had to run in parallel throughout the migration.

As I began to unwind on the plane, I mulled over the complexity of their challenge. You can lay out a general architecture that is based on the lofty SOA principle of loose coupling, but when you get into it, there is a whole lot of unraveling to do before you can really reach that tidy nirvana. My mind wrapped terminal applications, unraveled data files, and created JCA adaptors as the engine noise from my wing seat lulled me to doze back in time…

I was back in my college days, playing in my band. Instead of enjoying the crowd’s appreciation of my solo in “Freebird” I was “reminiscing” about all of the work that went into playing out somewhere. We finished playing a job and the appreciative crowds left behind only the empty beer bottles. We were in the middle of that massive exercise to tear down the equipment. Ah the glamour.

We had to tear down all the equipment where we practiced and set up again to play, and now we were reversing the process to go home. A lot of time went into disconnecting and reconnecting components using the many, many wires. Microphone to PA, PA to stage speakers, PA to monitor speakers, power to PA, amplifiers and lights, tape decks to PA, PA to tape deck for recording…. There are lots of different kinds of cables to connect lots of different kinds of components. Of course a big part of the challenge was to have our equipment work with the resources provided by the place we were playing. I can still picture cords, hoping they would reach where they needed to or that the plugs would match or that the cable still worked after the abuse of moving.

The great nemesis after the jerry-rigging and changes made while we played was the tangled ball of cords at the end of the night – in fact I considered naming my band just that - Tangled Chords – it was the late seventies. Two o’clock in the morning and we can’t go home because the wires are so tangled up, not just with each other, but around the legs of tables, bar stools, microphone stands. No matter how carefully we laid them out when we set up, by the end of the night they were completely entangled. Some form of entropy I suppose.

Turbulence brought me back to my seat on the plane. “The wiring for setting up a band would make an SOA architect blush” I thought. I considered the analogy more deeply because as a band, we put a lot of thought into how to make the moving process “more agile.” The tangle is created by the things in the club you cannot control – if you plug this in here it will only reach to there. The speakers have to be on that shelf. You can’t run wires across where people walk. Or, the power outlet does not accept a ground so you can only plug in over there with an adaptor. Similarly, the entanglements in a would-be SOA architecture are most protracted around the existing concrete things – the way people interact with the system, data that is shared by existing processes, and key processes that are off limits to change.

The lesson? In both situations you can see that, without care, the new system will inherit the tight coupling of the existing system. And the approach to reducing this effect seems quite similar to both worlds:

• Simplify the existing environment (get as many entanglements and obstacles as possible out of the way up front)
• Make the existing resources as easy to use as possible before you start using or integrating them in your new system.
• Create a master plan – a schema of the best layout if you will. Understanding all the connections you need to make helps understand how to keep things separated.
• Use a centralized connection point – in the music world this is a mixer board that allows you to change logical connections without moving wires. In IT this is probably an enterprise service bus.
• Plan for change – there always will be surprises. For the band this involved having a “toolkit” of adaptors, extension cords, extra wires, and so on that helped solve a problem without heading out to the store to buy a widget we did not anticipate needing.
• Coordinate your activities with people responsible for other elements in the system.

A note on how basic the last point is. We played in some old bars where the wall sockets did not allow for a ground. When each band member set up his own equipment we would argue over who got the adaptors and wall sockets which quickly became scarce. The solution was to reshuffle the octopus with each new need to plug something in. With some coordination we realized that setting up a power strip as soon as we got there provided power for all and only required a single ground adaptor if one was needed. This sounds like a pretty obvious solution but its amazing what can happen without some coordinating influence.

Thinking about the migration problem my client was facing in the context of the concrete steps we evolved to facilitate setting up our equipment many years ago brought some clarity in my mind. Considering the steps we evolved, the challenges seemed a bit less daunting. I deplaned feeling confident I could avoid getting tangled up in blue.