Your software architecture is falling apart. How can you save it?

Did you built it or inherit it? If you built it, then you likely did not understand the problem domain, or have good requirements in the beginning. This is usually very bad for you as an Architect, but rare. In most cases, you inherit an existing Architecture, and you are asked by the stakeholders to make changes to it. First, do you understand the existing system well enough? Have you pulled out all the key “golden nuggets” of the architecture which are essential to success? If the premise is you have failed, then you need simultaneously try to put bandaids in place, while finding out why it failed and redesigning the parts which are failing to bring them to a success state. You need to listen and learn.

1. Conduct a thorough assessment of the current architecture, identifying weaknesses, bottlenecks, and areas of concern. 2. Prioritize identified issues based on their impact on the system and align them with the defined objectives. Focus on addressing critical issues first to ensure immediate improvements. 3. Enforce coding standards, design patterns, and best practices to ensure consistency and maintainability in the long run. 4. Implement continuous monitoring and analytics to track the system's health, performance, and user satisfaction. This helps in identifying and addressing issues proactively.

As I said in the first part: The hardest part of being an Architect is setting aside our pride in the knowledge and experience we have and really listening to the stakeholders. First the persons paying the bill. Then the Alpha users, then the Beta users who might not speak up. Try to keep the system understandable to the average human if at all possible while building in the “ables” that systems needs (reliable, stable, dependable, etc). Be clear about what can be accomplished when. Avoid overpromising if you (but that may be difficult if you overprice missed before and the expectations are that you will “cleanup the mess”) did before. Try to be ahead of the expectations not behind them. Measurable objectives and milestones matter

Most Architecture failures involve trying to replace everything without buy in from all the stakeholders. It’s exactly what I asked for but not what I want! Try to architect “evolutionary” rather than “revolutionary” unless it’s clear from the stakeholders that revolution is what they seek. Better to upgrade existing platforms, bolt on new features, evolve the existing system to the new state or system in steps or phases. Sometimes, this can’t be done. And expectations need to be clear on how the stakeholders will move forward. Are you migrating data to the new system? Are you running them side by side until the old one “ages out”? Are you just dumping them into the new system, no migration?

Make sure you have the right KPIs, financial, behavioral, and user satisfaction. Behavioral describes how the system runs and how exceptions in the system are handled. Not usually covered directly in a KPI, but important nonetheless. Behavioral would include successful transaction and failed transactions %, uptime, connectivity, and response time. Don’t forget security scans as well. Most everything is online these days and scan reports and penetration tests are predictors of future hacks or failures. Heed those reports and remove vulnerabilities.

Acredito que em um momento de crise arquitet?nica, é crucial refletir sobre a escolha e implementa??o da arquitetura de software desde o início do projeto. Isso envolve avaliar se a arquitetura escolhida foi apropriada para os requisitos e metas do sistema, e se os desenvolvedores aplicaram-na corretamente. Além disso, é essencial reconhecer e compreender as falhas e desafios encontrados, a fim de identificar oportunidades de melhoria e corre??o. Ao fazê-lo, os esfor?os de salvamento da arquitetura devem ser guiados por uma abordagem que priorize a estabilidade do sistema, evitando impactos negativos nos clientes e no or?amento da equipe.

Always have a retrospective on your work, so you can be in an improvement loop. Don’t keep making the same mistakes over and over again, yet most of us do. Learn from your mistakes and failures.