Introduction
Jason Steele is the Head of Systems Architecture at NIQ Brandbank, an NIQ division that helps retailers and brands with omni-channel product content solutions. With over 20 years of experience in software engineering and architecture, Jason has first-hand experience with the rapid shifts in technology — yes, there was a time when HTTP APIs were not really a thing!
We had the privilege of chatting with Jason about everything from his career journey, using the C4 model in practice, and the future for software architects. We’re excited to share his learnings and insights with the community. Read our interview below! 👇
Can you tell me a bit about yourself?
Like many architects, I started as a software developer. There is a fairly natural progression for some to always want to contribute more - have more scope to their role, more influence on the decisions made - so after 3 years as a software developer, I became a lead developer. Upon joining a large insurance company, I moved into solution architecture.
What does a typical day look like for you?
We have a constant stream of new initiatives coming via our Product team from customers and the business. A typical day will start with a 30 minute call with my team where we all let each other know what we are doing and any challenges we are facing. This can result in further quick breakout calls to discuss things further. Then, I may attend a workshop with the Product team, Business Analysts (BAs) and stakeholders to discuss one of the projects. This may be to discuss what the requirements are, or how we would best implement them within the business. Hopefully I would then have some time to work on the solution design using the Arc42 documentation framework in Confluence and C4 diagrams in IcePanel.
How is your team structured at NIQ Brandbank?
I lead a team of 5 solution architects. We have 50 developers split into small teams of 3 to 5, with a lead developer in each. On the business side, we have Product Owners who manage the Jira backlog for each team, with Product Managers and Business Analysts feeding in the work required from the Commercial and Operations parts of the business.
With such a large team, how do architects and engineers collaborate?
When the architects are designing the solution, they will talk to the developers to go into the details of how existing components work and also to get consensus on the proposed changes. The architecture team uses the Arc42 template for documentation, and we’re getting better at logging decisions as ADRs. And of course we create diagrams and update the model in IcePanel. We’ve had good feedback on the C4 diagrams in IcePanel. The developers that have been with us for a while say that they wished they would have had it sooner, and the more recent joiners say that it really helps get them up to speed.
And what about with non-technical stakeholders?
It really depends on how non-technical they are. Some of our Product Managers and BAs are happy to go through the proposed solutions in IcePanel. The less technical ones will stick to the written documentation - but they are more concerned with the cost-benefit trade-offs of the solution options we propose - and timescales!
C4 model journey 🛣️
What was your experience like using the C4 model in practice?
A previous member of the architecture team had come across it and recommended that I take a look. I was immediately won over by the way it brought greater consistency and clarity, but there were some decisions to be made on how we approached modelling some elements like shared databases and event-driven microservices.
Have you had any “aha” moments or unexpected insights after using the C4 model?
The process of deciding at what level things are and what they contain is really useful. It forced us to consider some parts of our estate that are more like distributed monoliths. It made us clarify the responsibilities and boundaries between Containers (Apps in IcePanel) so that they move closer to becoming self-contained microservices.
What are some of the biggest mistakes you’ve seen or personally run into when adopting the C4 model?
I think the biggest mistake we made is actually one I would consider as a challenge in C4 in general: how best to model topics and queues that transport commands and events between Containers (Apps). The naïve approach is to consider your messaging service (Azure ServiceBus for us) as a Container and the queues and topics as Components. This has the unfortunate effect of turning your whole model into a single hub (the messaging service) with all your Containers surrounding it with connections to it. This actually hides the true relationship between the Containers - so what’s the alternative? Simon Brown actually went into this at GOTO 2024.
Because IcePanel allows us to add a technology to a connection, we decided to go with making the connections themselves represent the topic or queue. This isn’t ideal as it is not obvious from the diagram that those technologies are being used, but we hope that at some point a “Via” feature will be introduced to IcePanel to help with this.
(Note to readers — We’re planning to improve how events are modelled in IcePanel. More coming soon!)
On a similar note, what are some other challenges you’ve come across with the C4 model?
We have a fairly large estate, and the modelling we were doing was ad hoc per feature or per project, using Draw.io in Confluence. There was no consistency or reuse between the models, which is the prime reason we adopted C4. However, to get those benefits you really need to model most of your existing estate - that can be quite a lot of work! Sure, you can use C4 for ad hoc features and projects in the same way, but you will quickly find that you start to get duplications and inconsistencies in your model, and you’re not getting the benefits you hoped to get.
Modelling at scale 🏢
One of the biggest challenges in modelling is doing it at scale with a constantly evolving system. How do you keep your model and diagrams up to date?
With a tight knit team of six of us, we are able to hold each other to account to keep it up to date. When we find that something we are working on has a dependency on something else which hasn’t been fully modelled yet, we will get in touch with the architect we know was working on it to collaborate on getting it updated.
As your system evolves, how do you ideate and plan for architectural changes? Any specific tactics you can share?
It very much depends on the size and scope of the proposed change. Feature requests are often tweaks to existing diagrams, whereas a significant new project will require much deeper thought on the approach we will take. We will pull together more of the architecture team to have a wider discussion. We would probably use Miro to have a whiteboarding session together.
How do you onboard new team members to your architecture and the C4 model?
I would start by pointing them to c4model.com and the IcePanel documentation, then we would take a look at our model.
I think it is really important not to overwhelm a new starter with information overload. I like to start with the landscape diagram to give an overview of the whole estate and then drill down into a single system that I know they will be working with. Ideally, after explaining the role of the Containers (Apps) within it, we would then take a look at one or two flows to bring them to life. It is useful to finish a session by going back out to the landscape again. The new starter should then be left to explore on their own and come back with questions. It may be necessary to go through it all over again.
Many large teams have to deal with the tension between standardization and flexibility. How have you balanced the two with your team?
Good question! I think the answer to this is to collaborate and get consensus. When we started with C4 and then with IcePanel, we had several discussions about how we should model certain elements within our estate, such as databases shared by multiple apps, topics and queues, and systems with vague boundaries. These decisions were documented, and occasionally, I ask my team members to remind themselves of their contents. If it is missing something, then it gets discussed, and a new consensus is reached and added.
Future of software architecture 🔮
As someone who’s been in the industry for a while, what are some of the biggest shifts you’ve seen in software architecture?
It’s hard to imagine now, but HTTP APIs were not very prevalent when I started and now they are everywhere! They have shifted from being XML and SOAP to JSON and REST etc. These web protocol based APIs made it easier to use machines behind firewalls on different networks enabling a shift to cloud based services. Separate, independent, managed (and serverless) services in the cloud facilitated a shift from monolithic applications to microservices.
But there are definitely parallels to be drawn between today’s microservices using Kafka or ServiceBus to the old Service Orientated Architectures using an Enterprise Service Bus. Quite often the underlying principles don’t change much, just the technologies, that’s why design patterns are probably the most important thing for architects to know and understand.
What recent developments related to software architecture are you most excited about?
Well, I guess it will have to be AI! OCR, with the added benefits of LLMs, is now much more accurate and able to cope with multiple languages, bringing some huge benefits to automating our operational processes. We are also looking at embedding LLMs into our products to help our customers generate useful content. Then there are some more backend tasks that may well benefit from AI, such as helping with data mapping and transformations, and matching similar data from different sources.
There’s been a lot of chatter about how AI may soon replace software engineers. What do you think about this?
AI can be a great tool to help developers with writing code, but the idea of AI replacing developers any time soon is fanciful. AI is currently not aware of all the guardrails and conventions - you can’t currently feed it all the information about your existing estate and expect it to generate the jigsaw piece to fit the space it needs to fill. However, I think it will come, but the prompt engineering will need to be very sophisticated - it could end up being the 5th Generation Language! But it will still require (prompt) engineers to write the prompts to generate the code.
How do you think the role of a software architect is going to change?
For a while now, I have had the dream of AI agents watching what code is being committed and what gets deployed and automatically updating the models to reflect it. It would be amazing to have an accurate, totally consistent view of what is actually out there created for you. But I find that over 60% of my job is actually helping BAs and Product Owners get to the point where we all know what needs to be built. I don’t think AI is anywhere near being able to have those conversations and understand the implications of what is being asked - what the impacts will be to the IT estate, but also users and customers - so our jobs are safe for a while!
What advice would you give to someone who wants to become a software architect?
Start as a developer, take an interest in the code you are being asked to write - is it the best solution for the problem, are you using the best tools? If you see something that doesn’t smell right, talk to the senior developers or architecture team about it - ideally, with some ideas about how to put it right. Take an interest in what the rest of your team is doing, and other developer teams. Quite a few developers are happy doing what they are doing, but if you are interested in the bigger picture of how it all fits together, talk to the architects and get access to their documentation and diagrams. Ask for an architect to mentor you.
Jason, thanks so much for your time and sharing your knowledge! 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
