In this edition, I'm excited to feature an architect with over 17 years of hands-on experience—someone who not only builds systems that make a real impact but also challenges the traditional boundaries of the architect role. Throughout our conversation, you’ll discover a candid look at early career lessons, a pragmatic approach to design that prioritizes business value and collaboration, and honest reflections on overcoming project challenges and toxic environments.
Where to find Oskar:
For many years, I was reluctant to call myself an "Architect," even when I had such an official title. I was afraid of being perceived as some too-serious dude from the ivory tower. But then I heard the phrase from my friend: "We all are Architects!". He meant that we're all responsible and accountable for our design and implementation. Then I realised that the architect role was still needed, and I stopped being afraid; I just had to reshape my view on it. I always liked to have an impact and deliver. So if we see an architect as the person enabling others to be efficient, to make decisions in defined constraints, teaching them how to do it, but also one who makes hard decisions that others don't want to make, then that's the role I can fulfil. Ah, and being hands-on, it’s essential to feel the pain of your own decisions.
I don't have such a moment from the early phases; at that time, it was a series of different projects, evolution, etc. However, after 7 years of my "career", I did the examination, and it appeared that I delivered only 3 projects to production. I talked with my colleagues, and their summary was similar. I realised that something was wrong with our industry and that learning only technical aspects of it won't take us far. I realised that coding just for the sake of coding, if it's not being used, doesn't give me much pleasure anymore. I understood that to make a real impact I need to focus my learning in other areas: management, product design, modelling, human-to-human interactions, so all those other aspects that shapes our projects.
Know what you have to deliver, understand whys behind it, as good design is not created in a vacuum.
For me, it’s a process of answering the following questions:
WHY? So, understanding the product vision and business model. Considering where the money flows: who the client and the user are. That’s an important fact, as we should care about all users but optimise for clients, especially those who bring money. In the end, our product should bring money. I’m trying to talk as much as I can with business stakeholders
WHAT? Understanding what we actually need to build. Set a mental model of the business workflow. This is an excellent moment for collaborative tooling, brainstorming and modelling practices like Event Storming, Domain Storytelling, C4 model etc. As in this phase, knowing the reasoning behind WHY, we want to model the business process. I’m still mostly focused on how the business process, but I already try to set the mental model for technical constraints. I prefer a general-to-detail approach, but I also always drill test boreholes. By that, I’m setting tunnel vision on key functionalities, verifying the hypothesis, and ensuring that what we thought would work in practice.
HOW? Thinking about the requirements and guarantees the system needs to have. I’m trying to select architecture patterns and class of solutions that will fulfil your requirements. So, the type of databases, deployment type, and integration patterns, not the specific technologies. I’m using tools like C4 and other tools to structure my findings. Thanks to it, by dividing design into individual levels, I try to create clear diagrams in a given context, to understand what our system does and see how.
WITH? This is the moment when I select the tooling based on the outcome of the previous point. It has to fulfil requirements and non-functional requirements, such as costs, team experience, and ease of use. Then, rinse and repeat. It is also a good moment for prototyping. If needed I do both purely technical spike and implementing business models. Thanks to that I can confront both technical and business assumptions.
Of course, those steps are not done in the waterfall mode; it’s more of a desired order, typically the findings in each phase impact findings in others. That’s expected; it’s an agile process.
This won’t be a success story, but hopefully also useful for others. I had a single project where I couldn’t find a way to communicate properly with other management members and technical leaders. It was a constant battle, Conway’s Law in practice. From many angles, it was a toxic project, and not only for me. I tried multiple ways to fix the scenery. Some succeeded, to some degree, most not.
I reached the position where I had to either quit this project or quit this project. So I did. Still, I stayed too long in it, as I was engaged and wanted to take care of my team. Still, I realised I couldn’t be a good leader anymore if I couldn’t motivate myself anymore.
We all need to take care of our mental health; in the end, this is just work.Something that we do to have the live we want to have. We should treat it as a business and not stay too long in toxic environment. If we do, then it leaves scars, and injuries that we may not fully recover. Just like with broken legs, we can break our mind.
So don’t be afraid to prioritise family and mental health.
My bet is that we all have a different definition of what creativity is, and what type of creativity brings us joy. My personal take is that creativity should not be expressed in coding structure. We should aim to make it as boring as possible. I think that creativity should be expressed in problem-solving. There’s so much good stuff we could do when we try to solve business cases. So I’m trying to talk to businesses and focus on solving product and user needs.
Of course, you cannot always do that, but then check the previous point.
Solving real needs and seeing people using what I did. Unfortunately in our industry, that’s a privilege that not always we get.
I never had mentors, or people I follow, I have folks that I respect, but I was always going kinda my way. I’m probably some sort of non-conformist. If I had to select something, I’d say that learning Event Sourcing was a tipping point for me. I understand that I can get a synergy between business process, design and coding. This approach is really addictive.
Honestly, I don’t see many novel approaches in architecture. However, I think that event-driven techniques will become more popular, as we’ll need to focus more on product design and achieving synergy between business and technical solutions. EDA enables that. I think that split between business and IT will become obsolete, as now IT is business.
I’m already seeing that people are outsourcing creative, design thinking to GenAI, and I think that trend will continue. Unfortunately. For folks, that can use it well, it’ll speed up research phase and prototyping, that’s good. I think that we’ll also focus more on design techniques that are design friendly and that can generate a bootstrap code based on the logical model.
Get your hands dirty and learn not only technical solutions, but also modelling, product design, management. Being an architect is a mixture of that. All of those aspects are important. Still, stay close/in the trenches, as I don’t see how you could make a technical design if you don’t use technology actively and don’t work close with your team.
Travel more and don’t do such a crazy amount of overtime.
Showcasing different perspectives, solutions tackling different aspects of software design (so modelling, technology, people, etc).
From over 17 years, I’m creating software close to the business. I started my career when StackOverflow didn’t exist. I’m a developer, technical leader and architect.
I like building well-designed systems, tools, and frameworks that are used in production and make people’s lives easier. I believe that using Event Sourcing, CQRS, and Event-Driven Architecture is a good foundation for achieving that. Working on OSS and knowledge sharing is a huge motivation driver for me.
That’s why I am:
running workshops and training about Event Sourcing, CQRS and event-driven architectures.
building or was involved in building tooling like Emmett, Marten, EventStoreDB.
providing Event Sourcing in real-world samples and tutorials in my Github Repository
share my knowledge on the blog of how to create good, modular applications pragmatically.