How do you validate solution architecture across domains?

Firstly: A Solution rarely is being applied across business domains. (Due to its very nature - to be a concrete solution to a business problem) There are two noticeable exceptions: personnel management and information security. So, in such cases in order to assess a solution you shall build a capabilities and features matrix first. Then create matrix of business’ domain specifics. And validate one again another. Such exercise is to be done quite early in the solution development process. The same principle is to applied when a solution is to be applied across LOB’s too

One thing that has to be kept in mind is that every organisation is different and there is no one size fits all kind of scenario. One also has to make compromise based on the constraints put forward by your respective organisation. Rather then starting from scratch to define the validation criteria it's better to look inside and leverage best practices within the organisation if not it has be carefully curated to meet the organisations need.

Solution architecture often appears to be domain-agnostic, but in reality, it's usually tailored to specific domain needs. While generic technologies are used, the actual implementation is domain-centric. To identify common elements across domains, a comparative map of business and technical capabilities can be invaluable. This mapping reveals what's shared and what's unique, aiding in efficient architecture design. However, the idea of validating architecture through simulations usually faces resistance. Although simulations offer technical rigor, they're often viewed as costly with no immediate business value. This perception can deter management focused on short-term gains, despite the long-term benefits.

To make sure that a solution is scalable and avoid any risk due to compliance and access issues, it's always important to validate solutions across domains. There are a few ways we can achieve it: Requirement Alignment: making sure that the needs of all stakeholders are fulfilled. Interoperability testing: clear data contracts and metadata are defined and managed. Cross domain integration testing: making sure data is consistent across domains and all the endpoint are working fine. Compliance testing: different domains may have elevated compliance requirements. Making sure that we are covering all of them is extremely important.

$ Continuous Monitoring: Implement continuous monitoring mechanisms to track the performance, security, and overall health of the solution architecture. Utilize monitoring tools and establish key performance indicators (KPIs) to promptly identify and address any issues that may arise. $ Scalability Assessment: Evaluate the scalability of the solution architecture to accommodate future growth and changes in demand. Consider factors such as the ability to scale horizontally or vertically, and assess whether the architecture can seamlessly adapt to increased workloads.

One thing I've found out to be helpful is external reviews, before making an expensive investment in a technology get an external consultant/domain expert to validate your decision.

Collaboration is the key for cross-domain validation. Identifying the near neighbors and the impacts of the problem is the initial step to creating a solution. Collaborating with cross domain experts and having a high-level understanding of the domain, instead of treating it like a black box, will help the solution to be more extensive. Peer review with cross-domain architects, SMEs, and business will help finalize the approach before the engineering team dives in. A solution with defined integration details, for instance, schema definitions for integration, database definitions, and a high-level diagram, along with business problem broken down to a granular level will help with appropriate feedback and validations to proceed.

In addition to peer reviews which means getting feedback from other solution architects, I find very important, validating the solution with the Enterprise Architectire team, to ensure the solution aligns with the overall architecture strategy.

As per my experience, it should be taken in step-wise manner 1) Do paper work 2) perform experiment and concept testing 3) Address new discovery and repeat step 2 4) develop the solution 5) Testing

Agreed with the contributors' insights, here's my approach for an effective peer review : Begin by setting clear objectives and forming a diverse expert team. Ensure all essential documentation is accessible and up-to-date. Utilize a structured method to thoroughly assess the architecture, encouraging collaborative and open feedback. Emphasize constructive and specific critiques to pinpoint improvements and reduce risks. Record important findings and recommendations post-review. Crucially, establish and closely monitor follow-up actions, guaranteeing the review's impact in refining the architecture. This approach ensures a detailed and impactful peer review, significantly enhancing the solution's quality and dependability.

An example I've seen work well is using policy as code to validate the syntax and semantics of your solution. Policy as code provides a pathway for a faster time to market with the industrialization of infrastructure.

Architect or System design solution can be reviewed with stakeholders to evaluate the feasibility of an implementation. In addition, we shall use established architecture framework checklist to review the same. Ex: Well Architecture framework validates the system in six pillars of Operational excellence, Security, optimized cost, reliability, performance and sustainability.

Closing the feedback loop is incredibly important. All too often in the SA role our work is produced but then it goes off into the ether for signing and then actioning. I always make a point to have a quick chat with our delivery teams at least once a week to see how things are going and if there are future adjustments, we can make in the pre-sales part of the cycle to improve efficiencies or client satisfaction. They hear me say a lot "I'll gather the ingredients, but you have to bake this cake!"

Tools for real-world scenarios are used to assess a solution's handling of varying loads and stress conditions, identify potential bottlenecks, and optimize scalability. Security validation tools scan for vulnerabilities and ensure industry standards compliance. Interoperability validation checks seamless communication between domains, ensuring data formats, APIs, and integration points work cohesively. A data-driven approach enhances objectivity, allowing a comprehensive assessment of the solution architecture's performance and compliance with predefined criteria.

Another important thing to look at is how well your solution is integrated to the existing IT landscape. Organisations spend thousands and millions of pounds to tackle integration challenges later on. It's one of the top concerns of CIOs across the industry. Thinking about it early on in your journey and getting an enterprise integration software like MuleSoft can help solve integration and automation challenges.

- Regulatory Compliance: Ensuring compliance with industry regulations and standards is paramount. The validation process includes a thorough review of how the architecture meets legal and regulatory requirements specific to each domain. - Environmental Considerations: Understanding the operational environment and potential constraints is critical. Validation involves assessing how well the architecture performs under different environmental conditions, such as varying network bandwidth or system loads. - Scalability Planning: Validation involves assessing architecture's capacity to handle future growth and scalability requirements, ensuring scalability planning aligns with business forecasts.

I would recommend a validation to make sure that the solution can be implemented considering the availability of technology, cost, and resources (people) availability. Take the cost , the proposed solution might be the best solution, but if the cost of implementation is too high, then other options needs to be considered.