Introduction
We sat down with Mladen Stanojevic, a software architect at Sotex Solutions, to talk about his journey from developer to architect, trends shaping the future of software architecture, and how the C4 model has changed the way he approaches architecture design.
About Sotex Solutions
Sotex Solutions is a software development company helping teams in highly regulated industries—from energy to healthcare and everything in between—build fast, compliant digital products. With a focus on long-term partnerships and deep technical expertise, Sotex supports organizations tackling complex systems, legacy constraints, and data-sensitive environments.
Tell us about yourself and what you do at Sotex Solutions
I’m a former developer with C#/.NET as my primary language, though I’ve had excursions into other languages like Java, C, C++, and Python. I’m certified in Azure infrastructure and plan to become a solution architect on Azure.
I started working for Sotex Solutions a year ago with a client, a startup that has acquired a lot of investment and is expanding rapidly. My job is to help them on this journey from startup to something bigger. We have four or five teams working on multiple projects for the same startup. I’m an architect on new projects, doing audits of current projects, and also giving advice and consulting about management. It’s a multi-role position.
How did you transition from developer to architect? What motivated that change?
In one of my previous positions, there was an opening to become an architect. I applied, went through a couple of rounds of evaluation, and made it into the software architecture role. For me, it was just an evolution of my technical skills and knowledge. As a developer, you can go two ways: you can stay technical by becoming an architect, or you can go into more managerial roles. My preference was to stay in the technical role, and the next step was software architecture - it was a logical step for me.
What does a typical day look like for you as an architect?
I spend time reviewing code and diving into details - that’s the most important thing. Personally, I don’t want to be an ivory tower architect, so I get into the code. I have meetings, consultations, and syncs with other people. Just before this meeting, a DevOps guy came to sync up and tell me what he found. I also check on implementation of designs I’ve created.
How do you prevent yourself from becoming an “ivory tower architect”?
You need to deep dive into the code from time to time. I’m not doing coding anymore, but for a big amount of my time, but I was a developer and I still have the tools and means in my head. I do risk management - when I think there’s something I need to check, I check it to help with navigating the complex situations.
What’s Sotex Solutions’ general approach to working with clients?
I’m not sure if this is philosophy, but we try to help our clients as much as we can on their way to success, primarily from the technical side, but we also have product and domain experience gathered in and out of the company. The client’s success is our success. Generally, we strive for long-term relationships, and that means not just doing the code but helping navigate the complexities of software development - the whole SDLC.
Trends in software architecture 💡
How has system design evolved over the years? What trends have you observed?
There’s always the trend of microservices versus monolithic architectures. This debate will be going on for quite some time. There are pros and cons for each of them. Personally, I like something in between - it depends on the team, requirements, whether it’s cloud or on-premise solution. I see a shift to microservices generally. I also see AI coming into development itself and into feature requests. I’ve seen this on multiple projects where clients would like the help of AI in some sense - to help with their processes, decision-making. From my perspective, AI is a good tool, but it’s just a tool. I won’t let it make decisions, but it will help developers a lot, not replace them.
What about architectural patterns. Have you seen new ones emerging?
I see some convergence in design patterns - architectural patterns are emerging and being defined. Something that was previously unknown now has approaches we can follow. We’ve gained experience as an industry and managed to put them into writing, into rules. There are always exceptions, but it gives us less uncertainty as a profession on how to approach and deal with issues.
Architecture is becoming more visible. Architects are finding their role in agile, scrum, and kanban. Previously this was not well defined, but they’re finding their role by giving value and helping teams navigate the unknown. Architecture is now in a better place than it was 10 years ago. We had big upfront design, then we had no design, and now we’re finding the sweet spot between design and agile.
Distributed transactions, for example. We finally have something to hold onto. This approach is good but has these drawbacks, this approach is good for this use case but not for that use case. Recently I joined a masterclass on software architecture from Neal Ford and others. They have vast experience and they said they managed to identify patterns and gather their experiences. They identified patterns for distributed transactions, which is still a big challenge when going to microservices.
What are common challenges you’ve seen teams face when designing architecture?
There are no mistakes, just challenges. The biggest challenge I’ve noticed is going from monolithic to microservices. You need to take into account a lot of things before making that decision - domain modelling, going synchronous to asynchronous communication, etc.
Another big challenge I’ve noticed is teams going from synchronous communication to asynchronous communication. There’s a big drop in velocity, and this is what I experienced when moving from sync applications to asynchronous applications with messaging brokers. It makes developers less productive initially. They need more time to adapt.
It’s a mind shift and the complexity of it. Even if the architecture is good, one of the drawbacks is that it’s more complex. It gives big value to business by making the application more versatile and loosely coupled, but it brings complexity to developers. They need to change their mindset from sync to async, and that’s the biggest challenge. Also debugging becomes more challenging. Previously you had everything in one place, and then you don’t have it.
You mentioned working on AI projects. What’s your experience with AI adoption?
Everybody wants to get AI into their workflows, especially to help operators and clients. The ultimate goal is to lower human input and make people more effective. From the development perspective, it helps developers be more productive. From an operational perspective, it helps make better decisions based on AI. I’m not a fan of AI making decisions, but it helps enable people to make better decisions by getting better insights. AI is here and will help us.
Using the C4 model 🔧
How has the C4 model influenced your approach to architecture design?
In the era of agile, the C4 model helped me communicate with stakeholders about architecture. It’s not too abstract - just enough abstraction so you can communicate with stakeholders at a higher level, explain what they want and need, and how you plan to solve their problems and challenges. It made me a better architect without the complexity of enterprise architecture tools, which are great but challenging and time-consuming.
UML is a great tool that we learned in high school, but it wasn’t that utilized in the agile era because of complexity. C4 made its journey into the agile world where you can have just enough architecture to communicate with stakeholders and developers. It’s not the ultimate tool, but it has its sweet spot.
Can you share specific examples of how the C4 model and IcePanel helped you?
I started using it five or six years ago when we had tight deadlines to finish a project. I started with the C4 model - it was good, but I was doing it in Draw.io, which is a good tool but took me a lot of time organizing and working with it. I was using a plugin which was good, but it took so much time to set up something.
At that moment, I tried to find something C4 model specific because it’s a closed set with enough complexity - the sweet spot. I used IcePanel to document architecture in hours, not days, and make it presentable. When I started at Sotex Solutions, I used Draw.io again, but changes were hard with Draw. So I tried the C4 model with IcePanel again, and it helped me a lot in documenting what I was designing and validating what I was planning.
What are some challenges or gaps you’ve found with IcePanel?
More technologies definitely - I can create my own, but I’d like more built-in. Deployment diagrams should be enhanced. To be honest, it looks like we just added groups to make deployment diagrams, but deployment diagrams are something I currently need in my work.
One more thing - visual visualization of synchronous versus asynchronous communication. When you create a basic diagram without technologies, there’s no difference between synchronous and asynchronous communication. For me, it would be good if you could have more emphasis on sync versus async. How do you model topics? I need to put the persistence, the database, to say this is a topic working in different spaces. There are some challenges.
Is the C4 model incorporated into your team’s process at Sotex Solutions?
Currently, it’s not in the process, but as an architect, when I have some kind of request or requirement, I like to present it visually, and clients love it. If there’s something more complex, I get called in to help document and visualize it. Should it be part of the process? I’m not sure. That’s the sweet spot between waterfall and agile - I’m not sure the industry knows where the sweet spot between big upfront design and no design at all is. We’re still finding our way.
Any advice for teams thinking about adopting the C4 model?
Just start using it. There is a challenge when you’re a developer moving into higher level abstraction - how to approach it, what to do, how to do it. I don’t have specific advice, but just start using it.
Why should business stakeholders and product people care about software architecture?
It gives predictability. It gives insight into the technical implementation. I’ve seen projects without any architecture, and after some time, nobody knew what was happening. With documented architecture, you have insights into the code from different perspectives for future projects and feature implementations.
Generally, architects are people who are former developers with experience who can help you make better technical decisions in the long term, paving the path for the team not to diverge too much on implementations.
Any final advice for companies designing their systems?
Start small. Start, advance, adapt, and advance. Everything changes - requirements change, everything changes. So start small until you see what you’re up against, and iterate. Maybe even fail fast - if it works, great. If it doesn’t work, change direction.
Mladen, thanks so much for your time today and stay chill! 🧊
We’re looking for interesting topics and opinions to discuss about software architecture. Have something you want to share? Let’s chat! Reach out to us — mail@icepanel.io.