“Software architecture isn’t forged in pristine diagrams; it’s hammered out in the messy, political and often chaotic reality of large organizations”

— Unknown (but it should be known)

This blog isn’t about glorifying failure or complaining about bureaucracy—it’s about shining a light on the real issues we face as architects in large organizations. By understanding and embracing the ‘dark side,’ we can make more informed decisions, better manage expectations, and deliver systems that actually stand the test of time. If you’re ready to see beyond the pristine diagrams, buckle up—there’s plenty to discuss, and it’s going to get messy.

When I first became a software architect, I thought best practices and well-chosen frameworks were enough. Over time, I learned that no matter how neat your architectural diagrams are, your organization’s culture, politics, and ‘real-world’ constraints can tear them apart.
Most blogs talk about how to design robust systems, but they rarely mention the organizational and political landmines that derail even the best architecture. It’s easy to craft a perfect diagram; it’s much harder to deal with outdated systems, budget cuts, resistance to change, and stubborn stakeholders (to mention just a few of the topics that I’ve personally been confronted with).

Pick up any book on microservices, and you’ll see the same example of a simple e-commerce system. But does it mention the 15-year-old mainframe that actually powers customer data? Rarely. Even more rarely it will mention that the organization maintaining the 15-year-old mainframe is a single 8-members team composed of (very) senior (both in experience and age) guys who are basically driven by one of the most famous laws in live: “the law of the least effort“. Who has ever teached you on how to deal with ‘resistance to change’? Sure there are good books with good theories about it. Did you tried them? I did. Did it work? Definetly not as expected in my case.

Books say, ‘Align your architecture with business goals.’ But what if different business units have conflicting goals? Sure, Enterprise Architecture to the rescue…right?

Some of the core topics I want to cover over time in this blog are:

1. Organizational Politics
   • How a design can fail because one or more stakeholders are suffering the Dunning-Kruger effect (psychological phenomenon in which individuals with lower ability or knowledge in a given area overestimate their own competence or expertise).
   • Big organizations are composed of smaller organizational units. Most of the times (and against the hope/wish of the organization) these units do not collaborate but rather compete with each other.
   • In many organizations, Software is not the ‘driver’. There are still big organizations where software is a ‘needed evil’, but not the center of the organization’s strategy. A clear example are companies that design and manufacture any kind of hardware or embedded device. Sure software is needed but since the hardware features (and sometime other aspects like consumables) are more important for customers and, therefore, the business: ‘can we not make all the software cheaper’ So that we invest more in the other areas?
   • Fighting Conway’s Law. Ah, wait this one is easy: “apply Inverse Conway maneuver”. What? You don’t know how to do it? Welcome to reality.
2. The Missing Piece in Mainstream Literature
   • Most software architecture books and blogs do a good job teaching the fundamentals: microservices, event-driven architectures, domain-driven design, you name it. But they don’t teach you how to handle the human aspects of architecture. What do you do when:
     • Your lead developer continuously bypasses architectural guidelines because “we don’t have time”?
     • The C-suite invests in the latest “revolutionary” tech without consulting anyone on the engineering team?
     • A critical business partner wants a feature that, if implemented, will unravel half of your existing architecture?
   • The reality is, no matter how solid your architectural blueprint is, it can be undone by organization-specific politics, ego battles, and knowledge gaps. This blog will discuss those very challenges.
3. The “intrusion” of Non-Software Professionals
   • Software engineering, perhaps more than any other engineering discipline, frequently gets directions from people with minimal technical background. While cross-functional collaboration is necessary, it can veer into the absurd when non-technical managers dictate major technology decisions. We need to talk about:
     • The power dynamics between business and IT.
     • Misaligned incentives that cause short-term product wins to trump long-term architectural stability (while long-term goals being more important for the business).
     • The blame game when stakeholders don’t understand how certain decisions introduce cascading technical debt.
4. Resistance to Change Is Real
   • Architecting software often requires evolution—sometimes even revolution. And yet, changing an organization’s systems, team processes, or technology stack can be met with fierce resistance, even when it’s obviously needed. I want to explore:
     • Why people resist technical innovations and new approaches.
     • How to get buy-in for architectural change from everyone, from your CEO to your most junior developer.
     • How to handle pushback when someone feels threatened by a new architecture that makes part of their skill set less relevant.
5. Leading Architecture Teams in the Trenches
   • It’s one thing to design a clean diagram and write a proof-of-concept. It’s another to lead a team of architects (and developers) to consistently deliver, maintain, and evolve that architecture. Leadership in software architecture is rarely about giving orders; it’s about influencing without authority, building trust, and sometimes getting your hands dirty in code to show your team you understand the real-life constraints. But this is easier said than done. Your leadership style can (and most probably should) be adapted to the people who compose your teams. Some teams benefit from a more autoritative leadership while others can deal better with a consentiment-based approach (no need for agreement, just the lack of a ‘veto’). Leading architecture teams requires taking into consideration topics like:
     • Navigating team dynamics: bridging the gap between junior developers looking to learn and senior architects set in their ways.
     • Coaching and mentoring: fostering an environment where your team is encouraged to experiment—and to fail fast and learn.
     • Budget constraints vs. quality: what to do when the team is told to “just make it work” instead of doing it right.
     • The (almost endless) different leadership styles: autoritative vs democratic, coaching vs mentoring, enabling vs prescribing. Are you as lost as myself about how to be a ‘good’ leader? This is because there is no single answer. I can share my personal experience here, which probably will not fit the experience of others and this is due to the fact that we are all humans surrounded by humans. The combinatorial results are endless, as the different types of leadership.
6. The Dark Side of Architectural Styles, Patterns, Tactics, and Principles
   • If you’ve read any popular software architecture book, you’re likely well-versed in the conventional wisdom of microservices, domain-driven design, layered architectures, or event-driven messaging. You know about SOLID, DRY, and other time-tested principles. But what the books don’t always highlight is how these patterns and principles can backfire in real-world organizations:
     • Overengineering for the sake of “purity”: When teams embrace a pattern (like microservices) without considering the added complexity or the organizational maturity required to support it.
     • Misapplied best practices: Good patterns become bad in the wrong context. A performance-optimizing tactic in one environment can cause bottlenecks in another.
     • Principles vs. deadlines: Sticking to DRY or SOLID might be ideal, but what happens when the business demands a quick hack that undermines those exact principles?
     • In software, every principle has a counterpart. We all know DRY (Don’t Repeat Yourself), but have you heard of WET (Write Everything Twice)? Figuring out when to apply each—and how to push back against those who rigidly cling to any one principle—is one of the most challenging parts of our work.
     • Cloud-native patterns and practices don’t automatically translate to every system. You’ll often hear statements like, “We need cross-functional teams to reduce dependencies because that’s what the tech giants do!” Before you jump in, remember Conway’s Law—and how the so-called Inverse Conway Maneuver can strategically shape your teams to match your ideal architecture. If your team setup is driven by personal agendas or superficial trends, you risk undermining your product’s true architectural goals. Learning to challenge these blanket “best practices” and adhere to sound principles—even when they clash with the latest corporate fad—is an art form in its own right.
     • Maintenance debt: Certain architectural tactics might minimize upfront complexity but create a monstrous maintenance burden down the road, especially if the organization doesn’t budget for refactoring.
     • Tooling & skill gaps: Sometimes an architecture’s success depends on specialized knowledge or expensive tooling that your team doesn’t have or your company won’t fund
   • In reality, every architectural style, principle, or tactic has trade-offs. They can solve specific problems beautifully, but they can also become the source of new problems if the organization isn’t ready—or simply lacks the discipline to enforce them. We’ll delve into these pitfalls and talk about ways to mitigate them without resorting to cynicism or complacency.
7. Honesty, Not Cynicism
   • “Dark architecture” doesn’t mean being pessimistic; it means embracing the hidden challenges and acknowledging that software architecture isn’t just about code and diagrams. It’s about people, organizational culture, and less technical (but equally important) topics nobody wants to talk about—until it’s too late.

In Future Blogs I would also like to cover:

• The (annoying) question of: who is a Software Architect and the (more annoying) list of possible answers: or how (ignorant and often times incompetent) people around software engineering play ethically questionable cards (like ‘psicological safety‘) to get a sit in a software architecture team or influence certain decisions.
• Architectural Politics: How to handle competing agendas that threaten the coherence of your design.
• Technical Debt vs. Political Debt: Spotting when short-term business demands create a growing architectural crisis.
• From Developer to System Architect. From System Architect to Solution Architect. From Solution Architect to Enterprise Architect: Am I choosing the correct career path? Is Enterprise Architecture the place where ivory-tower architects ends up? Is this the only technical career path for Software Architects?
• Real-Life Examples: Stories from the trenches—like how trying to standardize the technology stack across the company ended up in almost a civil war.
• When Delivering Good Products isn’t Enough: If you and your teams are successful in delivering good products, overtime the focus will switch from high quality products to social aspects within a professional environment. Pay attention to the signs and learn what is about to come, because history repeats itself.

Dark Architecture is a call to be realistic, transparent, and human about what software architecture actually entails in large organizations. I’m not claiming to have all the answers—far from it—but I believe that by understanding and embracing these “dark” parts of our work, we can better prepare ourselves and our teams for the reality of transforming great ideas into great systems.

I invite you to join me on this journey. Let’s explore the challenges of software architecture not just as a theoretical discipline, but as a gritty, day-to-day practice shaped by politics, personalities, and real-world constraints. Welcome to Dark Architecture—let’s learn how to move in the darkness.

written by

Dark Architect