True story.
one day at Silo, I came back from a meeting and I was just about to place myself back on my orthopaedic and comfortable chair and saw that someone or something literally and figuratively peed on Silo’s architecture, or at least it’s schematics, the ones we’ve been working long and hard on.
After thorough investigation and a suspect lineup it turns out it was Daniel’s new dog, Dobie.
You are probably wondering, why did the dog pee on our architecture? Was it that horrible and complex!? But for real, the first thing you have to ask yourself is “What is Silo?”. Before you ask yourself what the architecture is, you need to ask yourself what the architecture is for.
Not just a vacuum sealer
Silo is the world’s smartest and easiest vacuum sealer ever.
Vacuum conditions extend food shelf life by x3-x5 longer and maintain its freshness and taste as well. Cheese in the fridge that lasts about a month, would last for 5 months if stored in vacuum conditions in the fridge. That’s a known valuable benefit. As there already are a lot of vacuum sealers in the market, it is not a new one. Silo’s parent is a mechanical technique that allows suction of air out of containers from below through a sideway air conduit. With it, Silo brings an entire new user experience. No longer you have to search for the pump that you threw somewhere in the kitchen. No longer you have to pump air to hell and back. All you have to do is take a Silo container, put it on a Silo device, wait for about 7 seconds and you are done.
Just by that Silo has something that is new, valuable and easy to use, but has nothing to do with software architecture. Back then, at 2016, we joked around saying we’ll market these “dumb plastic containers” as 100% “cyber secure”. The joke eventually was on me. Two years later I was the one in charge of making sure that it really is 100% cyber secure. Probably 99.9%. The first time I demoed the device on AWS Community Day 2018 the audience also wondered what plastic containers had to do with cloud computing. The answer was Docker Containers of course! The joke was on me again as later on parts of our messaging platform did actually run within docker containers.
For real, what does it have to do with software architecture?
The smart starts right after the container has been sealed. Once you’ve lifted a container off the device you can tell Amazon Alexa that there are strawberries inside the container and she will reply with “your strawberries will be good for 5 to 7 days”. This also allows Alexa to remind you to eat your strawberries, advise you to make a cake out of it before it goes bad, remind you to throw it out – and the most important prospect for us in Silo – when to buy you more strawberries. Which makes this device not just “the easiest vacuum sealer ever”, not only an Echo Dot, not only your kitchen virtual assistant and smart kitchen hub, but also a point of sale that we are placing at people’s kitchens.
That is one amazing prospect and promise, or as we call it – a roadmap. One that could have taken us all the way from 2020 to 2023 and beyond. But we didn’t start working on it in 2020. We started all the way back in 2017.
We’ll never know
Back in 2017 we got funded to make a smart vacuum sealer out of the easiest one. Back then nobody knew what smart meant and we had to work it out. We barely knew anything back then.
We knew that we would have a device…
and we knew that we didn’t know what it would do.
We knew that we would have a mobile app….
and we knew that we didn’t know what it would do.
We knew that we would need to store all the data…
and we knew that we didn’t know what our data would be.
We knew that we would need to analyze and monitor product usage…
and we knew that we didn’t know anything about that.
We were about to design an entire system completely in the dark. Which is quite an opportunity for me both as the company’s software architect and it’s CTO.
Then I had a Zen Moment. There’s a famous Zen saying: “If you say you got it, you didn’t get it” or “if you say you understood it, you didn’t”. Because the truth is – we will never know what the system would do.
To better explain it, let’s have a look at a very simplified product roadmap and let’s presume the year now is 2019, the year of the planned product launch.
| Year | Milestone |
| 2019 | Vacuum sealer MVP |
| 2020 | Vacuum sealer V1 |
| 2021 | Virtual Assistant / Smart Kitchen Hub |
| 2022 | Point of Sale |
| 2023 | ? |
By the end of 2019 we will successfully (unfortunately, we actually haven’t) launch our hardware product with the minimal valuable software required, which is the ability to tell Alexa what’s inside the container and have it shown on the mobile app with its current weight.
The plan for 2020 is to optimize the current user experience, optimize sales, get shelf life estimations and start sending notifications to the mobile app and to the device. To have a good device to sell in the masses.
The plan for 2021 is to make our product into a Smart Kitchen Hub and Virtual Assistant where you can ask Alexa about your food inventory.
The plan for 2022 is to make it into a point of sale.
The plan for 2023 is to go beyond that, whatever that means.
If you haven’t noticed, as the roadmap progresses the fine details are getting slimmer and slimmer.
A more generalized view on table/roadmap would be:
| Year | Milestone | Category |
| 2019 | Vacuum sealer MVP | The things we did… |
| 2020 | Vacuum sealer V1 | The things we plan to do… |
| 2021 | Virtual Assistant / Smart Kitchen Hub | The Buzzwords…. |
| 2022 | Point of Sale | |
| 2023 | ? | Nobody knows… |
An even more generalized view on table/roadmap would be:
| Year | Category |
| X | The things we did… |
| X+1 | The things we plan to do… |
| X+2 | The Buzzwords…. |
| X+3 | Nobody knows… |
So technically speaking the only thing that changes through time.. is time itself (X). I will never be able to really say “I know what the system does” because nobody knows. The day I would say “I know” will be the day that I dug my own grave. Two years after I would say “I know”, I would have to explain to my CEO and investors that the system “can’t do that because we didn’t design it to do that”. An architecture that would cause the company to miss on a huge business opportunity is a bad architecture. It will be my fault.
We do know
But saying “we don’t know anything at all” is not entirely true. There is something that we do already know which is called customer expectations and we do know they will change through time.
It shouldn’t strike you by surprise that customers expect a kitchen appliance to work. Silo is not a free mobile app. If for some reason it doesn’t work it would be uninstalled and the customer would go on with his life, which could be fine. This is a product people will spend hundreds of dollars on. A fault entails a full refund, maybe a recall. Not to forget a bad review on Amazon, where future customers would take these quite seriously before purchase. That’s a double loss. But for a company whose business plan is based on a Razor Blade Model, where a point of sale will create future revenues, every fault is not a double loss – it’s a triple loss.
So what do we know? We know that our system and software must be resilient. As an architect, that’s enough to start with. I have a rule of thumb, a compass, that will guide me through each design iteration, to ask myself does it increase or does it decrease the system’s resilience. Time to get to work.