Application developers tend to prefer working in our own little worlds. We put our heads down, write code and everything is fine. Integration developers can’t afford that luxury. We have to communicate or the project dies before it even has a chance to get going. And that’s just scary.
For integration specialists, effective communication with business subject matter experts is essential in order to know the most basic things about how to begin to do our jobs. We also have to communicate effectively with application developers who are used to coding with their heads down and not being bothered. There’s a lot of talk on the web about this concept of a hybrid employee, one who speaks both business and technical languages and bridges the gap between the two worlds. It’s the nature of integration, by definition, to bridge gaps. It’s the nature of an integration specialist to be that hybrid employee. And it’s essential to integration project success to have someone who is fluently bi-lingual in both techno-geek and business need.
When large integration projects hit snags, go over budget, or miss deadlines and SLAs, the most common cause is data quality and failing to account for data quality problems up front when estimating project time and budget. In my opinion, the number two cause of integration project delays and cost overruns is a lack of communication. Integration architects have to start with good communication to define objectives design optimal solutions and locate possible problem areas ahead of time. Integration developers, as they’re building the solution, have to be able to go back to those business experts and check in again and again to make certain that what they’re building will solve the problem and give the benefit that the business requires.
As an example, in a project I worked on, an integration developer working remotely delivered a solution that integrated with a mainframe application. He was following the instructions the business analyst had given him to the letter, and as far as he could tell it was working perfectly. He couldn’t understand why, during testing, the solution kept failing, and no one was happy. The problem turned out to be a combination of a data error and new business rules that no one had communicated to either the person generating test data or the mainframe application programmer who checked the output. All it to look was five minutes of clear communication first with the mainframe programmer to explain the new business rule, and then with the test data generator to explain how to adjust the test data so it no longer violated the business rules. Bingo, everyone was happy with the integration solution. The real problem was communication, not coding or architecture.
This situation also pointed out the need for better data validation on the front end, but even that problem would never have been spotted without clear communication across departments. A single hybrid employee to bridge the gaps can mean the difference between long weeks of frustration and missed deadlines and a problem solved in five minutes. Communication can mean the difference between a project that grows and thrives, and one that rots on the vine.