Disclaimer: Silo’s final architecture described in this boog is a second design iteration process made after we’ve successfully launched a smaller system for our PoC. This design did not start with a clean state, but with prior experience and knowledge.
If you’ve read through the introduction, you’d know by now that we barely know anything. What we do know can be one day completely discarded, changed or entirely new. We knew of customer expectations.
What we also knew is that an interaction with the device will entail a change in the mobile application and vice versa. Did we know that?
The product team already had two user flows in mind, not solid ones:
- A container is weighed after a successful vacuum, thus the weight is updated and shown on the food list. The food list is displayed in the mobile application
- A swipe on a food item in the mobile application causes the label of a container to be removed. Once that container is placed again on the device it will show “Unlabeled” on the screen.
If I were to say, the system will need only to answer the above examples (as good as my imagination is thank you very much), because I already know what the system is going to do, a year from now I won’t be able to send notifications to our devices. This is the problem of stating I know. This is why I always state I don’t know. This is also the problem with abstract and concrete thinking. How come?
Notifications do not fall under “an interaction with a device or a mobile application”. Notifications may be generated as an offline job by a server-side application. Same is true for remote updates which may be triggered by a CI/CD pipeline, the MVP thoroughly discussed in Impermanent Continuous Chaos. Same is true for the future web application which no one has ever thought of, yet. No one in the company has yet to think of it. Not even myself.
So a better abstract is one that does not include any named entities (device/mobile) or operations (interaction) nor positions (client/server): A change in one part of the system will entail a change in another part of the system. A few questions still remain to be answered:
- What is the system?
- What are the system’s borders?
- What is a client?
What is a Client?
As we were a multidisciplinary team, the term client meant something completely different to each and every one of us, which was quite the head ache:
- For our mobile developer, the mobile application was a client, and everything else was a server.
- For our server developer a client was any other application that calls a server application, which can also be another server application.
- For me, as the system’s architect, a client is every application that does not live within our servers.
- But for me as the head of software, a client also meant a paying customer.
So we came up with the following terminology, which is needed to realize what are the system borders:
- From a server application’s perspective, a client is its direct invoker/consumer.
- A client application is an application that has an interface with a customer.
- A customer can be a paying customer who bought our device, or an internal customer that uses our system (e.g. the product manager).
- A customer can be a 3rd-party company or one or more of its customers.
- From a customer’s perspective, everything that he directly uses and all indirect components needed to satisfy his needs – is a product which must have a product roadmap.
Throughout the boog, I will try to maintain the correct usage of these terms. Funny thing is, that in the end, from a system’s perspective, there won’t be any need for some of this distinction.
What is The System?
It may sound like a simple question. Whatever the answer may be, it would have a lot of consequences, some of which would be hard or even impossible to change further down the road. Some would say that long term consideration of consequences is exactly what software architecture is for. The very definition of the job.
My first thought was naturally, everything we develop is a part of The System.
Something didn’t make sense to me. The microcontroller (MCU) in the device is not a part of the system. I wasn’t sure about the UI of the mobile application part as well.
So is the system just the server side?
That’s also not entirely correct as it does not include the system’s access points / gateways, whatever they are. So a better model of the system would be:
You still can’t see why this is still not entirely correct. You’re missing a mind blowing piece of information – there is a client application running in the server. I’ll need to remind you that Silo’s device also tells you for how long your strawberries are going to be good for. This user flow is partially executed with the help of an embedded Alexa assistant in the device, and partially executed by an Alexa Skill running in the server. By our definitions this Alexa Skill is both a server side application and a client application as it has an interface with the customer!
This is very significant, as it entails there will be at least two server side applications, an Alexa Skill and at the very least a single monolith. That alone changes The System borders.
For this stage of the boog, it is a good place to halt iterating on the system’s design. It is still not 100% correct and far away from a final design, but it is enough for now. I am still maintaining zero knowledge on what the system or clients will be or do.
The current diagram presented an entity that is still to be better defined:
- What are The System’s Gateways?
- As the Alexa Skill is a client application, will the “monolith” require a System Gateway as well?
But for now, System Gateways are not my top priority, but I do have to keep them in mind. As an architect, I do know what is the next stage of the discovery process. I do know what are the two next issues to tackle. I would know need to ask myself and contemplate further on:
- What is the internal system communication?
- What are the external system communications?
To answer all of the above, would require a deep dive into cloud compute infrastructure, which Part II: Feet in the Cloud is covering.