This week, I practiced my first architectural kata (alternative link) with my mentor Jens Schauder and my co-mentee Thomas. These katas are meant to practice the process of designing an IT system from scratch, given a specific task. Jens picked one of the tasks for me which was to design a digital UN conference system for students. This system should serve as the technical infrastructure for hosting UN gatherings via video chat as well as one-to-one-video chats between the users. News events should be created by admins and shown to the users, which are students from all over the world who aren’t meant to buy new hardware to use the system. In this article, I want to describe my thoughts about the task, the process of getting to an architecture and of course my failures in this solution.
After having read that the application shall be used by hundreds of students on a common PC or laptop, my first thought has been: This has to be a web application!
Because this is a very fine-grained implementation detail of the system, I noted the thought and forced me to step back from it. I wanted to think about the customer value first. What is the most important thing for the customer? Obviously, the product has to have a good performance in the sense of being able to cope with a lot of requests and users simultaneously. This is the most important functional requirement. Also, the system has to be cheap because it will be run by a NGO. On the other hand, security shouldn’t be a great concern because a NGO is not a bank. Even if there is a security issue, no money is lost and no private data will be stolen.
The most important requirement of a world-wide, temporarily massive-used product leads me to this distributed system architecture:
As you can see, the system consists of several servers that are connected to each other. Users are connected to these servers and some of them to the exact same machine. Because of that, one-to-one conversations can be handled on this machine without connecting to another server. However, if one of the users of the conversation connects to another server, an inter-server-connection would be necessary. I hoped that this multiple-server idea would help with taking a lot of the load of a huge assembly. To make things cheap, each of these nodes would run an Apache Webserver.
In the next step, I try to figure out what each server would have to do and came up with the following modules:
As I already mentioned, each server would provide a web interface. This interface would be fed with the video chat that is used in assemblies and conversations and with a news feed. Additionally, an admin module can provide moderation and messages to the user. At the core of each server would be the data storage module for persisting videos and the synch-module for connecting to other nodes.
The web client should provide an interface for the three top-level functions of the server:
Curiously, I came up with that architecture in exactly that order. I seem to like the top-down-thinking because that is how I decompose every bigger problem.
After having thought of this architecture, I had to present it to Jens and my co-mentee. This went fairly well at first. However, Jens quickly figured out one huge flaw of my design. He asked how the connections between the servers would look like when organizing a huge assembly with users from all over the world. Not having thought about that much, I improvised by stating that there will always be one master server and multiple client servers. In case of an assembly, there will be one server which hosts the event. All other servers will connect to it. Even while explaining this thought, I figured this out as being a really bad idea because the master server would be the bottle neck and there wouldn’t be an alternative to it. In the following discussion, we figured out that a dynamically organizing web structure of the server, maybe like used in many peer-to-peer-networks, would be a better design.
The second minor flaw was that I assumed that security would not be a big issue. I ASSUMED, not asked. During the design phase, Jens sneaked around me quite a bit while I was sketching one paper after another, waiting for being asked, which I only did two times. That was a mistake. Since a couple of years now I know that having unchecked pre-assumptions is always a bad thing. However, during the exercise I didn’t think of this.
Another quite unsettling thought crossed my mind while discussing how our designs have been created. I noticed that thinking about some aspects of the system immediately triggered a decision regarding the implementation. For example, one requirement was to store assemblies and conversations as video files. It was clear to me that there shouldn’t be a relational DBMS, but rather a file-based one. Having dealt with relational databases I was able to decide if that tool would be appropriate or not. This ability to make immediate decisions would rise by having worked with a lot of different systems, tools, languages and in different environments. Hence, a good software architect should have a lot of experience in a lot of categories. Maybe experience is all it needs to be a good architect. For me, this means that I should work with other systems and concepts in the near future.
In conclusion I found this to be a very inspiring and joyful experience that I wish to repeat in the near future. It is not often that a software developer can, even in play, design a whole system from scratch. But this is exactly what a good software architect should be doing quite often.
