The Invisible Architect

Defining the Software Architect role responsibilities in modern organizations.

Jun 12, 2025

Intro

In a recent talk at J On The Beach 2025, I introduced the concept of the Invisible Architect — the newcomer who joins an organization with a purpose: becoming invisible. They try not to do some of the work they are expected to do, instead pushing it to others, which makes them redundant in the best-case scenario. Tricksters? Not really, as long as what they do is intentional. These rare individuals focus on empowering fellow engineers, facilitating effective communication, and offering coaching.

Main Challenges in Software Architecture

The entire talk served as an introduction to my approach to Software Architecture, which focuses more on the socio-technical view than on the pure technology itself. This is because, over the last 15 years of my experience as a Software Architect, I realized what other seasoned techies have discovered before me: that most problems in software organizations, and especially those related to translating business objectives into a system design, are primarily caused by social aspects. Technical challenges are often identified as the primary issue, but they aren’t:

The monolith is not your problem. That approach has always been the best for startups that want to validate their business cases quickly. Your real problem is that you can’t sell a massive refactoring to the people who prioritize the work.
Microservices are not your problem. They’re a nice way to separate domains or complex systems, reducing cognitive load and allowing teams to work in parallel. Your real problem is that your working methods are slowing down the development process due to artificially created dependencies.
Salespeople are not your problem. They’re just trying to make money for the organization (and themselves). Your real problem is that their objectives and incentives might not be aligned with the actual technical state of the organization, either because it’s not clear enough to all stakeholders, or because the priorities don’t reflect the best decisions at the time (usually also caused by the current technical state and risks not being conveyed).
…

I’m not neglecting the technical side of the story — you need to have a clear strategy to split the monolith or combine microservices, and you need to know the system deeply to understand its risks and describe them to stakeholders. However, I feel that there has been too much focus on technical aspects by software architects and too little on sociological elements. Why? Well, in the first place, that might be due to the poor definition of the Software Architect role.

Software Architect’s Responsibilities are Blurry

While at the conference venue, I reconnected with my friend Julio. When I was describing my approach and explained in more detail what I’ve been doing during the last years to him, he told me:

“What you’re telling me is not the job of a Software Architect. Actually, I’m doing those tasks in my current position.”

Julio is a Senior Director of Engineering (SDoE), essentially a super engineering manager for those who, like me, got lost with all the ladder steps. Part of what he does is to ensure, directly or indirectly through other Engineering Managers (EMs), that software engineers feel empowered to perform their job in the most self-sufficient manner possible — being proactive, and making decisions that align with business needs while balancing them with technology priorities.

He’s right. In his organization, he and other EMs cover that part of the delivery spectrum. But that changes across organizations—a lot. Let me introduce the visual I use to analyze potential gaps in the delivery of software organizations: the Delivery Function Map.

Delivery Function Maps: The Tool to Find Gaps

The visual depicts the software delivery spectrum on the horizontal axis, from getting an Abstract Idea about what should be offered, to having that functionality in the system, delivered in production. The vertical axis represents how close that discipline is to the system, that is, how much that role works on the actual system’s content.

Inside, we outline the various functions involved in traditional IT organizations: sales and/or strategy, product design, product management, business analysis, software architecture, engineering management, and software development. To keep it simple, I’m assuming here that you follow DevOps, and software development includes the operational/infra parts as well. You can split it when needed.

Without even looking into the colored ovals, this baseline’s initial setup might be triggering you already:

It considers that you have all these functions within your organization. However, you may not recognize the roles that are mapped to them. Maybe you don’t have business analysts or software architects. However, the functions still exist:
- Not having a software architect doesn’t mean that you’re not doing software architecture as part of the delivery (e.g., impactful technical decisions, component design, even when done directly in code).
- Not having a business analyst doesn’t mean that you’re not thinking about how the abstract business requirements can be translated to inputs for technical people. Missing the role is not a problem; missing ownership of a function is.
It positions some functions closer to the system than others, but you may have a very different opinion. For example, you may have product managers or engineering managers who are very knowledgeable about the system, becoming hybrid managers/analysts/designers and architects/developers. Is there a clear ownership? Was the hybrid role intended? Does the situation scale with the organization? Those are also questions that this visual helps you answer by triggering valuable discussions.

Now, let’s pay attention to the ovals. Those are the areas of impact for the particular function in your organization. As much as intended in books and frameworks, functions are not standardized across organizations. People follow different ways of working and interpret them in various ways.

Ask ten people to define the software architect role, and you'll get fourteen variations.

No matter how you interpret them, the goal of your organization must be that the functions in the map are connected through their ovals. That’s what will guarantee a smooth delivery process. Ovals represent the function’s connections: if function A oval touches function B, that means that the responsibility of that function is to fill the gap between A and B, which is typically implemented by having a fluent communication and translating the artifacts flowing through the delivery process to a language that the target function can understand.

Startups

It’s simpler with an example. Let’s look at the typical Delivery Function Map for a two-person startup.

Delivery Function Map - Two-person startup

One person focuses on the business and mapping it to requirements. The technical profile also fills the gap by being a business-oriented software developer (don’t judge me for this yet). For specific organizations, such as the example, we can draw circles around functions to see how they map to particular roles. In this case, these individuals are referring to themselves as Chief Product Officer (CPO) and Chief Technology Officer (CTO).

Even in these small structures, the function assignment depends on the organization. You can find other startups where the person on the right side of the spectrum also assumes business analysis and product design responsibilities.

Startups shouldn’t care about role names. These people know exactly what their functions are, or else they can adjust them quickly. They don’t need this visual map, just as they don’t need software architecture documentation or task management systems. They talk to each other.

You can imagine what the map looks like for one-person startups. I’ll dedicate a different article to one-person startups using AI agents, because choosing what functions go inside the AI agent is also an interesting topic.

Mid-size organizations

Startups grow because we humans are constantly driven to do more and build more software that can accomplish more tasks. In the name of efficiency, functions are spread across people, following copy-pasted structures from other organizations, templates and frameworks provided in books or articles, big consultancy companies’ advice, etc.

An example outcome is the following Delivery Function Map:

Delivery Function Map - Mid-size organization example

This example organization shows a few interesting patterns:

Product Managers and Software Architects have a lot of responsibility (see the ovals):
1. Product Managers are responsible for translating sales and strategy ideas into a product. The connection towards engineering managers indicates that they’re the ones responsible for feeding them with actionable roadmaps, which EMs communicate to Software Engineers.
2. Software Architects are responsible for translating the product requirements into artifacts that software engineers take as input.
Software Engineers’ oval is tiny, so they experience two bottlenecks:
1. With their managers, who tell them what to do.
2. With architects, who tell them how to do it.
Engineering Managers are not knowledgeable about the system; they focus purely on people management. This creates an interesting situation where they can’t perform their job properly, as they’re very limited in terms of assessing performance, coaching individuals, and so on.
UX Designers are placed in an isolated corner, providing product ideas and designs to product managers, who must prioritize them in conjunction with input from sales and strategy teams. This doesn’t take full advantage of the Product Design function.

Agile

I know what you’re thinking. “This is an old-fashioned approach. Agile came to solve all these problems.” Let’s look at a more Agile version of the map.

The main differences are:

Product Owners, Product Designers, and Sales/Strategy are inter-connected as equally responsible. They work closely with customers and define initial versions of product increments that the Product Owner (PO, Agile terminology) will further refine with the software engineers. Together with the PO, teams distill the ‘what’ into the ‘how’ and implement the change.
In Agile’s simplest form, there is no need for architects because teams can embody those functions internally (e.g., while refining a feature).
There could be separate engineering managers, but the idea in Agile is that teams are self-managed. The Scrum Master role is a facilitator (not a manager) who ensures the team is not missing anything or blocked by inter-dependencies with other teams.

If you examine the Delivery Function Map for a two-person startup, this one is quite similar, with two main areas representing business and technical execution. The ‘what’ and the ‘how’. What Agile aims to do is maintain lean, incremental processes that support this duality when more than two people are working in organizations. Agile, with its roles, manifesto, and principles, tries to standardize something that should happen naturally, yet it doesn’t. Agile creators observed that the delivery processes in IT organizations were very inefficient and developed a framework to address these inefficiencies.

Then, people made their own interpretations of how to map functions and roles. They copy-pasted ideas without having a clear understanding of how they would define their delivery process or who would be responsible for what. They developed fancier versions for larger organizations, such as SAFe, an aberration whose sole outcome is to make things more complicated than they should be if we would take the time to analyze our organization’s processes and come up with our own ideas (yes, they can be inspired by frameworks too).

So, does Agile produce the Delivery Function Map shown in the last diagram? In theory, it does. In practice, it doesn’t — at least in my experience. Can its principles improve worse situations? Definitely. In any case, I’m not going deeper into Agile methodologies since that could very well be the subject of another post.

The Software Architecture Gap

Okay, back to the core topic. I now have the tool to visualize the central issue in every organization I’ve helped during the last fifteen years.

I’ve worked in both Agile and non-Agile organizations, and I’ve observed the same patterns; the only difference lies in the role names. As you can see, a significant gap exists, leaving an empty mapping between high-level requirements and tangible software development tasks. To make it more explicit, I intentionally kept Business Analysis and Software Architecture functions there. I placed them where these organizations expect these functions to happen, but they’re not happening (thereby the strikethrough style):

Some organizations expect that one of the technical management roles (whatever name that person takes) does Software Architecture, but they’re busy with people management, paperwork, and bureaucracy. There are different outcomes for this:
1. They don’t do Software Architecture. This usually ends in technical debt and delivering the wrong thing.
2. They have strong opinions, and they dictate the Software Architecture, typically throwing buzzwords and copy-pasting fancy diagrams from shiny systems. That’s similar to not doing software architecture, as it rarely ends up translated into changes in code. In addition to degrading the system, this also causes frustration.
Other organizations hope that Software Engineers will “follow Agile practices”, be more “t-shaped,” or become “Product Engineers,” so they also do Business Analysis and Software Architecture. But that doesn’t come with explicit organizational support. What happens in practice is the following:
1. Product Managers are overwhelmed with many tasks, frequently neglecting business analysis and providing overly high-level task definitions.
2. Engineers often need better business requirements but lack the necessary interfaces, empowerment, or time to distill them effectively. To make it more interesting, other job roles can interpret this situation as “developers not having enough seniority” or “not being proactive”. The result is building the wrong thing (due to misunderstandings) or tasks being stalled for a long time in development (due to conducting discovery while coding).
3. Engineers often lack the empowerment or time to make informed architectural decisions, considering constraints, mid-term expectations, and other factors. The result is an improvised architecture that you can only see in code, and that becomes unmaintainable very quickly.
4. In some situations, engineers do have support to conduct Business Analysis and Software Architecture. However, when technical people with a hunger for the perfect technical system and a limited MVP mindset take over in isolation, they can build something that is far from what the organization needs, ultimately leading to over-engineering chaos.

There are several reasons why many organizations create this gap by removing or neglecting these functions and their corresponding roles. As a summary, I can say they’re all caused by dramatic experiences with waterfall-bureaucrat Business Analysts and Software Architects, and fueled by the common mistake of interpreting Agile/Lean principles as “we don’t need to think that much to deliver stuff”. It’s like people were specifying Lego block castles on paper and not delivering them, and then they shifted to placing one block on top of the other in an improvised way and expecting it to become a castle magically.

In summary, when an organization fails to perform the Business Analysis and Software Architecture functions, it leads to numerous issues, all of which impact the time-to-market, including a slow discovery process, building the wrong things, and technical debt. I hope I don’t need to convince you of this part.

Let’s talk about solutions. The situation described in 2b can be fixed by providing engineers with organizational support. Something like this:

Product and Technical Managers empower Engineers to fill the gap

In this case:

Product Managers take the time to ensure there is proper business analysis. They can even encourage engineers to do more of it, slowly decreasing the size of the orange oval towards engineers and engineers approaching closer to product managers (meaning they’re not only empowered to do Business Analysis but also responsible for that).
Technical Managers also empower engineers with time, motivation (incentives), and general support to encourage them to think more proactively about Software Architecture. Remember that these engineers do not need the role of Software Architect — they just need to perform that function so everything flows smoothly in the delivery spectrum. Remember Julio? That’s what he’s doing.

This solution is doable, but it’s challenging for a straightforward reason: Product Managers and Engineering Managers are usually quite busy. The success of this potential improvement sometimes relies on delegation or good intentions. Failures in achieving this can cause a potential problem shift, ending in any of the situations described above (from managers adopting a dictatorship architecture to over-engineering).

Filling the Gap with a Software Architect

If the main issue is that people are busy, you can always have a dedicated person to fill the gap. This can happen organically, when one of the individuals in a particular role moves to fill that gap, or it can be done explicitly by hiring someone to do that job.

In this particular example, a Software Architect fills the gap as a dangerous octopus that connects all the other functions within the organization. Two questions can be derived from this:

Why a Software Architect?
1. As I’m describing in this article, job roles are not as important as the functions they perform. I’ve filled in that gap in my career, and I define myself as a Software Architect even though I know I’m covering more than the classical definition of it (whatever that is anyway). Anyone with a mixed knowledge of business analysis, software architecture, and soft skills can comfortably work in that space.
2. Therefore, you could also name that job role Business Analyst. It’s covering both functions in any case. I could call them Business Architect or Product Architect, but that wouldn’t be convenient because then I would have to make people pre-read this article so they know what I’m talking about.
3. You can also fill the gap with two separate roles, having two people working closely together. Finding these two separate roles and ensuring they’re working smoothly together is sometimes easier than trying to find the hybrid role.
4. The interesting thing is that the gap also attracts specific individuals in other job roles, such as Agile Coaches, Scrum Masters, Team Leads, and Staff Engineers. This might end up well or badly, depending on how balanced is this person in terms of navigating the organization with a decent knowledge of the system’s domains (more affinity with e.g. Staff Engineers), while having the required soft skills to communicate effectively adapting the language to the audience (more affinity with e.g. Agile Coaches).
Why is it dangerous?
1. You need to look at the ovals; they’re all over the place. It’s similar to the map we covered when discussing the scaleup example, but now this person has even more responsibility in connecting other functions.
2. The only sustainable approach to filling that gap is for the person working there not only to focus on filling it but also to remove the gap itself, by doing what we previously covered — empowering others to do business analysis and software architecture.