I recently introduced after a proof of concept and technology Service Integration Bus to enable Event Driven Architecture style integration across the commercial enterprise.
The first team implemented it exactly as the POC specified. The second team that was responsible to be the durable subscriber raised concerns about Domain Agnostic Connection factories.
The claim was that using domain Specific Connection Factories makes life easier. The basic difference between the two is that one uses for example TopicConnectionFactory to create a TopicConnection, whereas the domain independent connection factory lets you look up a ConnectionFactory to create either a TopicConnection or a QueueConnection. This lets you get flexibility in the app and is basically a new feature in JMS specs.
Anyway the second team was up in arms about using domain agnostic connection factories. “Why is architecture recommending this? It’s making life difficult for us!”. Of course the first thing you learn in software architecture school is :make life hard for the development community. The tone and attitude changed at the end of this debate – architecture was a friend and developers happily followed the direction. How ? Surprised me. This blog entry is probably a note to myself.
How do you convince developers to do the right thing, ‘change’ and adopt a new way of doing things? Sift through words and select the right bytes. Software architects must recognize ‘code’ in spoken language. Understanding the subtle hints and uncovering the real issues. This is the key. Sounds like management skills? Yep, a little bit.
This is not science and they don’t teach you this in college. Negotiation and arguments must be approached uniquely each time based on context. When this ‘senior’ software dev was lamenting about how hard his life is going to get because architecture decided – he was starting getting an audience that did not understand the topic. He kept saying that we should not use Domain Agnostic Connection factories, I needed to break it down quickly and stop the nonsense. Usually when there is resistance to change, it is mostly because this new change has not really sunk in mentally. Addressing concerns objectively is the first step. Use technical facts, lay it down straight. This needs to be the corner stop of every architect and a must-have skill. If you don’t know why you’re recommending something, just don’t. If you do - SEI’s ATEC skills comes in pretty handy here.
In this particular case, the facts were that the recommendation had clear advantages. However, this did not seem to satisfy the senior developer. After some social digging it turns out that the fact that the architectural decision to use Domain Agnostic Connection Factories was made without the sr developer in question being involved was a contributing factor to the resistance. This little tit-bit of information was gathered from his peer. I opined that this was the key to his constant lamenting. With this hypothesis I formulated the next steps. Now, one has to be careful because this is the type of situation when people start looking backward and not forward. Even in hindsight, it was not possible to predict this engineer’s interest in the topic. It was explained that these decisions were made along with a host of other decisions through a Proof Of Concept and technology evaluation. This was reviewed and approved by other senior stakeholders. It was documented on the wiki and the link was sent via email. I worked with the technical person senior to him in his team – and explained the matter in technical terms. He heard from him and me, saw that others were on the same page too. A few more emails with links to document and an encouraging note – things started to look better. The attention he received probably made him realize that it wasn’t a purposeful exclusion on that decision but the natural process of technology selection by a whole host of senior technologists. The technical reason for using domain agnostic connection factories is sound and makes sense for advanced JMS systems that don’t want to have 2 connection factories depending on what messaging resource they are connecting to.
He replied back saying that he would follow this direction. It turns out that the direction was finally adopted. So what is the moral of the story ? Sometimes it matters how you make others feel about technology regardless of what the technology does for them.
