Architecting Your Professional Journey

The world has sped up dramatically in recent years. Technology is advancing faster than ever before. Naturally, each of us has doubts about whether we can keep up. We start worrying about the end of our careers and the possibility that AI will replace us.

n this article, we’ll put ourselves at the center rather than focusing on AI once again. Instead of learning how to use vibe coding to build yet another unicorn, I’ll show how we can repurpose concepts from software architecture to find ourselves and our path in this highly demanding, fast-paced world.

The terms we want to borrow are Software Architecture Drivers and the related concept of Evolutionary Architecture. But before I explain how they might be helpful to us, let’s define them briefly.

Designing software architecture is not an easy task. There is no perfect solution, and designing is a continuous activity. The environment around us evolves, and therefore our architecture must evolve too. We are bombarded with new requirements to build features quickly in order to beat our competitors. Hence, architecture is a set of decisions that we make within a given context, taking into account various constraints.

All the forces that influence software architecture are drivers. The sooner we understand and define them, the more clearly we can design the architecture.

We can define four groups of drivers:

• Business Constraints – time, budget, and team structure
• Technical Constraints – existing solutions, programming language, and software practices
• Functional Requirements – what the solution is meant to do
• Quality Attributes – how the solution should behave. These include characteristics such as availability, scalability, reliability, and others.

Knowing the architecture drivers, we can steer the solution in the right direction. For the purpose of this article, this is all we need to know about them, but I encourage you to dive deeper into the topic.

Complementing Architecture Drivers is another term: Evolutionary Architecture, coined by Neal Ford, Rebecca Parsons, and Patrick Kua in their book Building Evolutionary Architectures. For the purpose of this article, we just need to understand the basics. The key is that architecture is not something we do once and then we’re done. We build it incrementally, one part at a time.

Important term is Fitness Functions. Every system at different points in its life needs to be optimized to “fit” its environment. Evolutionary architectures explicitly define what “fit” means with as much automation as possible.

Fitness functions provide automated, continuous feedback on whether your architecture is moving in the right direction or degrading over time. They help protect the architectural characteristics that matter most.

We, as humans, evolve just as our solutions do. Therefore, we are not much different from software in this regard. We can borrow these concepts and apply them to ourselves. We grow up and learn new things. We set our own goals for what we want to do and how we want to achieve them. The environment around us constantly changes, requiring us to adapt.

We see the similarities, but before giving examples, let’s first answer why we should do this at all. Our life is like a software system—without knowing the goal and direction, we will wander aimlessly. That is why it’s important to define what we want to achieve, by when, and what we need to do to get there. We should also take constraints into account. Defining these elements is where the software architecture terms mentioned earlier can help us.

Good news: no one is going to give you functional requirements. There are no business stakeholders who will tell you what you have to do. You are in charge of your life, so you need to define for yourself what you “as a system” want to do. For example, do you want to be an amazing backend developer writing code in C#, or do you want to be a Solution Architect? Your functional requirements are up to you.

Now, what about constraints? Business constraints remain the same. You have a limited budget, so you may need to choose a cheaper course that still supports your functional goals. The same applies to time. We don’t work 24 hours a day, nor should we. We have many other activities outside of work that limit our time for self-development. That’s okay—we should put our family first. The key point is that we need to be aware of these constraints.

When it comes to Technical Constraints, they work similarly. We may not know a technology that is crucial to achieving our goal. However, this isn’t a problem—in our case, we can easily overcome it through learning. The important thing is being aware of these gaps so we can make progress.

Compared to other drivers, Quality Attributes might be less common. In Software Architecture, we can refer to predefined lists with many examples. For humans, this is more of an individual matter. You can create your own list or borrow Quality Attributes from Software Architecture. Below are some examples:

• Autonomy – I’m a Junior Software Developer who wants to become a Senior Software Developer, so I need to be able to work independently.
• Credibility – I’m a Senior Software Developer who wants to become a Tech Lead, so I need my opinion to be respected.
• Trustworthiness – I’m a Senior Software Developer who wants to become a Team Lead, so I need to be seen as a reliable person who is easy to work with.

Quality Attributes don’t describe your current state but rather define how you want to be perceived in your desired position. You need to know where you are right now and what your goal is (your functional requirements). Only after identifying your goal can you determine which Quality Attributes are necessary. Based on that, you can identify what you’re missing and what steps you need to take.

One of the main rules in Software Architecture is that everything is a trade-off. The same applies to Human Architecture. If you define too many Quality Attributes, your journey to fulfill them becomes overly complex and lengthy. You may find yourself in a state where you’re not making progress in any direction.

Another important rule to remember is that the only constant in our lives is change. Time passes and the context around us shifts. Therefore, we need to adapt our drivers to our current situation. Reviewing them regularly is where Fitness Functions can help us.

As defined earlier, Fitness Functions are automated measures for our systems that validate whether the system architecture is heading in the desired direction. We should do the same with our careers. Through our drivers, we know our destination and what we should do. However, if our plan spans many years, how do we know if we’re going in the right direction?

What we want to borrow from Fitness Functions is a way to check whether we’re heading in the right direction. Take the example of a Senior Software Developer who wants to become a Tech Lead. The person defines Credibility as their Quality Attribute. To achieve this, they attend presentation workshops and complete technology courses. To ensure these actions lead to the desired position, the Developer asks their team members and manager for feedback.

In many cases, asking your colleagues for feedback works best as a Fitness Function.

To give you more tangible example, I listed how it looks like in my case.

Functional Requirements	In the short term, I want to be a Software Architect. In the long term, I want to be either a CTO or a Founder.
Business Constraints	Limited time
Technical Constrains	On the backend worked mainly with C#
Quality Attributes	– Adaptability – adapting quickly based on project context – Storytelling-ability -clearly conveying ideas to stakeholders – Learning-ability – staying up-to-date with latest technological changes.
Fitness Functions	Asking for feedback

In a rapidly changing world where AI threatens to replace us, this article shows how to apply software architecture concepts—Architecture Drivers, Evolutionary Architecture, and Fitness Functions—to navigate our career paths effectively.

Just as software evolves continuously, our careers require the same iterative approach. We can define our path using four Architecture Drivers: Functional Requirements (our career goals), Business Constraints (limited time and budget), Technical Constraints (knowledge gaps), and Quality Attributes (how we want to be perceived, such as autonomy or credibility).

We must build our careers incrementally, adapting as our environment changes. Remember that everything is a trade-off—spreading yourself too thin halts progress. Finally, use Fitness Functions by seeking regular feedback from colleagues and managers to validate you’re heading in the right direction. By applying these principles, we can find clarity and purpose in an increasingly demanding world.