MonitorMe: Recognized as World's Best Architecture at O'Reilly Katas 2024
The O‘Reilly Software Architecture Katas, organized by Mark Richards and Neal Ford, is a competition where teams all over the world tackle challenging architectural problems. Discover the architectural approach to MonitorMe, a winning project of our team.
Watch the video to discover the winning project
Our approach to architecture
In architecture, a common mistake is focusing too much on small elements without considering the whole. This leads to overly complex solutions that miss the main goal. Stakeholders then struggle to understand the vision, getting caught up in details. They often fixate on technical points, which might not matter to users or others.
This is why we used our method, called the Rubik’s Cube for Architects. It allows us to look at the application from 6 different perspectives:
- Functional requirements perspective
- Non-functional requirements perspective
- Technical architecture perspective
- Application deployment perspective
- Fitness Functions
- Team building perspective and role division
The challenge - can we save a life in one second?
That’s the question our winning team in the O’Reilly Software Architecture Kata set out to answer.
Piotr Filipowicz, Sebastian Dąbkowski, Wojciech Kasa, and Artur Kruszewski had 10 days to prepare an architecture solution for MonitorMe. A life-saving application, designed to collect data from sensors, process it in real-time, and send critical alerts to both nurse stations & mobile devices.
They came up with the business overview [GitHub] and distilled requirements [GitHub].
These requirements can be covered by the four main data flows:
- Collecting data from sensors and visualizing them on the nurse’s station.
- Alerting the medical staff on both mobile devices and the nurse’s station when anomalies are detected based on defined and easily extendable rules.
- Browsing the patient’s vital signs (maximum 24 hours).
- Sending the snapshot to MyMedicalData.
01.
Functional requirements perspective
For business requirements, we carefully listened to the client and wrote down their requirements. Then, we identified a list of functional requirements.
The next step was to collect events, identify actors, and the actions they can trigger.
We conducted Event Storming to identify the main components of the MonitorMe system. This collaborative workshop helped us visualize system workflows, identify domain events, and determine the interactions between components.
Through this process, we identified the necessary components and their relationships, informing the design and implementation of the system. Here are the results.
02.
Non-functional requirements. Identifying architecture characteristics
The Business Requirements [GitHub] and Event Storming [GitHub] results led us to look deeper into the project, and identify crucial architectural characteristics [GitHub] that are highly important for the MonitorMe system.
Choosing the right architecture is crucial for effective design. It also defines efficient data flow within a system. By considering these characteristics, one can pick the right software and hardware. They will meet system needs. This ensures the system functions properly and is scalable, maintainable, and high-performing.
The top three architectural characteristics are what we found based on the requirements and our expertise.
01 Evolvability
To be able to adapt the system to meet changing business needs
02 Performance
To transfer data in max 1 second
03 Elasticity
To handle unexpected peak loads and spikes in data transmission
If you're passionate about architecture, don't miss these two episodes of our podcast (in Polish)
03.
Technical architecture perspective
Having identified the top three driving characteristics, we can simply choose the architecture style that best fits our business case Architecture Decision Records [GitHub].
Based on the evaluation criteria of elasticity, evolvability, and performance, an event-driven architecture is chosen. The decision is supported by a rating of 14 stars according to the selection schema for architectural styles.
Designing the architecture
By utilizing the C4 approach, specifically focusing on the Context (C1) and Container (C2) views, we can effectively visualize the overall structure and key dependencies within the MonitorMe system.
Context view (C1)
The Context view allows us to understand the high-level relationships and interactions between the system and its external components or systems. All architectural decisions are documented as the Architecture Decision Records (ADRs).
The whole description of the Context view can be found here [GitHub].
Container view (C2)
The Container view shows the system’s internal components. It also arranges them into containers, like services, databases, and user interfaces. This method helps us understand the system’s architecture. It makes communication and decisions easier during development.
The picture below shows the final Container (C2) view.
The whole description of the Context view can be found here [GitHub].
Component views (C3)
When designing the application architecture, we sometimes delve into the C3 level. At this level, we illustrate key use cases, visualizing them through sequence diagrams. This approach helps us show which parts are in each use case. It ensures clear and effective communication of the system’s functionality.
There were identified four main system use cases:
04.
Application deployment perspective
We chose Kubernetes for our on-premises infrastructure to boost availability and performance.
Its auto-scaling optimizes resources based on demand, efficiently handling workloads. Kubernetes’ failover and load balancing mechanisms ensure high availability and uninterrupted service. This approach effectively manages our growing application while maintaining reliability standards.
The final deployment diagram looks like the diagram below. If you want to see details, go to the Deployment section [GitHub].
05.
Fitness Functions. Verification perspective of the created architecture
As we develop and optimize your system, we use fitness functions to ensure it meets our performance and quality goals. These evaluations help us refine the system to ensure it performs optimally in real-world conditions, aligning with your business objectives.
These functions evaluate various aspects such as:
- Accuracy – ensuring the system delivers correct results.
- Performance – measuring speed, resource usage, and response time.
- Scalability – checking if the system can handle increased load or data size effectively.
- Reliability – assessing stability and error tolerance.
- Usability – evaluating how intuitive and user-friendly the system is.
- Security – ensuring robust data protection and defense against unauthorized access.
- Flexibility – confirming the system’s ability to adapt to changes.
- Cost – analyzing implementation, maintenance, and operational expenses
These evaluations help us refine the system to ensure it performs optimally in real-world conditions, aligning with your business objectives.
06.
Team building perspective and role division
We’ve identified two key streams in our team topologies: Team A and Team B. Together, they will integrate seamlessly to form the platform that supports our entire operation.
We want to celebrate your success!
Our team will solve the most complex architectural challenges for your business. Get in touch to schedule a meeting.
And in the meantime, watch our team’s reaction to the winning announcement 🙂
Thank you for reading.
Get notifications for upcoming Katas 2024/2025
We occasionally run our own katas open to developers looking to improve their skills & learn something new. To stay informed when the next event is happening Sign up for the waiting list, and we’ll notify you with more details soon.
