System Interfaces Are Not Kitchen Renovations

Recently I had to write my part of an RFP. The topic was a system-to-system interface between two health care information systems. I went through the usual stages:

1. Nail down my assumptions and their requirements
2. Come up with a design to meet those requirements
3. Translate the design into an implementation plan
4. Put the implementation plan into a spreadsheet
5. Make my best guess as to level of effort
6. Have our project manager review my egotistical/optimistic assumptions
7. Plug the estimated numbers into the spreadsheet
8. Shrug and use the resulting dates and cost estimates

The result was all too predictable: push-back from the customer about the time and cost. In our amicable back-and-forth, which seemed to be driven on her side by a blind directive to challenge all prices of all kinds, I had an epiphany: software development in general and interfacing in particular is not a kitchen renovation, so why do customers act as if they were the same?

I have been on both sides of kitchen renovation and there are some similarities:

• the customer is always impatient
• the cost is hard to contain
• accurately imagining the outcome of decisions is an uncommon skill

But there are some crucial differences:

• the concept of kitchen is well-known and well-understood by most people
• the elements of a kitchen are similarly familiar: sinks, cabinets, etc
• examples of kitchens one likes can be found
• in general the main user is also the main contact with the contractor

Why do I get huffy when people tell me I am padding my estimates? Because writing interfaces between complex systems is like the sand shifting beneath your feet. Sure, it is just another HL7 interface between an industry standard source system and a system of ours which is the intermediary system, but which has to export its data to a completely different industry-standard target system.

Thus we are linking industry standard system A (ISSA) to industry standard system B (ISSB): a piece of cake! Except....

• ISSA has over 1,500 configurable parameters (literally).
• ISSA was deployed almost five years ago and no one from that team is around.
• ISSA's configuration was in flux those first few years.

These factors complicate my job because the source HL7 does not exactly match the spec. Further complications arise from the fact that the users have developed some local idioms, so the data elements are not being used in exactly the standard way.

On the target side, ISSB is still being configured, so I am trying to hit a moving target. Which of the local idioms serve a higher purpose (so they will stay) and which of them were to compensate for issues with ISSA? No one knows. What new idioms will evolve to compensate for issues with ISSB? No one can even guess.

So this is like remodelling a kitchen if the counters used to be suspended from the ceiling but now might be cantilevered from the walls and the water might be replaced by steam.

How long will it take to keep rewriting the interface so that the new system's evolving configuration and the customer's evolving needs are all met? I don't know; I wish I did. In the meantime, my good faith best guess will have to do.