How do you handle incorporating user feedback that requires significant changes to the software architecture?

Employing a modular design with a microservices architecture in modern software development is essential. This approach decomposes complex applications into smaller, manageable, and independently deployable services. By using microservices, teams can develop, test, and deploy components independently, resulting in faster release cycles, more efficient resource utilization, and quick adaptation to change. This modularity also enhances fault isolation, as issues in one service do not affect the entire system, improving overall system reliability. A microservices architecture enables agile development practices, ensuring software can promptly adapt to evolving user needs and customer demands.

Architectures that are built using domain driven design techniques tend to adopt better to major changes. Impact assessment needs to begin with a full and clear understanding of the requested change and the catalyst driving the change. Are the changes driven by improvements that will warrant the cost of the change? It is also imperative to assess the impact these changes will have on the overall system and business processes that are integral to the system. When looking at significant changes, I will look for measurable results. I always ask these 3 questions: 1. Will this change save cost? 2. Will this change increase revenue? 3. Will this change get us to the beach earlier? (Or wherever your happy place is!)

A good architecture needs to anticipate change and promote the steps of development. If that has not been done the impact assessment should include the changes needed to refactor to allow features to be added at lower cost. The expectation of agile is to produce results quickly at the expense of shareholders. A good architecture is backed by enterprise components that are reused through out the organization. Making an application framework using pretested components allows for lower technical debt, and lower cost to introduce new features. Like building a house start with the foundation and build the basement first. The building code for software is enterprise policy that encompasses privacy, security and accessibility

This scenario is exactly why up front design is so important. If the design of the app is modularized, then making changes can be contained to only parts of the app. If the app is a spiderweb of dependencies, then some pain (translate: additional hours, cost for the company) will happen. The effort is not just with the changes to the application, but also (hopefully) unit tests and QA regression testing. It is very important to demonstrate this to management. Up front design saves money, accelerates time-to-market, and delivers a higher-quality product, which gives the company a better reputation.

Here's how to approach: 1. Understand the underlying user needs behind the feedback. Focus on what the benefit the user is looking for from a functional point of view without focusing on technical requirements/details. 2. Determine if the feedback aligns with the product’s vision and goals. 3. Determine how it impacts the current architecture, including dependencies, scalability, performance, and security considerations. Also, explore different architectural approaches. 4. Discuss with Stakeholders, including product managers, the development team, and users. 5. Analyse potential benefits vs costs. 6. Develop a detailed plan including timeline, resource allocation, and milestones. 7.Break down the changes into smaller,manageable phases.

Each group should take the necessary time to anticipate "what if" scenarios and give estimates. This includes possible roll-back efforts, should things go south. A good blue-green rollout should be anticipated. If you're lucky enough to be able to take the site offline and simply do a full backup of the database, you save possible pain. If not, you will also need to write rollback scripts. Don't forget to anticipate - Security Testing - Load Testing - Stress Testing - Updating automated test scripts - Plan for manual testing

What kind of architecture decisions are we talking about here? On what level? Tactical design (request/response vs messaging etc.) Or physical : design patterns, framework choices etc. It matters.... a lot. Or are we talking "changing circumstances" as a driver of change? I relate to these things by looking at the role of architecture in the physical building domain. Accompanied with the picture of the three pigs and the wolf blowing wind at their buildings.

It should be no surprise that changes need change management. Every piece of the value chain needs to review impact. Writing requirements or stories organized by impact to each department allows each department to sign-off on their requirements only speeding the agreement cycle. Imagine a world where HR is included in IT decisions and make termination and on-boarding easier. Termination of an employee that removes access to all systems by a single button press. Change management needs dependency management, training plans, deployment scheduling, monitoring, environment scheduling and more. Incomplete design results in incomplete software, so ensure that QA starts early in the change process.

There is no person that is smart enough to see all design issues. Iterative design, and iterative development is needed to ensure constant improvement. The use of enterprise provided framework components reduces the design effort, and ensures enterprise policy compliance.