More things than just find an "solution"

During a daily talk through email, a friend of mine came to me with a question about an specific approach that he would like to adopt on a new application(information system type thing) that the company where he works will start soon. Basically the scenario is: They would like to build an UI in Delphi to “interact” with a Java backend running in a remote server, this interaction will happen practically for all UC’s that needs to deal with data and/or business rules, what means that it is not a single or isolated interaction. Due to they have a strong Delphi knowledge and they want to find an “opportunity” to make things in Java, they decided for this solution(The point here is not to question if they should or not start to make things in Java in this project). It is a medium size application in accordance with him.

In a superficial level, he showed two possibles solutions and asked my opinion about those. The two solutions were:

1. Implement a WS approach to integrate the Delphi’s UI and Java backend.
2. Implement a Java “client” that would run together with Delphi and would be the responsible to communicate with the Java remote services, where Delphi talks with this Java client through JNI.

Well, I confess that in a first moment, I wasn’t so “comfortable” with this kind of architecture solution, but I’m not in position to criticize them, because probably there were several motivations that drove them for this way (Delphi + Java), and the question that he brought was about the “bridge” between Delphi AND Java and not about if he should use Delphi OR Java. And of course both of them have their respective advantages for different solutions.

After sometime thinking about some possibilities for this “bridge”, I decided to write down some primordial questions related to his options, just to check if he was aware about “attached” things that can come with an architecture choice, things that can be expensive if the requirements changing comes. The questions were:

• Assuming that you already wrote and implemented an use case to validate those possibilities, did you write and implement an use case to validate how hard can be apply a change in a code developed follow both choices?
• If after some time effort you identify that you need to replace the current “bridge” solution for another one, were you planning to design a solution to protect the others parts of your software?
• Did you analyze the possible costs of defects found in requirements time, architecture time, construction time, system test time or post-release time?
• Did you implement a end to end equirement to prof that the solution is feasible?
• Probably this design is complex, challenging or both for you. The development team is unfamiliar with the application area. Then, are you assuming to use an iterative approach for this development?

I was waiting some “no” as answers, but I was surprised when I got “no” for all question above. It just showed that sometimes the team is so focussed on a fast technical solution that they put in place the first one founded, and then probably they will forget to think about others things that is coming on the future.