Cracking the Code of Software Architecture: Lessons from an Expert

"Welcome to the Hüb – a place where our experts frankly share their opinions, ideas, and expertise of the industry as well as its future and important trends you need to know about."

In today’s 18th episode of the series, we talk with Branko Tripkovic, the Lead Software Engineer Consultant at Zühlke Group.

What is architecture really about?

Architecture is about delivering software solutions faster and with higher quality, and that means managing complexity. The complexity comes from several places, but the most important ones are business complexity because we are solving business problems and overall organisation decisions, which might not be aligned with project needs. The other side of complexity comes from technology itself because technologies are very complex, and most of the time, you don't need the full power of some technology, just a part of it. You need to decide which and how much of each technology to use.

The architect's role is to help a project manage these complexities. But the biggest challenge is that none of these things are stable – there is always change. Managing that change and preparing the project for the change without incurring too much cost is crucial.

Get comfortable with balancing business and technology

This is a delicate balancing act, and you can never be perfect at it. But first and foremost, it's a business. You're trying to solve business problems, and that often implies using technology. That means you have to have a broad knowledge of technologies, and where you lack knowledge or expertise, you should be able to delegate to others or find people who can help you make informed decisions.

There is a famous truism that says you know the least about a project at the beginning, and there's no way around it. As you keep working on a project and start development, you discover both technological and, especially, business perspectives. As teams develop, the businesspeople keep seeing things and make more informed decisions based on what they see. To paraphrase Steve Jobs - customers don't know what they want until we show them. While it might sound a bit too blunt, it's true for all of us. It's much easier to make decisions when we see things in front of us. Sales and marketing, for instance, often revolve around putting the product in front of you so you can make decisions. This is also the same process in project development. In that sense, architecture is a lively process, not a static state.

Two important benefits of developing with containers

Regarding tooling, I think container environments are incredibly valuable and are finally gaining more recognition. Containers solve several problems, one of which is the ability to install multiple versions of the same software in different containers and run or test them. This is especially useful in a multi-tier environment where different services might require different versions of the same software. It used to be quite challenging to manage. The same goes for databases and versions.

Another crucial aspect is that containers allow you to run very close to a production environment. In the past, there were cases where implementations worked locally but failed once deployed to a test or production environment. Containerised environments allow us to run an environment that's almost identical to the production environment, which helps mitigate such issues.

The reasons you shouldn't shy away from pair programming

There's an impression that pair programming is a waste of resources. However, I strongly believe that it's not. With practices like git flow and pull requests, they're essentially a form of the four-eye principle. But in pair programming, feedback is instant, and work benefits from two persons' perspectives. The resulting solution is often better than if you were waiting for a traditional code review. Unfortunately, we can't do it all the time, but I think it's underutilised, especially when more experienced team members are paired with less experienced members. The junior members should be the ones doing the coding, as it ensures the flow of knowledge and understanding from senior to junior members.

It’s time you start staring at the cloud

Cloud adoption is becoming increasingly widespread among our clients. Almost everyone is moving to the cloud, and some even operate their private clouds. So, it's essential, not just for professional developers but for anyone in the field. Cloud technology is likely to play a significant role in the future. It simplifies processes too. In the past, there was a disconnect between different stages of development, from business analysis to coding to testing, and so on. The cloud streamlines the entire process, enabling better integration and collaboration across the entire development lifecycle. In the past, the development process was fragmented, with many handoffs between different roles, leading to inefficiencies and misalignment. But with DevOps, development teams now take more ownership and responsibility for the delivery of solutions. This brings faster and better delivery. This is beneficial because it provides instant feedback and the satisfaction of seeing your work in use. It's a significant trend that will stay with us.

Developers must be capable of business analysis, coding, testing, and deployment, so multiple roles are often rolled into one person.

Architecture is a delicate balance of 4 things

People will give back as much as they receive, and if they don't get the opportunity to contribute, they won't provide to their full potential. When we hire people, it's for their minds, not just their coding skills. Coding skills can be improved, but their ability to solve problems is what we value the most. Architects have a crucial role in presenting their solutions at the beginning of projects because projects need a starting point. Architects need to secure buy-in from various stakeholders, from business to the teams that will implement the solutions. They have to make sure that team members understand why decisions were made and what the overall business picture looks like. It's essential for teams to internalise these decisions and feel that there's an open door for them to provide feedback and propose improvements. This feedback loop is crucial because it prevents teams from working around decisions, which could slow down the project. Architecture is ultimately about delivering solutions faster; this feedback loop is vital to achieving that goal. It's a delicate balance of leadership, inclusivity, decision-making, and adaptability to changing circumstances.