I was listening to episode 280 of “Under the Radar” this past weekend, and they were discussing architectural and design decisions that are made early on that end up disproportionally driving decisions down the line. Not to mention bugs and endless frustrations. I ended up nodding a lot during Marco and David’s discussion.
Which led my brain down the path of relating that to Romanoff. What was a decision that was made long, long ago that I wish would have been made differently? And honestly, what came to mind was something I (or we) didn’t know because we didn’t have the experience to know. What was that topic? Contacts.
Let me describe what exists now, and then we can look at what I wish it would (could) have been:
Right now, orders (in Romanoff parlance: Work Orders) are linked to a Customer entity. And that Customer has relational entities for CustomerName, CustomerAddress, CustomerEmailAddress, and CustomerPhoneNumber. Hence if the customer has multiple phone numbers (for example), the system will support that. Seems great, right?
Well, the main issue is that the Work Order is only linked via the Customer entity. So, when a given customer has two orders, one at address 1 and the other at address 2, there’s a problem. If you change the “installation” address for order B, the address also changes for order A. Not great. Sure, the workaround is to create another Customer instance, but that defeats the purpose of explicitly linking both orders to the same customer.
As we’ve come to discover, there are more customers out there with multiple addresses than I thought. (Must be nice, right?) We also learned is a lot of customers aren’t just individuals. They use our services for their own businesses. So, they may manage an apartment complex with multiple units. Our structure utterly breaks in this scenario.
Here’s my spitball proposal to fix this issue (and I’m still mulling over the consequences, good and bad):
Introduce the idea of Contacts. And what I mean by that is a separate collection of entities that are wholly separate from the order structure. A single contact can have multiple phone numbers, addresses, email addresses, and even names. Sounds very much the same as we have now. Except for the key distinction that these entities exist on their own. The Work Order would simply “pick from” the contact’s various data points and hold its own references. Hence,
- WorkOrderCustomerName (1)
- WorkOrderCustomerAddress (1…N)
- WorkOrderCustomerEmailAddress (0…N)
- WorkOrderCustomerPhoneNumber (0…N)
This allows the Contacts infrastructure to hold the underlying information, while the Work Order references what it needs, and ignores the data points that don’t apply to it.
Honestly, as I’m thinking about it, it’s kind of like how (retail) Amazon used to behave with the idea of a contact “book”. (Jayme handles all the Amazon stuff these days, so I don’t exactly know if they still treat it like this or not.)
We always talk about technical debt in our profession, and this is a perfect example of it. We just didn’t know it at the time. 🤷🏻♂️
