I usually prefer simple design to rich, complex ones. In almost all cases, simple design offers numerous benefits, from fast and low cost implementation, easy modifications or extensibility. Yet, sometimes there comes a tiny little, unforeseen requirement which ruins the simple design and makes the entire design painfully overcomplicated.

In our case, this unforeseen requirement was a small feature of our order processing system, which sends Software Maintenance Agreement (SMA) expiration notification emails to the client. Notifications are sent 30, 10 and 3 days before the license expires, to remind the client to renew the SMA in time.

When the first 30-day reminders were received, many clients purchased the license right away (thank you!). Task completed, right? Not quite. When the first 10-day reminders were sent, we received a number of complaints from our clients that their SMA has already been renewed. It was not entirely surprising to us, because we knew the system will work this way, but we were surprised by the number of complaints. Even though we added a note

“If you already renewed this expiring license or you have an order in progress, please ignore this notification”

to the reminder later, it did not really help, so we had to come up with a solution.

But why reminders are sent once the SMA was renewed? The reason lies in the fact that our system does not track which SMA was renewed. When a new SMA order arrives, license is registered in the order history and that is all. If the client has multiple SMAs that have not yet expired, our system has no idea which license exactly was renewed. After all, why would it? From business perspective, we do not need that information, so the “design simple” principle said we should not add the complexity of license tracking to our system. However, without SMA tracking, we cannot tell if a particular SMA license was renewed or not.

Ah, devil is in the details.

To fix this problem, we decided to implement SMA tracking, but due to the extra complexity added, we expect this to stir things a little. We hope it will be less confusing than the repeated notifications (and will have another advantage – see below), though.

The disadvantages:

• SMA orders will require an ID to be accepted. This ID will identify the “parent SMA”, i.e. the license to be renewed. The required IDs will be provided on our website.
• If you have two SMAs that you bought separately (in two orders), you will not be able to just buy two SMAs to renew both. Instead, you will have to buy one and another one (two orders again). This is because you will be able to enter one reference ID only.
• Placing purchase orders and reselling ORF will become painfully complicated.

The advantages:

• No more “Your SMA expires in 10 day(s)” after purchasing a renewal.
• SMAs will actually start expiring when the SMA they renew expires. Previously, due to lack of tracking, SMAs started expiring immediately. This also caused some misunderstanding, but adding a repeated notice next to order links fixed things. I believe our clients will like this change, because they will not waste their money on the overlapping days when both SMAs are valid.
  
  This change, however, causes another problem, namely that purchasing 3 SMA renewals in a (referenced) row would result in 3 years of guaranteed updates. From business perspective, we do not really want this. We actually want our clients to buy the SMA renewal when it expires. This provides us calculable income flow and flexibility (the dream of every business :). To avoid the above problem, a limitation was built in: an SMA can be renewed first only 60 days before expiration. The limit can be, and will be, adjusted, if it is “too tight”.

We are looking forward to start this system, hopefully in the next two weeks. I hope this time choosing complex will be better than simple.