What are some strategies for dealing with uncertainty and ambiguity in system architecture and decomposition?

Embarking on a significant project, remember the 20/80 rule: 20% of efforts yield 80% of results. Focus on the essential 20% rather than overwhelming details. "Simplicity is key" advocates for a streamlined architecture, ensuring cost-effective maintenance and swift implementation. But crafting an architecture should always allow for easy future adaptations and expansions. Embrace iterative progress from PoC to MVP, RC, and beyond. The wisdom here is to resist the urge for immediate perfection, opting instead for a foundational structure that can gracefully evolve, improve, and expand as needed. In the symphony of development, these principles compose a harmonious melody leading to success.

As a thought leader with almost 2 decades of experience, I have faced many situations where uncertainty and ambiguity were prevalent in system architecture and decomposition. Here are some useful strategies and thought processes that I would recommend - Embrace uncertainty and ambiguity as opportunities for learning and innovation. - Use scenarios and prototypes to explore multiple possibilities and test assumptions. - Adopt an iterative and incremental approach to system development. Uncertainty and ambiguity can be reduced by sharing information and perspectives with stakeholders. Navigating uncertainty is not just a challenge, it's an opportunity for growth.

On top of what the other contributors mentioned, don’t forget to keep calm and positive. Your attitude, showing willingness to go above and beyond will inspire others and bridges will be built between all moving parts to be arranged based on priorities.

As an architect or senior engineer, Defining goals are must and what could be the impact on end users and why it is really important from business perspective and how system behaves in any kind of uncertainty. Below are the processes I would like to highlight. 1. Make a solid diagram of system architecture and sequence diagram of high potential and generic behaviors including failures one for which you may aware. 2. You never know in what scenarios it may break, but while designing the system it should be open ended for incremental approach.

- Ask clarifying questions to understand the problem and define the scope clearly - Document all the questions asked, and the clarity provided. - Establish a clear vision and high-level objectives for the system. This guides decision-making and provides a benchmark against which to evaluate design choices, helping to navigate uncertainty by focusing on overarching goals.

Employ iterative and incremental development methods. Start with a basic version of the system and progressively refine and expand it. This approach allows for flexibility and adaptation as requirements evolve or become clearer.

Listing below. 1. Identify epics in a project first 2. Prioritize epics which are must for MVP. 3. Always check with product for some future scope if they can tell. 4. Always backlog ready and align the resources so that team can start thinking on those requirements. 5. Always have a similar environment of production for one round of UAT and send features to unknown users and seed feedback. Because you will always get more feedback from unknown users as compare to your team.

Iterative and incremental approaches are not always the best: when facing uncertainty and ambiguity, the first step is to define the needs with a proof of concept. It will sometimes redefine the approach and induce a complete redesign. The main design rule of a proof of concept is Keep-It-Simple: - make shortcuts and document them - reuse whatever is at hand - reduce development to the minimum to meet aggressive milestones. Once you have a prototype that kind-of works, you have a better understanding of what is expected.

Applying design principles and patterns actually comes with an experience and how often you spend time to read some good technical articles and apply to your daily routine. 1. SOLID principles are must which every developer should know which explains most of the things. 2. Your framework knowledge plays a critical role, how you put common code in libraries which can be accessible by multiple modules. 3. For an example api design, I often see people these days they simply build an api for specific use case or consumer(for example react) but you need to think beyond single type of consumer, you should design an api which can be called by multiple types of consumers and how much api is capable to respond not only front end.

Event Storming & domain-driven design (DDD) can also be used for clear system design. These are well accepted methodologies in the industry.

This part is indeed uncomfortable and at times ignored. Rarely any system design is perfect and requires compromise to move it forward. Engage the stakeholders from the beginning, even if it leads to uncomfortable conversations. Keep having a dialogue with them, establish the design priorities, design accordingly, and keep moving the design forward.

I think no system design is perfect at initial stage but company should set up architecture review board in place by having cross team leads and experts so that they can review and suggest feedbacks based on their experiences. Because system design made perfect when only how much it is filtered or reviewed by senior members.

There's a strategy popularized by Neal Ford and Mark Richards on their book about architecture, The technique is known as "Last Responsible Moment" (LRM). It involves delaying decisions until the latest point at which failing to make a decision eliminates an important alternative. This practice allows for more information to be gathered before making a critical decision. It encourages continuous reassessment and avoids premature commitments to a particular course of action, thus reducing the risk of costly rework or heading in the wrong direction. However, it requires a high level of discipline and awareness to identify the actual last responsible moment and not delay decisions excessively.

Uncertainty is an inherent part of projects. It can affect functional and/or non-functional requirements, and is best addressed with detailed documentation. A risk analysis will usually help to identify the root causes and decide which strategy should be adopted. On the other hand, ambiguity is a risk that needs to be addressed: it may come from antagonistic expectations or interpretations, in which case a consensus must be found. Ambiguity can be addressed with clear priorities and definitions.