How can you handle feedback on your system architecture from peers, clients, and users?

The best ever feedback I received from the Product owner who was engaged into Sales and Client support. He used the product in his day-to-day life and spoke to clients to understand what is good and what is bad. If there is no such person in your organisation then I recommend to ask Sales to take you to their meetings with clients. Just listen what they discuss there, you may be surprised with what you will hear there.

Architecture is about Fit for Purpose and Value for Money more than anything else. Feedback should be gathered in a structured way which can be easily linked back to the requirements. Any feedback linked to a requirement should get priority and the other feedbacks could be put in the "good to have" category. Not all requirement backed feedbacks are important. The feedback should be ranked in terms of relevance, customer satisfaction, quality of service, cost and performance. These decisons cannot be taken in silo and the architect should evaluate them with the key stakeholders of the project too ensure better coverage and incorporation of the feedbacks.

In addition to understanding the feedback source, you should insist on a diverse set of reviews from peers with different areas expertise. It is not sufficient to receive general technical feedback about your architecture. It should be reviewed by subject matter experts from each subsystem, other solution architects, product managers, cyber security SMEs, if necessary contracts and legal, etc. If your reviewers do not provide any constructive feedback, don’t use them again. Find reviewers that work to uncover flaws. It will save you time and money in the long run.

Feedback should be taken in perspective below F-->Foster the desire E-->Enlighten with Need E-->Engagé in brainstorming D-->Develop according to requirement B-->Bestow the change A-->Align with Peers C-->Communicate to Stakeholders K-->Know the Product "Never think you are the only Genius someone else can also have better understanding of what you are doing "

Assuming Sales/PM are listening and eager on feedback, the feedback will usually come in the form of a conversation(causal), and at times formal, in a meeting or an RFE(request for enhancement) It is up to the vendor’s engaging team with the customer or partner, to query, for context, depth, customer need and the benefit to be had by the customer from having the change, IF any. In most instances after the above data points are collated, the collated data then goes to the PM team for analysis & review on the final path forward(for “business” reasons, which directly relate to the company goals - with the hope, here is, that business has a good cause & goal as a community entity)!

One thing I have found useful is that sometimes you need to minimise your discussion time frame. If its exceeding more than 30 minutes, it should be rescheduled with more clarity. Those feedbacks which are not relevant cannot be thrown in backlog at all because they will need a revisit later. Some feedbacks are extremely important but due to capacity and urgency those will be thrown in backlog and will be addressed later depending on priority. Feedback with certain examples or proof of concept can be really valuable to evaluate. Clarity is most important, if during some high priority implementation any feedback is taken and it increases time lines then you have to go an extra mile to make sure successful delivery.

If designing components is like a journey, feedback can act like google maps. Different feedback can be received, similar to multiple routes to the same destination, however the choice of which feedback to consider can depend on different factors depending on the business, architecture, time to market or customer specific needs. So seeking feedback is one part and applying it is another important step

Designing a robust system is a complex task that cannot be done in isolation. It starts with asking questions, understanding requirements, and conducting thorough research. Consultation with domain experts is vital to establish a strong initial design. As the design matures, involving peers for feedback becomes crucial. Initially, limiting participants ensures attention to detail and efficiency. However, a weak design can lead to overwhelming feedback, making prioritization and incorporation challenging. Eventually, presenting the design to a wider audience is necessary, as stakeholders at all levels may offer valuable insights to significantly improve it.

In the quest to improve our system architecture, the quality of feedback is paramount. It's essential that the feedback we receive is neutral and unbiased, regardless of personal relationships within the team. For instance, during a recent review of our API design, it became clear that opinions were divided. To navigate this, I steered the conversation toward our business goals, asking questions that would elicit genuine, growth-oriented responses. Feedback must align with our tech stack and business needs, not just individual preferences or assumptions. By focusing on constructive, objective input, we're better equipped to make decisions that will strengthen our system architecture in the long run.

Feedback is based on the requirements of the system you are building, specifically non-functional requirements. Good feedback ensures that all requirements are adhered to in the architecture, and it emerging and opens up to extensibility in terms of scale and layered. Have a list of RACI - who is responsible, who is accountable, who needs to be consulted, and who needs to be informed. And have a first session with all, and then meet one-on-one (in each category), and then wrap all the feedback again in one meeting, as long as the document is shared and everyone can view the comments, changes, and decisions.

List out all the feedback, go through the tradeoffs for them with the people, and prioritize based on impact on short-term and long-term first based on validity (how important is it now). And then look at the feedback on relevance (how does it impact, small, medium, or high). Now review the list of short-term, with high, and medium first, followed by long-term, high, and medium. Incorporate the feedback in that order, and backlog the rest for future enhancements/review.

It is important to quantify feedback in order to determine which feedback is worth implementing. As Lord Kelvin said, "If you cannot measure it, you cannot improve it." Some feedback may seem interesting, but it is important to determine whether it will lead to meaningful improvement. There are a number of ways to quantify feedback, such as by counting the number of times a particular issue is mentioned, or by assigning them a weight. Once quantified, it can be compared to other feedback to determine which feedback is most important to address.

Identifying the feedback and classifying its importance are both an easy and hard task. Sometimes, the client might treat it as urgent, however, by looking at the bigger picture, you might see it otherwise. It is also important to look at the current timeline of the project. If the feedback is somehow related to an existing deliverable, it could be easily addressed. However, if a client has already signed-off a release, you might need to communicate to the client and agree for trade-off, if the addressing it might cause a speed-bump on timeline. Communication is always a key factor in addressing and prioritizing feedback.

A valuable direct feedback on architecture arises after solving operational incidents: Conduct a thorough post-mortem and calculate the cost of the incident happening again at other clients with the resources spent on this one. This gives you the amount of money you're able to spend on improving the system so it never happens again with any customer. The gravity of the incident + risk of repeat are in turn a good indicator of the priority it should be given.

Implementing a User Acceptance Form can be viable solution when delivering a functionality, collect feedback, and documenting the same. It will ensure that everyone involved are on the same page, and can always refer to the documentation if confusion comes up. We always setup a meeting and try to involve everyone from the unit heads to the front liners who will primarily use the functionality. This ensures that we cover how the functionality will be used by the end-user and how will they interpret the results. This reduces the back-and-forth of communications and unintended changes. Plus, it encourages that everyone involved agrees on the documentation before the actual deployment.

Feedback is key to improving your system architecture. Receiving feedback on your system architecture is a valuable opportunity to improve it. Here's my vision how to handle it from peers, clients, and users: Be receptive and open to feedback. Listen actively and ask clarifying questions. Evaluate the feedback carefully. Prioritize the feedback. Take action on the feedback. Follow up with the feedback provider. Finally, consolidate feedback from different sources.

Build a mechanism to solicit & respond to feedback at time of initial design. Find ways to handle routine feedback as well as "critical" (as in serious flaws). Engage as feasible and do not be quick in closing out comments.

Software development is a series of decisions; some decisions have a business impact, and some are technical and social (people). All these decisions cannot be made in isolation, so communicating with all stakeholders when incorporating is the most critical aspect of architecture. In the best teams of architects, we need 3 types of skills that is one who can create prolifically and one who can prune ideas and stuff when it's in excess or not serving the purpose. And most important perspective is one who has experience in day-to-day operations of how the architecture or the product works in production. Combining all three perspectives is important and usually lacks and leads to ivory-tower architecture decisions.

Software architecture is a creative process that thrives on collaboration from individuals of all positions. Cultivating a culture that encourages open dialogue and recognizes valuable contributions promotes active participation and a sense of ownership over the system. While you may hold the final responsibility for design and vision, giving others a voice by facilitating discussions yields a more comprehensive and thoughtful design that garners collective support. Seek input, bounce ideas around, brainstorm, and organize collaborative design workshops with engineers when applicable.

In modern Software days , where technology is evolving so rapidly , have a single mind to architect an end to end Software or solutions is a big No, specially when there are cases of no feedback route. A feedback route is a must , software architects must share what they are doing with peers , discuss the ideas , progress and end goals constructively to learns and sometimes even take advantages of peers knowledge on the matters that may be aliens to one.

I have found establishing a repository to be very useful in exchange of views and ideas. This obviously depends on all stakeholders aligning to using the said repository. A collaborative repository works well when used correctly. Sometimes it is necessary for the PMO to enforce and ensure collaboration.

When you seek a feedback, make sure to explain what is the real problem you are trying to solve (AKA the job to be done) before jumping to explanation of the implementation

If negative feedback comes from an active user, from your target customer group, and confirmed multiple times - you have no other way, but bite the bullet and actually adopt your architecture to reality. Maybe you don’t like what you hear, maybe you are getting offended (deep inside), maybe that was specifically Your decision to do it differently 2 weeks ago. But when users share their feedback - you adopt accordingly and fast. Own it (system design). That’s why you are an architect.

This is probably one of the more difficult things to get right, not just as a Technology Professional, but in life in general. If we take all feedback as criticizing feedback aimed us and our abilities as opposed to constructive guidance on the output, we are never going to be open to growth and development. Approach the feedback with an open mindset, as feedback aimed at improving your skills in the longer run. Challenge your mental model on learning. Focus on an open growth mindset. And most important of all. Reflect on your emotions. Try to understand WHY you feel like you do when you get feedback. It’s only after you’ve stepped outside your comfort zone that you begin to change, grow, and transform. Roy T. Bennett

Someone used the word "adopt" customer's feedback. I'd like to introduce listen and adapt or adopt. Sometimes, one should adapt rather than wholesale adopt. If someone said that "2+2=5", I would try to find why the customer would say this. Maybe, the customer knew the answer had to be "5" and the designer needed to re-analyze and to ask different questions. The "2+2" was the wrong question.

Having contributed to system architecture in start-ups, one major hurdle in having upfront end to end architecture is the lack of feedback from your end users. While the product-market fit evolves, one needs to be prepared not only to make major changes but also re-start/re-think the architecture from scratch. One example in the embedded world would be what interface to use PCIe, SDIO, USB etc.

Sometimes feedbacks come w.r.t. very old features (maybe developed years back) and team keeps patching the old features. But most of the time it incurs significant cost, impacts performance and other non-functional aspects. While it is not completely avoidable, teams should also consider if it is worth re-designing certain features based on newer techniques so that the cost of maintaining old features reduces in the long run. When we re-design a module then it is easier to accommodate a lots of feedbacks that various stakeholders might have provided.

As system architecture evolves, documenting architectural decisions in a low-maintenance format is vital. Architectural Decision Records (ADRs) are an effective way to track changes, timelines, and rationales. System documentation undergoes frequent updates, so efficiently monitoring changes is essential. An effective approach is to store documentation alongside code in the source control system, like GitHub pages, enabling synchronization with Developer Portals like Spotify's Backstage. Diagrams, when included in the Repository's docs, should use change-friendly formats like Mermaid. When updating documentation is not overly burdensome, it's more likely to stay current.

One of the challenges when developing an architecture iteratively is communicating change. Since not all stakeholders might attend all reviews or keep up with the documentation, their actual understanding of the architecture might drift, leading to unmet expectations or at worst, to the wrong thing being built. Constantly keeping up and communicating changes at all levels is one of the great challenges of architecture.

"A picture is worth a thousand words". I a world of FOMO, you must always start by providing a visual representation of your system to receive valuable feedbacks from your peers, customers and users.