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.

My point of view is quite simple, as an architect you must bridge the gap between the business and technology. This means that with a business stakeholder (even if they do have technical background) you should always speak his natural langue, meaning business language. Quality will come natural if you fully understand the business goal, ambition and process, as you will design having the full end to end (business and technological).

The uncertainty in the requirement is not always deliberate or malicious on a customer’s part. A lot of it boils down to the customer’s own role and focus area in their organisation. Things like Security or Performance and their importance to Solution Architects is not always clear to them. What I’ve always done is to express these requirements in clear stats and numbers from SA perspective but in the domain terminology that the customer understands well and can provide valuable feedback against. The feedback loop fine tunes these requirements, brings additional customer stakeholders online and helps bring important clarity. The key is to be empathetic and ensure customer knows we are trying to help their initiative succeed.

With limited information or requirements solution architect should provide at least two possible solutions with appropriate assumptions along with the recommend approach. That’s what creates a curiosity with the customer then customer may provide their point of view or make some suggestions. If we wait to get all requirements from customer, it’s kind of order taking. That anyone can do. With the limited information solution architects should paint a picture what’s the art of possible.

Divide an organization into 4 parts like CTO/CIO/IT team, CSO, Finance and Business User. Try to understand their requirement, challenges/pain points, goals and priorities. Do as many as possible surveys, meetings, reviews, presentations, sessions with all the stakeholders. Always share design considerations and assumptions to minimize uncertainty

A solution always MUST solve some problem that occurs in some process. (Regardless whether it is a business process, or process within a SW system, or even processes within a domain) Hence, we shall not even expect explicitly stated quality requirements. Because a solution MUST improve overall quality of a problem domain we apply solution to. And there are no exceptions to this rule of thumb. Because if a solution may compromise overall quality - then it is stated as a allowable condition. (For example: increase output sacrificing some of qualities)

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).

Enterprise architects rely on quality attributes and metrics to guide architectural decisions, verify congruence with business goals, and maintain the architecture ecosystem's health and performance.

Often, quality of software are not capable of being fully elaborated at any point of time, especially if the software is not a single use one, eg, a mission specific one. Hence, an important way to imbibe quality is by separation of concerns (SoC). The philosophy, aka, Aspect Oriented Programming (AOP), is cleverly designed such that the main business logic and various quality attributes are designed as loosely coupled software modules.

There are numerous architecture options (technologies) to solve a business problem defined by a set of SMART business/functional requirements. Once you understand the functional requirements, identify the applicable technical requirements (Quality attributes ("ity") as defined by the SEI at CMU) from the list published which includes Scalability, Accessibility, Agility, Simplicity, Availability, Security, Testability, Usability, Reliability, Mobility etc. Strike a trade off if needed. Next apply the constraints, and you will be able to narrow down to the architecture with 'best fitness for the purpose'! It boils down to People, Process, Technology. Focus on all three not on technology alone. Remember, A Fool with a Tool is still a Fool!

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.

As a solution Architect use feedback loops, regular reviews & retrospectives, to refine and improve architecture continuously. Adapt changes based on the feedback received during development. Be prepared to accommodate changing requirements and priorities. Build architecture that is resilient and can be easily adjusted without major disruptions.

Embracing agile and lean architecture principles is like having a dynamic roadmap for building solutions in a world full of uncertainties. It's about taking small, smart steps, with constant feedback from the users and stakeholders, to ensure we're on the right track. These methods, like architectural spikes and reviews, help us fine-tune and deliver quality in ever-changing environments.

Prioritize refactoring tasks based on their impact and urgency. Consider using techniques like the MoSCoW method (Must-have, Should-have, Could-have, and Won't-have) to categorize tasks and prioritize them accordingly. Address technical debt as it arises. Avoid accumulating excessive debt by balancing the need for new features with the need for maintaining a healthy codebase. Establish regular feedback loops with stakeholders, including end-users, product owners, and business analysts. Gather input on the impact of the refactoring from a user and business perspective. Incorporate this feedback into your iterative development 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.

Defer the decisions that you don't need to decide at this instant. Some uncertainty can resolve itself, some requirements change or disappear completely and the remaining things you need to resolve.

Speaking of "Architects" I'd say be a listener, be an advocate of the specific change or requirements by articulating in a way that better informs the stakeholder about the holistic paradigm of what is involved in architecting/ designing/building to better inform the intrinsic factors that are a must to discuss and consider, there by keeping the engagement and the collaboration alive.

It is always helpful to get the quality attributes observable. Availability of monitoring dashboards on quality attributes aid the architects in understanding the current quality of product during discovery and help make appropriate design decisions to meet the desired quality targets. As part of the design, recommend making the new quality targets observable to make your life easier for next program and to measure the success of the current program being designed

Adopt an iterative approach to architecture design and validation. As more information becomes available or uncertainties are clarified, iterate on the architecture to refine and improve alignment with quality requirements.