Dealing with the interfaces

Few days ago… I received an email from my old buddy…

From istressed Team Lead
To: VJ
Subject: Dealing with Interfaces

Hi VJ,

I have successfully made my way to a project called “XYZ”. Now I need some serious help from you. I am mostly involved in a something called as interfaces. There are a lot outgoing/incoming interfaces in “XYZ”.

Please let me know what has been your experience in old projects wrt interfaces and what are the pitfalls that I should avoid.

Also give some rules of thumb so that I can manage my work as well as my personal life. Hope you understand.

Regards,
Interfaces Team Lead

I wrote following response to him from my experience, hope others would also find it helpful.

From: VJ
To: Interfaces Team Lead
Subject: Dealing with Interfaces

Dear Interface Team Lead,

To Answer your question better, I should need to know.. in what capacity would you be involved in “interfaces” ? As Project Management Lead / Tech Lead?

I am sure that you already know most of the blabbering that I am gonna do below. Still… Let me try to answer.

Following answer is kind of mixture of both (Project Management & Tech) anyways.

First n foremost thing to understand is : Interfaces are always tricky.

Because,

1. They involve external systems and external teams (this one is even more trickier!).
2. Every system would have its own communication protocol of offering / receiveing data (MQ / FTP / HTTP / Listener)
3. Every System will typically exhibit data inconsistency from the originally worked out data contract.

My ex-project has many interfaces and they all show above characteristics.
Now that we know what are dealing with when it comes to interfaces, this is what I would advice when you are about to deal with the interfaces:

Project planning

1. DO NOT ACCEPT FIXED PRICE AND DATE when it comes to interfacing systems. That is so because, if you need any change in interface, you need to work with their team and managers in order to achieve a mutually acceptable priority and date. So we can easily get screwed if we promise our clients a fixed price and date for delivery. Kindly bring to attention of your customer even a smallest delay possibility for interfacing systems.
2. Put a lot of time to do testing. Reasons would be apparent in following technical section.
3. Ensure that you have offshore connectivity to ALL the interfaces and the interfacing systems are up in offshore timezone. If they are not, prepare to change your plan to absorb the downtime or prepare to get screwed.
4. In the plan, probably put milestones for each interfacing system to be ready to receive / send data (in case they are not ready already). This would help in getting such issues tracked in front of customer well.

well well well.. enough of PM crap.. I know you know better than me on this front so go on add more from your side.

Technical aspects

1. Signed off Contractual Agreements between your project and interfacing system teams. This is a must so that any further change that is requested (by us / them ) can be clearly be tracked.
2. Signed off NFR Documents. NFR gives clear idea to both teams what load and response time expectations are at the beginning itself. This is very important if we figure, later on, that interfacing system is not able to deliver on the promise.
3. Many many times, the interfacing protocol that is been agreed upon does not turn out to be the best in terms of scaling, performance, etc. That is why doing a POC on each interface can be a good idea. At least on the ones where you know lot of data is being communicated.
4. If you are going to send data, prepare a whole lot for test-cases for sending all sorts of junk data (when i say junk, it should adhere to contract but still be junk e.g. when you want to send name, try sending spl characters, try testing for unicode support, etc)
5. If you are receiving data. Make sure that the contract is foolproof. Check if you need to support unicode, spl characters, do you need CDATA conversion (u receive ‘&’ in xml and your xml bombs), etc. Ask interfacing team to provide you a way to send all such kind of data on devel env so that you can test such scenarios while in development.
6. Ensure that if you are receiver of the data then your system is cluster aware. [meaning.. even if your program runs in multiple nodes of the cluster, it would not depend upon some in-memory values which would be different in individual cluster members.]

boom!

That’s a lot of stuff Guess this would help!

Oh, on the work-life management, my only advice is, if you track every issue at work closely, you would mostly be able to demonstrate that you were not at fault and you should not be penalized for others’ mistake. That would automatically help having less of ‘work’ and more of ‘life’ in your daily life

Take care of your family! Else work and life both would be hell. Oh .. you know better on that front again, I guess

Enjoy..
Regards,
VJ