What exactly does "using an ESB" mean? Robert L. Bogue has written "Creating a common lexicon for software development in your organization
," published on TechRepublic. In it, he discusses the need for common terms and understanding in a software development group, and how to create it.
For example, the assertion that an organization should use an ESB might mean one thing, while another person in that organization might crucially misunderstand what the statement was meant to say. This can critically damage implementation. If "using an ESB" means using a bridging application framework (a la JBI
), and a developer (or an architect) interprets the phrase as "using SOAP to communicate with a central server," then there's a potentially huge problem in how the two views will mesh.
Most people have had situations where we've given direction to someone and come back only to find that the direction we gave wasn't clear to the recipient. Or at the very least we've taken some direction from someone and when we demonstrated what we had done they indicated they were expecting something different. (This still happens when my wife asks me to do something.)
It's annoying but in software development it's costly. Estimates vary but the general consensus is that over 40 percent of a project's budget may be consumed by rework. If you consider that most of this rework isn't because of poor understanding of how the technology works, but in because of poor communication, you can see a great potential for improvement in the performance of your team by communicating better and reducing rework.
The foundation for creating less rework is in developing a common language that you can use to communicate as clearly as possible. It will never be perfect, but having the same understanding of a word will radically improve your chances of fully understanding what someone else is communicating.
He suggests the use of repetition to help clarify meaning.
The basic format is the speaker saying something like "I believe we need a SOA-based approach to this problem." The recipient (or one of the recipients in a group setting) says something like "I understand that you believe Web services are the right way to go with this project." The response doesn't use the same words that the speaker used. It uses a slightly different construction and in this case with a slightly different meaning. The result should be the speaker responding with "Yes, but I believe we need to address queuing and the transactional nature of what we're doing. I also believe that we have to focus on maintaining loose coupling." This interchange has illuminated that the speaker believes that queuing (asynchronous operation), transactional processing, and loose coupling are important components of the solution. Without this reflection of meaning back to the speaker this information would have never been shared.
What do you think? What terms have you seen used that have vague meaning or could use further clarification?