How can you navigate uncertain quality requirements in solution architecture?

The role of solution architect is to deal with uncertainty. If you are designing your solution purely based on the 1 liner or 2 liner requirements provided by your business, you are completely missing the mark. You need to be a visionary, go deep and understand the intent and context behind those requirements and solve for the bigger problem. Your solution should address the broader intent and outcomes but lend itself for iterative implementation and should be incremental value driven. Understand the key business drivers, have a conceptual architecture and then a reference architecture and then describe the capabilities over time and define the investment roadmap and show how the architecture will influence the portfolio over time with ROI

Simple answer. Dont. Refuse to accept a customer order until its clear as a bell quality and other factors. Ive walked away from deals. Missing in the above list - risk. Always analyze risk factors up front. Reduce likelihood of missed budget or timing. #1 reason for poor quality - trying to get back on-budget or on-time too late.

Categorize requirements into 4 quads(zohari window) 1. Known-Knowns, that are certain for both parties, you(solutions architect) and the stakeholders, all these requirements can be incorporated to solutions design. 2. Known-Unknowns, that stakeholders identify as important, but these are not fully clear. To unleash these, engage in active discussions with stakeholders, develop prototypes and convert these unknowns to knowns. 3. Unknown-Knowns, that you would have made assumptions, without explicit confirmation, you should with utmost care, get these assumptions clarified, to convert unknowns to knowns. 4. Unknown-Unknowns, that are blind spots, for which you would need to create flexibility in the designs to accomodate these in future.

The main role of Solution Architect is not only to design and provide solution for known but predict the possibilities of unknown unless it is completely different than the main approach or driving vision of overall scope. SA shall look for the reason of the uncertain requirements, find why it was not initiated earlier, understand the impact of including into current solution, investigate the root cause of the origin and severity or driver of the base of the requirements. Inform stakeholders about this change and get proper approval provided if this uncertainty doesnt deviate too much from the current baseline solution.

Sailing through the seas of uncertain quality requirements in solution architecture demands a keen navigator's mindset—start by charting the sources of uncertainty. Picture them as constellations in the project sky, each a unique challenge waiting to be deciphered. As a solution architect, I've learned that uncertainty isn't a foe but a guide, pointing towards areas that crave clarity. Imagine yourself as an architect-explorer, seeking hidden treasures amidst the ambiguity. Embrace uncertainty as a compass, steering you towards a robust, adaptable solution. It's not about avoiding the waves; it's about surfing them with ingenuity.

A good way that works for me is to keep the business team near to the tech team as much as possible. Thinking about the solution without really understanding the product may be your failure. A good strategy for this is to use the Domain-Driven Design (DDD) philosophy, where you can involve all the stakeholders on the same page and discuss the all journey and not only the tech or business things. And, next, you can develop your product using the behavior-driven. All things will make sense.

Depending how bureaucratically you want to be in your applied architecture solution, and how you want to drive the engineering team to deliver. The best approach that I've seen in my experience has been to model your metrics and standards against Architecture fitness functions that measure the quality you want to achieve. This way allows you to achieve an evolutionary and agile design of your solution system.

The biggest issue with defining quality metrics is absence of clear cut baseline that is acceptable in current and in future. if there is an existing system that is being replaced still you have a reference point which can be prorated to future demands, but in case the system is brand new identification should be done using industry best practices and at a layer and aggregate level

Some important metrics to consider and prioritize as per business stakeholder inputs: Performance: Response time, throughput, efficiency Reliability: Availability, fault tolerance, recoverability Security: Authentication, authorization, encryption Usability: User experience, accessibility, learnability After prioritization, define measurable metrics and set an acceptance criteria. Utilize industry set standards and best practices to align with business objectives and follow iterative refinement.

Defining or collecting quality attributes should be the first step. This includes 1) list and validate applicable non-functional requirements from business users 2) assign quantitative or qualitative metrics against each 3) explain how these will be achieved in solution architecture document. This serves as reference for system designers, developers and testers throughout the lifecycle. For key architectural decisions, it is advisable to maintain ADR (architecture decision records).

Navigating uncertain quality requirements in solution architecture demands agility. As an experienced solutions architect, I prioritize collaboration, rank attributes, prototype for feedback, and adapt based on real-world data. Lean principles ensure efficiency without over-designing. We mitigate risks tied to unclear requirements, prioritize user experience, and foster a culture of continuous improvement, all while maintaining clear documentation and quality assurance through integration and testing.

Proof of Concept Pilot Roll Out That way you can iterate as you go Allows flexibility and at each stage you can add more quality metrics

Many teams think they are agile but certainly are not. Being agile means embracing and adapting to change at every step. Accept feedback and work from it to improve the overall architecture. Use different tools, seek opinions and incrementally improve the solution you have.

Applying agile and lean principles to architecture is indeed a smart move, especially when dealing with uncertain quality requirements. It's about embracing a mindset where change isn't just expected but welcomed as part of the journey. In a way, it’s like building a bridge while walking on it, constantly adjusting your path based on the feedback you get and the challenges you encounter. The idea is to move away from the traditional approach of trying to get everything perfect from the start. Instead, you focus on developing your architecture in small, manageable increments. This could involve architectural spikes to explore potential solutions, or creating an architectural runway.

The following 3 steps are normally part of the plan while designing and implementing a solution: 1) Incremental Development: Implement requirements in small, manageable increments. 2) Agile Methodologies: Adopt agile practices to allow for flexibility and iterative improvements. 3) Prototyping: Develop prototypes to test and validate requirements early in the process.

Watch out for anti-patterns when doing solution architecture - one of my favourite ones to be aware of is “do not implement a pattern for the sake of the pattern”. In other words don’t apply patterns as a religion, there is always exceptions. If you do, you often end up over-engineering your solutions.

Explore design patterns relevant to your technology stack and problem domain. Tailor the chosen framework to suit your specific context. Solutions are rarely one-size-fits-all, so be prepared to customize and extend the chosen framework based on your organization's unique requirements. Personally, I also like to create a pattern library that documents the architectural patterns, design principles, and best practices relevant to your solution. This library serves as a reference for the development team and helps maintain consistency across the project.

Explore patterns that meet the solution, don't go for a pattern that will be better for a wild range of solutions. Keep in mind the functional and business criteria, or else you're going to create a legacy solution on the first day. As solutions architect, your main goal is to solve step by step, unless you're trying to redesign a lot of solutions at once, there's no need to build a general solution, even on those cases, it might be better to go through each solution and check for similarities and then design a solution for each group of similarity.

Many software design patterns are reinforced by application frameworks. Using a handful of design patterns to manage domain models and business logic can go a long way towards maintainability and scalability. General patterns can be tweaked to better align to specific functional and non-functional requirements.

I'm shocked nothing is mentioned about risk assessments. Defining the scope is a vital part of solution architecture, without it you will have a never ending project. Risk assessments and mitigation plans are also important because no project comes without risk. Risks can adjust your requirements and help refine your scope.

Typically Enterprise Architects and the solution architecture work they do are domain specific. A seasoned architect within a business domain should have some or a lot of familiarity of the current business fundamentals. Even if not all the requirements are laid out, a working framework of how the business operates can provide useful insight where there is vagueness. Once a person has a clear grasp of the fundamentals of the business they support, greater insight and clarity can be realized in the solution architecture.

A solution architect should be a strategic thinker with a broader perspective. Translating business problems to an end to end solution with different towers of business processes, application architecture, data flow and technology infrastructure. In my experience, adaptability to ever changing requirements from stakeholders and decision making for it's re-alignment are just as critical to be effective.

Prioritize Quality Attributes: When faced with conflicting or unclear quality requirements, work with stakeholders to prioritize them. This helps in making trade-offs and focusing on the most critical attributes. Prototyping and Proof of Concepts: Build prototypes or proof-of-concepts to explore different design approaches and validate them with stakeholders. This iterative process can help in refining requirements and design choices. Risk-Driven Architecture: Identify and assess the risks associated with unclear quality requirements. Focus on addressing the most critical risks early in the design to reduce uncertainty.

A solution architecture is a joint effort between Business, IT and many other stakeholders including 3rd party system owners. Reality is that they have their own priorities and a solution architect has a deadline to meet. As a solution architect, I would do my best to reach out to different stakeholders to get the requirements on time, propose a solution based on the information I have received. Design document will have clear mention of the shortcomings of the proposed solution and potential impact it may have on the overall solution or on specific applications. Of course there must be a basic quality standard check and the rest should be handled as continuous improvement.