Top Mistakes Made by IT Architects

In this previous article, I highlighted some of the worst mistakes a Product Owner (PO) can make.

Now, it’s time for introspection and an analysis of the most common errors I’ve observed in architectural practices throughout my career.

Disclaimer: I’ve personally made a fair share of these mistakes throughout my career ;-).

1. Being a “Seagull Architect”

This type of behavior has seriously damaged the reputation of our profession. Seagull Architects are highly concept-oriented but disconnected from real-world issues and complexity.

Their abstract ideas often fail to address the practical needs of the teams and systems they are meant to support.

How to Recognize Them

• It’s been 10 years (or more) since they last wrote production-ready code or resolved a critical production issue.
• They are overly confident in their designs and decisions, often assuming they are flawless without seeking feedback.
• They rarely confront themselves with developers, integrators, and operations teams, leading to impractical or disconnected solutions.
• They focus more on high-level concepts and theoretical frameworks than on practical implementation details.
• They like overdesigned solutions including the most design patterns they can or infrastructures overloaded with components.
• They champion the KISS principle but fail to acknowledge the real-world constraints that make simplicity challenging to achieve.
• They aren’t present at 3 a.m. to resolve urgent breakdowns in the very system they created.

My Own Experience

I once worked as Junior Architect for a “Seagull Architect” who designed a very complex yet seemingly powerful system on paper to manage business traces asynchronously for a large-scale project. Its main purpose was to integrate traces more efficiently and faster.

However, the reality was far different. It took more than one year to develop, and once implemented, it turned out to be slow, overly complex to maintain and deploy, and difficult to administer. Eventually, the system was dismantled but it was so complex that it took more time to drop it than to develop it.

How to Fix It

• Stay hands-on: Regularly practice real-world technology in real contexts—whether it’s coding, integration, or operations.
• Be truly KISS: Simplicity should be informed by practicality. Collaborate with teams to find solutions that balance simplicity with real-world functionality.
• Be agile: Collaborate closely with teams, embrace iteration, and adapt your approach to fit the evolving landscape of technology and business needs.

WARNING: While avoiding the Seagull Architect behavior, it’s also important to avoid the opposite extreme. An architect must remain confident in their decisions once the architecture is properly designed. Constantly undoing or revising decisions at the first issue raised by developers or operations can create chaos and undermine trust. A solutions architect’s role is to carefully consider many factors and find the most balanced solution that aligns with business, technical, and operational needs. Complaints from individual team members often come from a partial view of the big picture. Architects must weigh such feedback thoughtfully but not let it derail well-founded decisions that account for the broader context.

2. Acting Like a “Factory Worker Architect”

Some architects fall into the trap of behaving like factory workers, mechanically churning out designs, diagrams, or decisions without truly engaging with the bigger picture.

NOTE: This is especially common in IT consulting and services companies and in transversal architecture teams of large organizations.

This mindset can lead to systems that look good on paper but fail to meet real-world needs or adapt to change.

How to Recognize It

• The focus is solely on producing artifacts (diagrams, specifications, etc.) without understanding every impacts on development or operations.
• The architect works on several projects in parallel.
• The work feels robotic, disconnected from user needs, team challenges, or business goals.
• The architect is already assigned to a new project when development begins, leaving their Architecture Document as the sole contribution.
• If an urgent breakdown occurs in the system they designed at 3 a.m., they are nowhere to be found, having already moved on to other projects and avoiding accountability for the consequences of their design decisions.

My Own Experience

In a large insurance company, I spent several years working as an infrastructure architect. During certain periods, I found myself involved in up to 15 projects simultaneously. Each project often required complex decisions, such as selecting between multiple IT products.

It quickly became clear that this level of dispersion made it impossible to deliver high-quality architectural solutions. Critical issues were overlooked, and the overall coherence and effectiveness of the architecture suffered as a result.

How to Fix It

• Embrace collaboration: Work closely with teams to ensure designs are practical and relevant.
• Focus on a single large project or few smaller ones but not more to avoid spreading ourselves.
• Engage with end-to-end processes: Get involved in how systems are built, deployed, and maintained. Real (and most interesting) issues are mostly seen in production only.
• Focus on outcomes, not outputs: Shift the emphasis from deliverables (like documents) to the value those deliverables bring.
• Stay adaptable: Be open to feedback and willing to iterate on designs based on real-world inputs and past projects your worked on.

3. Falling into the “Golden Hammer Syndrome”

This is a classic pitfall where an architect relies excessively on a single tool, technology, or methodology, treating it as a one-size-fits-all solution. While the tool or approach may be effective in specific contexts, overusing it can lead to poorly designed systems that fail to meet diverse requirements.

This issue is often exacerbated by company fossilization—when architects stay in the same company for too long without exposure to external ideas or trends. Over time, they become overly comfortable with the tools and processes they know, reluctant to explore new possibilities. Additionally, many architects isolate themselves by avoiding meetups, conferences, or industry events, further narrowing their perspectives.

An associated occasional cognitive bias is what I would call the “Technology Stockholm Syndrome”: Sometimes, a technology that is not particularly great becomes deeply entrenched because it was so hard to set up, configure, and learn. The victims of this syndrome feel compelled to continue using it, justifying their investment of time and effort, even when better alternatives are available.

How to Recognize It

• Problems are approached as if they can all be solved with the same favorite tool, technology, or framework.
• The unique challenges and constraints of individual projects are overlooked or disregarded.
• Resistance to adopting new technologies or approaches persists, even when they are clearly more suitable.
• The continued use of outdated or overly complex technologies is justified by the effort it took to implement and learn them (Technology Stockholm Syndrome).
• Participation in external learning opportunities, such as conferences or meetups, is rare, reinforcing a stagnant and narrow mindset.

My Own Experience

I once worked for a company where the infrastructure services team absolutely refused to use containers, even something as simple as Docker. Their reasoning was rooted in tradition—they preferred to manage systems manually, following a more "traditional" approach.

In one particularly baffling conversation, I even heard the argument that automation was bad because it was "safer for a human administrator to type commands manually." This resistance to modernization not only slowed down development and deployment processes but also increased the risk of human error, ironically undermining the very safety they aimed to preserve.

How to Fix It

• Stay versatile: Continuously explore and evaluate new tools, technologies, and approaches.
• Understand the problem deeply: Focus on the specific requirements and constraints of each project before deciding on a solution.
• Challenge assumptions: Encourage team discussions to evaluate whether the chosen solution truly fits the problem.
• Adopt a toolbox mindset: Use the right tool for the right job rather than defaulting to a single, familiar option.
• Engage externally: Attend industry meetups, conferences, and workshops to broaden your perspective and stay up to date with trends and best practices.
• Rotate roles or projects: Periodically take on new challenges, even within the same company, to avoid falling into overly familiar patterns.
• Continuous Learning: Commit to lifelong learning by taking online courses, earning certifications, and keeping up with industry publications. Architects who are eager to learn stay adaptable and open to innovative solutions.
• Challenge sunk cost thinking: Regularly assess whether a technology still serves its purpose, even if significant effort was spent on implementation. Don't let past investment justify future inefficiency (Sunk Cost Fallacy bias).

4. Succumbing to “Résumé-Driven Development (RDD)”

Résumé-Driven Development (RDD) is another common mistake made by architects. This occurs when decisions are driven more by what looks impressive on the architect’s résumé than by what is actually needed for the project. Architects guilty of RDD prioritize trendy tools, frameworks, or methodologies to boost their personal career prospects, often at the expense of practicality and project success.

The problem with RDD is that it shifts the focus from solving real problems to adopting flashy technologies that may not align with the team’s skills, the company’s goals, or the project’s requirements.

How to Recognize It

• The latest buzzword technologies are heavily favored, even when they add unnecessary complexity to the project.
• POCs (Proofs of Concept) and real-world integration work are avoided or minimized, leaving developers to solve critical issues after the technology has already been chosen.
• Little to no consideration is given to IT governance, operational constraints, or long-term maintainability, leading to fragile and unsustainable systems.
• Whenever an urgent breakdown in the system occurs at 3 a.m., the architect who created it is unavailable to help, having already moved on to another company.

My Own Experience

When designing a large system as a junior architect in the late 2000s, I was seduced by the ESB (Enterprise Service Bus) trend and proposed a solution that included it. In hindsight, the client was not mature enough to effectively integrate such a technology. Even though the ESB solution was Open Source, it added significant costs by introducing unnecessary complexity into many aspects of the project while delivering very little tangible benefit.

This experience taught me the importance of aligning technological choices with the client’s actual maturity and needs rather than following trends.

How to Fix It

• Code and integrate: Spend time coding, doing real integration work, and building Proofs of Concept (POCs) to validate ideas in practical scenarios.
• Align with business needs: Ensure architectural decisions align with the company's strategic goals and address real-world problems.
• Take IT governance into account: Evaluate technologies and solutions in the context of organizational policies, compliance, and long-term sustainability.
• Focus on outcomes: Prioritize solving problems over building a résumé. Success is measured by the value delivered, not by the tools used.
• Collaborate with teams: Work closely with developers, operations teams, and stakeholders to ensure solutions are practical and achievable.

NOTE: A symmetrical issue often arises in the opposite scenario. Technologies are chosen without assessing the popularity, availability or cost of skills in the market. As a result, finding and keeping qualified personnel becomes either extremely difficult or prohibitively expensive, adding unnecessary challenges to the project.

5. Trying to be “Nostradamus”

Another critical mistake is what I call the "Nostradamus Syndrome"—an architect's tendency to create overly detailed, long-term plans and designs based on predictions of the future.

While strategic thinking is essential, attempting to foresee and address every potential issue far in advance often leads to a lack of agility and results in rigid systems that fail to adapt to changing requirements or technologies.

Instead of taking an iterative approach and addressing challenges step by step, Nostradamus architects invest significant time and effort in plans that often become obsolete before they can be fully implemented. Premature optimization often exacerbates this problem: resources are spent optimizing aspects of the system that may never become critical or relevant, diverting effort from solving current, pressing needs.

NOTE: This error is commonly observed among Seagull Architects as well.

How to Recognize It

• Overly detailed designs are created for systems that won’t be implemented for years, often becoming obsolete before completion.
• Future requirements, technologies, and constraints are assumed to be predictable and static, leading to inflexible designs.
• Iterative and incremental approaches are dismissed in favor of a "big bang" implementation, increasing risks and delays.
• Teams struggle to adapt plans to unforeseen changes in business or technical environments, causing frustration and inefficiency.
• Resources are wasted on premature optimization, focusing on details that have no immediate value and may never be needed.

My Own Experience

I once worked two years on a very large waterfall project where the technical and business requirements were an astonishing 30,000 pages long. To put this into perspective, a single printed copy of the documentation filled an entire armoire. The project was restarted three times over its lifespan, and after 15 years of planning, development, and countless architecture committees, the final delivery only covered about 20% of the original business scope.

This monumental waste of time and resources was a direct result of trying to predict and design every possible detail upfront instead of adopting an iterative and flexible approach. Premature optimization compounded the problem, as time was spent perfecting features that were never actually used.

How to Fix It

• Adopt agility: Break down large plans into smaller, iterative steps that can be tested and adjusted as you progress ans when you have into hand the most information on functional and non-functional requirements.
• Focus on near-term value: Prioritize immediate needs and design systems that can evolve over time.
• Embrace uncertainty: Accept that not all variables can be predicted and design with flexibility in mind.
• Avoid premature optimization: Concentrate on solving immediate and known problems instead of optimizing for hypothetical future scenarios.
• Iterate and learn: Regularly review and adapt your architecture based on real-world feedback and changing circumstances.
• Involve stakeholders continuously: Collaborate with teams and business stakeholders to ensure designs remain aligned with evolving requirements.

6. Being trapped by the Vendor’s Siren Song

Another common mistake architects make is being overly trusting and receptive to vendors and commercials, often in the name of "better support" or "guaranteed security." This naivety can lead to costly decisions that prioritize vendor solutions over more practical or open-source alternatives.

Some architects are particularly drawn to the perks vendors offer, such as being invited to fancy restaurants, exclusive seminars, or high-profile events. These perks can cloud judgment and make the architect more inclined to recommend the vendor’s solutions, even if they aren’t the best fit for the organization.

Once the contract is signed, the initial promises of dedicated support and expert engineering often vanish, leaving the organization stuck with subpar implementations and rising costs. This approach can also lead to vendor lock-in, where switching to alternative solutions becomes prohibitively expensive or complex.

How to Recognize It

• Vendor solutions are prioritized without thorough evaluation of open-source or in-house alternatives, leading to missed opportunities for cost-effective and flexible solutions.
• Enthusiasm for vendor-organized events, seminars, or social invitations overshadows critical decision-making.
• Excessive trust is placed in vendor promises of long-term support and top-tier engineers, often without adequate verification.
• The architecture becomes heavily reliant on proprietary technologies, resulting in a significant risk of vendor lock-in.
• High costs are justified with vague assurances of "better security" or "long-term reliability," echoing the old adage: "Nobody will blame you for buying IBM."
• Urgent breakdowns in the system occur at 3 a.m., but the architect who recommended the solution forwards the issue to the editor.

My Own Experience

A few years ago, I worked for an organization that was considering switching to a Kubernetes-based infrastructure. I suggested evaluating some basic open-source distributions that would meet their needs without incurring unnecessary costs. However, they ultimately chose a costly solution that charged based on the number of containers used.

The decision was heavily influenced by the allure of fancy nodes auto-scaling features, which turned out to be overkill in their actual use case. After struggling with the high costs and complexity for a few years, they eventually switched back to a cheaper open-source solution. The entire ordeal wasted time, effort, and money, all of which could have been avoided with a more pragmatic and cost-conscious approach.

How to Fix It

• Stay critical: Evaluate vendor claims thoroughly and validate them against real-world use cases and references.
• Promote diversity: Consider open-source and in-house solutions alongside vendor offerings to maintain flexibility.
• Avoid lock-in: Design systems that minimize dependency on any single vendor by using standards and modular approaches.
• Conduct due diligence: Ensure contracts have clear performance metrics and support guarantees, and verify the vendor’s track record.
• Be cost-conscious: Always weigh the total cost of ownership (TCO) of vendor solutions against their claimed benefits.
• Involve engineers: Consult with developers, integrators, and operations teams to assess the feasibility and practicality of vendor proposals.
• Engage in realistic POCs: Before committing, involve your teams in building and testing realistic Proofs of Concept (POCs) to validate the vendor’s solution in the actual business and technical context.
• Ignore perks: Focus solely on the technical and business merits of a solution, not the perks offered by vendors.

7. Being Misused

One of the most overlooked errors an architect can make is becoming misused—falling into roles or situations where their skills and expertise are underutilized or misdirected. This often happens when the architect is brought into a project too late, handed tasks that do not align with their strategic responsibilities, or consumed by day-to-day operational demands.

Common Scenarios

• The Firefighter: The architect is called in as a last resort to rescue a project that has been poorly designed or managed without proper architectural oversight. By this stage, the project often fails to meet critical non-functional requirements like performance or security, and the cost of fixing bugs or adding features grows exponentially due to bad design decisions and lack of rigor.
• The Deluxe Secretary: Instead of providing strategic guidance, the architect is relegated to writing reports, compiling presentations, or acting as an intermediary for managers. This reduces their impact to mere administrative tasks.
• The Boat Scooper: The architect becomes so consumed by daily tasks—coding, integration, or operational fixes—that they lose sight of the bigger picture. While this may provide short-term relief for the team, it undermines their core role as a visionary and strategist.

How to Recognize It

• Architects are brought into projects only after major issues arise, instead of being involved from the beginning to guide the design and strategy.
• The role becomes heavily administrative, with a focus on reports and documentation rather than technical strategy or architectural design.
• Daily operational tasks overwhelm the role, leaving little to no time for long-term planning or strategic thinking.

My Own Experience

I have personally experienced all three of the situations described above.

For instance, I once worked as a performance architect on a completely delusional project. The goal was to compute hundreds of thousands of tasks using a BRMS and display them on a 5-year Gantt chart in less than two seconds after each drag-and-drop operation. Needless to say, the performance requirements were far removed from reality and nearly impossible to achieve. When I joined the project, the average latency per action was approximately one hour, and the project was already too advanced to completely overhaul the flawed architecture.

In another instance, I found myself spending my days writing memos and reports for managers, not to support the project but to fuel internal political battles. My role as an architect was reduced to being a "deluxe secretary" in the middle of a management war.

In other missions, I ended up spending most of my time coding or helping with integration tasks. This was often due to a lack of budget or competent resources, leaving little time to focus on the big-picture architectural vision.

These experiences taught me the importance of defining clear boundaries and ensuring that architects can focus on their strategic responsibilities rather than being consumed by operational or administrative demands.

How to Fix It

• Be proactive: Ensure your involvement from the start of the project to guide its architecture and ensure alignment with non-functional requirements.
• Define your role: Establish clear boundaries and expectations for your responsibilities as an architect to avoid being pulled into administrative or low-level tasks. If these boundaries remain unclear or are not respected, don’t hesitate to refuse the job or mission. Sometimes, allowing stakeholders or managers to face the consequences—such as rewriting a poorly managed project from scratch—can serve as a valuable lesson for the future.
• Delegate operational tasks: Work with the team to delegate coding, integration, and other daily responsibilities, allowing you to focus on the bigger picture.
• Prioritize non-functional requirements: Advocate for and address performance, security, and scalability early in the project lifecycle.
• Regularly step back: Dedicate time to reflect on the strategic goals of the project, ensuring your efforts align with the larger vision.
• Don’t Hesitate to Resign: I have never regretted resigning when the context was toxic. You can't always go against the tide. Prioritizing your well-being and professional growth is essential, and staying in a harmful environment often does more harm than good.

8. Neglecting Functional, Business, or Legal Aspects

One critical error architects often make is focusing too heavily on technical challenges while neglecting the broader functional, business, or legal considerations of a project. A technically elegant solution is of little value if it fails to meet business objectives, ignores functional requirements, or violates legal and regulatory constraints.

How to Recognize It

• Systems are designed to prioritize technical complexity rather than addressing real business problems.
• Functional requirements, such as user workflows or critical features, are treated as secondary considerations or overlooked entirely.
• Legal and regulatory constraints are neglected, resulting in compliance issues later in the project lifecycle.
• Delivered solutions frequently fail to align with stakeholder needs or expectations, leading to dissatisfaction and rework.

My Own Experience

As I explained in my previous article about Product Owners, disalignment is often caused by poor PO practices. However, architects can also create or worsen such situations through their own decisions. For instance, I worked on an archiving system where the architect designed an overly complex solution. The architecture required clients who uploaded documents to first place them on an SFTP drive before making a REST call to complete the process. This design not only imposed unnecessary complexity but also introduced a different contract for each client instead of leveraging a generic approach. Especially for small documents, a simple HTTPS-integrated endpoint would have been much easier to use and maintain, saving significant time and effort for all parties involved.

I have also observed several times that architects collect far more data than necessary simply because they can, often under the justification of future Business Intelligence (BI) needs. This approach, while seemingly forward-thinking, frequently leads to costly reworks when compliance with GDPR or similar data protection directives demands stricter data minimization practices. Instead of enabling better insights, these decisions often create unnecessary risks and reworks.

How to Fix It

• Collaborate with stakeholders: Work closely with business owners, legal teams, and end-users to fully understand functional, business, and legal requirements.
• Embrace a holistic view: Consider all dimensions of the project—technical, business, functional, and legal—when making architectural decisions.
• Prioritize business needs: Ensure that the architecture is directly aligned with business goals and delivers measurable value.
• Account for legal compliance: Engage legal experts early in the project to ensure the design adheres to relevant laws and regulations.
• Iterate on requirements: Continuously refine requirements in collaboration with stakeholders to adapt to evolving needs and constraints.

9. Neglecting Evolutivity and Reversibility

A common yet critical error in architecture is failing to account for evolutivity (the ability to adapt to changing requirements) and reversibility (the ability to undo decisions). A good architecture should not only meet current needs but also leave room for errors, unforeseen changes, and the evolution of requirements, especially in an agile project.

When evolutivity and reversibility are neglected, systems become rigid and costly to adapt, making even minor changes difficult or impossible without significant rework. As Martin Fowler emphasizes in his Is Design Dead? article, reducing irreversibility is a key strategy to manage complexity in software systems, as it enables flexibility and adaptability in the face of evolving requirements.

How to Recognize It

• Systems are designed with a "set in stone" mindset, leaving no flexibility for future changes.
• Technologies or frameworks are chosen without considering how easily they can be replaced or updated.
• Critical design decisions are made without fallback options, leading to high risks if assumptions turn out to be wrong.
• Teams frequently encounter high costs or delays when attempting to implement new requirements or fix errors.

My Own Experience

I once worked for a software editor that developed half of a large retailing solution using PL/SQL, Oracle's stored procedure language. This choice created a significant Oracle vendor lock-in, making it nearly impossible to switch to another RDBMS without substantial rework. This situation wasn't unique—I’ve observed similar patterns in other contexts as well. Such decisions not only limit flexibility but also prevent customers from saving enormous amounts of money by opting for more cost-effective database solutions. Instead, they become trapped in a costly and inflexible ecosystem.

A better solution would have been to implement business rules and logic in an application server, decoupling them from the database layer. This approach would have significantly reduced the dependency on Oracle and made the system far easier to adapt to other technologies in the future.

How to Fix It

• Prioritize reversibility: Design systems that allow for easy rollback or replacement of components when necessary.
• Embrace modularity: Use modular and loosely coupled designs to make replacing or updating parts of the system easier.
• Plan for change: Assume that requirements will evolve and build flexibility into the architecture to accommodate future needs.
• Adopt iterative validation: Regularly validate assumptions and decisions through Proofs of Concept (POCs) or incremental implementation.
• Document alternatives: Clearly document (using ADRs) the rationale behind decisions and alternative options to revisit if circumstances change.

10. Overlooking Documentation and Governance

While it’s true that outcomes are more important than outputs, neglecting proper documentation and governance can severely hinder communication and collaboration across teams and over time. Documentation serves as the primary means of passing critical information between teams and ensuring continuity as projects evolve or as team members change. Documentation is a bridge between space and time.

The most common types of documentation include architecture documents, Architecture Decision Records (ADRs), and presentations. A good starting point is this architecture document template: https://github.com/bflorat/architecture-document-template[Architecture Document Template].

However, documentation is only effective if it is kept up to date. Outdated or inaccurate documentation can quickly erode trust, leaving teams hesitant to rely on it and increasing confusion and inefficiencies.

How to Recognize It

• Documentation is either nonexistent or incomplete, making it difficult for teams to understand architectural decisions or system designs.
• Existing documentation is outdated, leading to incorrect assumptions and a lack of confidence in its reliability.
• Governance processes, such as reviewing and approving architecture decisions, are inconsistent or poorly enforced. It's impossible to know what is validated or not.
• Teams frequently rely on verbal communication or informal notes, leading to gaps in knowledge transfer.

My Own Experience

In many legacy products I’ve had to analyze, the architecture documentation was either so poor, outdated, or completely irrelevant that it was impossible to rely on it for even basic questions.

Whenever I needed to address an evolution, implement a fix, or evaluate interoperability, the only reliable source of truth was the code itself. This not only slowed down the process but also increased the risk of misinterpretation and errors, as extracting information directly from the code can be time-consuming and error-prone without proper context.

How to Fix It

• Prioritize documentation: Treat documentation as a deliverable, ensuring it is comprehensive and reflects the current state of the system.
• Adopt lightweight governance: Establish a governance process that ensures architectural decisions are reviewed and documented without creating excessive bureaucracy.
• Use standard templates: Leverage standardized templates for architecture documents and ADRs to streamline the creation and maintenance of documentation.
• Favor Architecture As Code: Leverage lightweight markup languages and diagrams as text like illustrated in this article.
• Maintain relevance: Regularly review and update documentation to ensure it remains accurate and trustworthy. Plan at least a yearly review of each major document.
• Promote accessibility: Make documentation easily accessible to all team members through a centralized repository or documentation portal.
• Encourage collaboration: Involve the entire team in the documentation process to ensure completeness and shared understanding.

11. Ignoring Organizational Constraints

A critical error in architecture is designing systems without fully understanding or considering the constraints imposed by the organization. Constraints can take many forms, including organizational, technical, or financial, and failing to account for them can lead to impractical or costly solutions.

NOTE: This problem occurs especially when new in a company or within organizations with poor technical governance or missing enterprise architects.

This issue is often exacerbated by Conway’s Law, which states: “Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.” While Conway’s Law is often seen as a frustrating reality, it must be taken into account when designing systems (using DDD when possible).

Common Types of Constraints:

• Organizational: Poor urbanization of IT landscapes, such as rewriting a service or making products incompatible due to siloed teams or misaligned priorities.
• Technical: Lack of awareness of technical rules, such as network zone segmentation, imposed tools, or mandated technologies.
• Financial: Choosing expensive solutions that are impractical for large-scale deployment or that exceed the organization’s budget.

It is also essential to consider the organization's maturity before introducing complex and demanding solutions. For instance, Martin Fowler advises that "you must be this tall to use microservices," highlighting the prerequisites and challenges that come with such architectures.

Ignoring these constraints can result in designs that are difficult to implement, manage, or sustain, leading to project delays, escalating costs, or outright failures.

How to Recognize It

• Solutions fail to align with organizational IT policies, such as approved tools, network standards, or urbanization guidelines.
• Projects experience friction during implementation due to unaddressed organizational or technical realities.
• Financial constraints are overlooked, resulting in unsustainable costs for deployment, maintenance, or scaling.
• Teams frequently raise concerns about misalignment with organizational practices or existing infrastructure.

My Own Experience

I have often witnessed "innovative" approaches that appeared lightweight and efficient on paper but proved to be the opposite in practice. For example, low-code solutions were chosen to accelerate development, but when deployed on-premises, they turned out to be extremely costly and difficult to integrate into the existing ecosystem.

These approaches often overlooked organizational constraints, such as the need for seamless interoperability with legacy systems, adherence to IT governance, or compliance with specific operational requirements. What initially seemed like a fast-track solution ended up creating significant overhead and delays down the line.

How to Fix It

• Understand organizational realities: Collaborate with stakeholders to identify and document organizational, technical, and financial constraints early in the design process.
• Engage with cross-functional teams: Work closely with teams from various departments, such as network, SOC, operations, and finance, to ensure alignment with organizational policies and practices.
• Balance ambition with pragmatism: While innovative solutions are important, they should respect the organization’s existing constraints and context. Low tech and cheap solutions are sometimes the most appropriate.
• Review regularly: Continuously reassess constraints as the organization evolves to ensure that the architecture remains relevant and sustainable.

12. Lacking Competence in Non-Functional Requirements (NFR) Collection and Integration

A very important skill for Solution Architects is their ability to competently collect and account for Non-Functional Requirements (NFRs). These requirements, which define the system’s qualities rather than its functions, are critical for creating a solution that is not only functional but also robust, scalable, and adaptable to organizational needs.

Collecting NFRs

Collecting NFRs requires a blend of technical knowledge and strong soft skills. Architects must:

• Engage stakeholders effectively to help them articulate their needs clearly.
• Illuminate the costs and delays associated with each requirement to ensure realistic expectations.
• Align the NFRs with organizational constraints, as outlined in the previous section.

Taking NFRs into Account

Once collected, all NFRs must be considered collectively, as neglecting even one can undermine the entire solution. Key categories of NFRs include Scalability, Performance, Availability, Confidentiality, Accessibility, Evolutivity and Reversibility (discussed previously) and many others.

Failing to address a single critical NFR can result in severe degradation of the solution. For instance:

• If the target population size is underestimated, and the architect designed a monolithic, hard-to-scale solution, the system may become useless or prohibitively expensive to fix.
• Similarly, neglecting a security requirement, such as an authentication protocol incompatible with the organization’s systems, can render the solution ineffective or non-compliant.

How to Recognize It

• NFRs (like expected time to create a report) are vague, incomplete, or absent from project documentation.
• Stakeholders express dissatisfaction with the system’s performance, security, or usability after implementation.
• Significant rework is required post-deployment to address overlooked NFRs, leading to increased costs and delays.
• The system fails to meet operational goals due to issues like poor scalability or inadequate security.

My Own Experience

I experienced a project where operational statistics used by employees and long-term business metrics were combined into a single solution (disclaimer: this is a bad idea). The system attempted to compute both in real-time, but this approach significantly impacted performance.

As a result, the features needed by operational users became far too slow to be practical, hindering day-to-day activities. This issue arose because the distinct requirements for operational responsiveness and long-term analytics were not properly identified and separated during the NFR collection process. It was a clear example of how failing to account for specific performance needs can degrade the entire solution.

How to Fix It

• Engage stakeholders thoroughly: Use early and regular workshops, interviews, and surveys to gather a complete set of NFRs, ensuring stakeholders understand the associated costs and trade-offs.
• Acquire infrastructure knowledge: Develop a fair understanding of infrastructure areas such as networking, systems, and security to better assess and implement NFRs.
• Be comprehensive: Address all major NFR categories, including scalability, security, accessibility, and maintainability, among others.
• Align with constraints: Ensure NFRs are realistic and fit within the organizational, technical, and financial constraints.
• Validate assumptions: Use Proofs of Concept (POCs) or prototypes to verify that the design meets the stated NFRs.
• Review and refine: Regularly review the NFRs as the project evolves to ensure they remain relevant and achievable.
• Understand NFRs Affinity and Anti-Affinity: NFRs must be considered holistically rather than in isolation. Some requirements complement each other (e.g., high availability may necessitate clustering, which can also improve performance), while others may conflict. For instance, stringent authentication requirements like MFA can reduce usability, and ensuring confidentiality may negatively impact latency. Balancing these trade-offs is critical to achieving a well-rounded architecture.

Conclusion

Being an IT architect is both a privilege and a responsibility. Architects shape the foundation of systems that drive business success, but they must also avoid the many pitfalls that can undermine their work. From neglecting Non-Functional Requirements (NFRs) to ignoring organizational constraints or becoming too disconnected from the realities of development and operations, the mistakes outlined in this article are all too common—and all avoidable with the right mindset and practices. A good architect doesn’t just aim for technical brilliance; he balances innovation with practicality, aligns systems with business goals, and ensures their designs can evolve and adapt over time. Documentation, collaboration, and an understanding of constraints are all critical to success.

If an architect is confident in their design, they will be eager to stay involved in the project, even during the deployment and operational phases. As a Litmus test, ask yourself this: “Am I willing and able to be there at 3 a.m. to resolve urgent breakdowns in the very system I created?” If the answer is no, it may be time to reconsider whether your architecture is robust, practical, and well-suited to the realities of its environment. Only by taking full ownership of our decisions can we truly learn and improve. Ultimately, it’s through pain—whether it’s the pain of debugging a flawed design at odd hours or witnessing a project fail due to poor choices—that we grow as architects. Embrace the lessons, refine your approach, and strive to create systems that not only work but inspire confidence and resilience in those who rely on them.