#19 Stand Out: Become A Better Software Architect

The synergy of business acumen and technical expertise is extremely important. We can understand how the business works, and on at the same time actively participate in software development.

According to my observations, there are three main groups of software architects:

• Focusing primarily on the technical side of a solution.

• Focusing primarily on the business side.

• Focusing on both the business & technical side.

The first group knows a lot about APIs, gateways, load balancers, Kubernetes, cloud services, databases, cache, Kafka, etc. They can design a system that will work and serve the business. Usually, if you wake someone like that at 3 AM at night, they can tell you what you have to configure in component X to make it work this way or that way.

That’s great. You can see that such a person has tons of experience in designing systems. At the same time, they often treat business analysis as a second-class citizen. Of course, they ask about numbers the system has to handle, such as requests, storage, availability, etc. They also ask about features and what should be done (and they know how to do it).

There is one problem - the missing WHY. Because of this, there is a high chance that it won’t be noticed that one area of the business would not have to talk to the other if the domain was analyzed properly. The lack of this knowledge results in the fact that, for example, microservices are too chatty. One of the first consequences is that this way, we build an application that generates X times higher costs than it should. Another issue - a really big one - is that at some point (after adding more and more microservices that are not properly designed), we create an unmaintainable monster. That’s bad.

The second group excels in business analysis and stakeholder communication. It consistently delivers exceptional workshop outcomes and provides a complete domain view. Its deliverables often include well-defined bounded contexts, detailed context maps, and thorough domain analysis.

However, this group faces a significant challenge: their technical skills have not kept pace with rapidly evolving technologies. While they may have extensive programming experience, their skills are often outdated. This gap typically requires 1-2 years to regain proficiency in modern development environments.

As a result, they may design suboptimal system architectures despite their strong understanding of the business domain. This can lead to inefficient use of new technologies, missed opportunities, and difficulty maintaining and scaling the system, which can be costly.

Organizations might consider pairing them with the first group to bridge this gap. This is where we come to the third group—the one you would probably like to be in (even if you are not sure today ;)).

The third group is what I call the complete software architect. These people have the best of both worlds – they understand business and technology.

On the business side, they are great at understanding how businesses work. They can run workshops to find out what people need and can talk to everyone, from stakeholders to workers. When it comes to tech, they keep learning about new tools and working methods. They can easily write code with the developers and know a bit about many different tech areas.

I ride what I call the architect elevator: they ride the elevator up and down to move between a large enterprise’s board room and the engine room where software is being built. Such a direct linkage between the levels has become more important than ever in times of rapid IT evolution and digital disruption.

Gregor Hohpe. The Software Architect Elevator (Kindle Locations 362-365). Kindle Edition.

What makes them special is how they connect everything. They are like a bridge. A glue between different parts of a project. They can turn business needs into tech plans and explain tech to business people. They help various people work together and make sure the tech work matches what the business wants.

They are a bit like a building site manager. They might not be an expert plumber or electrician, but they know how all the parts of a building should work together. This big-picture view helps them design systems that work well and can grow. They can spot problems before they happen and guide projects to success, thinking about now and the future.

These architects are rare but very valuable. Any company doing tech projects needs them (even if it doesn’t know about that yet). They can make things work well on both the business and tech sides, which leads to better results.

As artificial intelligence starts to do more of the simpler jobs, people who can solve big, complex problems will become even more important. Complete software architects are good at this. They can look at the whole picture, help different teams talk to each other, and make smart choices about how to use technology to help businesses.

Learning to be a complete software architect isn't just good for now—it's also a smart move for the future. It means you'll be able to adapt to new changes and stay relevant in your job for a long time, even as technology keeps changing.

How do you see the role of the complete software architect evolving over the next decade? What new skills or areas of expertise might become critical to success in this role?

PS I have been getting a lot of feedback lately regarding the title of my book. Often, the feedback has been that the title is unreadable - it's unclear what it's about. That’s why, after running some polls, I decided to change it. “Ode To Software Architecture: A Pragmatic Guide For Software Architects” changes to “Master Software Architecture: A Pragmatic Guide.”

The premiere is still set to 02.09.2024, but there is a high chance it will take place on 26.08.2024 - I will keep you updated! The book will be available only on Leanpub.