Validating Architecture

• Architecture goes through various versions based on review before being finalised and fully validated.
• Some validation methods are Technical delivery accessment(TDA),Static accessment,Risk Accessment
• We should ensure sufficient governance is included in that so that there are people to look into the escalations.
• Viability assessment is the QA for architecture.
• Our architecture should pass through all the prescribed reviews.
• Architecture gets reviewed by the design, authority and architecture review board and Governance board.
• There will be technical reviews and security reviews and viability assessments.
• Assumptions and architecture reviews are a key part when we are presenting our architecture to the boards
• Change in assumption changes the architecture decision which in turn changes the architecture.
• Need for Viability and Validation
• Humans are imperfect and so are solutions created by them. Fixing flawed solutions at an early stage of the project costs less than at a later stage.
• Reviews and assessments are used to ensure that the architecture is ready
• Viability - It can be implemented and delivered
• Validation - satisfies the functional requirements and qualities.
• The Unified Method Framework work product for documenting the architecture assessment is Viability Assessment.
• The validation and viability of the architecture are an important element of the overall approach to testing across the whole solution life cycle.
• Faulty Product Design causes
• Fixed price for combined phases
• Vague or misunderstood completion criteria
• Customer responsibilities not clearly identified and documented
• Assumptions not clearly identified and documented
• Concessions during negotiations
• Poorly written proposals or SOWs
• Inaccurate project estimates
• Not performing QA reviews
• Lack of transition, marketing to delivery
• Faulty Project Delivery causes
• Project skills deficiencies
• Not performing QA reviews and action plans
• Lack of line management oversight and support
• Not implementing or exercising change control
• Starting a phase before completing the preceding phase
• Unplanned turnover of key project team members
• We need to consider all the perspectives during the validation like data, privacy, and data security, et cetera.
• Viability assessments and other forms of validation and QA can help prevent your project from becoming troubled only if necessary actions are taken.
• If our design is right, then our technical implementation can be easily solved
• Viability Review Points
• Cost
• Budgets are limited. Even if a project starts off well-funded, new cost constraints may cause solution architectures to change radically from initial design.
• Skilled resources
• Throughout a long-lived project, staff comes and goes.
• Information
• New information requirements, legislation, competition causes change to the business.
• The architecture must change to accommodate new information constantly.
• Time
• Architects never have sufficient time, particularly at the beginning of the project when they have the most influence.
• We need to maintain a balance between availability, system, management, standards, and performance.
• Viability Accessment
• Assess the architecture
• Does it fit the wider context?
• Does it satisfy the wider needs of the business?
• As-is operational environment
• CMO - identify current mode of operations
• FMO - identify future mode of operations
• To-be enterprise architecture
• Confirm that the deployed solution will be operable and maintainable with operations
• Understand the architecture context, requirements and commitments
• Assess whether the proposed solution is possible
• Can it be designed and developed within the available means?
• Develop Solution should be incremental.
• Determine the project team's ability to deliver.
• Are the right resources in place to ensure success?
• Is the necessary infrastructure in place?
• Identify and assess technical risks.
• What risks must be raised and formally managed?
• What are their probable impacts?
• How can these be contained?
• Validation Accessment
• Considerations
• Does it do what is required of it?
• Does it meet the sponsor’s needs?
• Does it do it well enough?
• Is it over engineered, or is it vulnerable?
• Check the functional requirements, working, security etc.
• Acceptance criteria
• The key criterion is that it satisfies the Functional and Nonfunctional requirements
• This is achieved through the use of Requirements Traceability and Verification Matrix (RTVM).
• RTVM(Requirements Traceability and Verification Matrix)
• Ensures completeness of architecture and design through mapping of the requirements (both FRs and NFRs) to the solution components
• Provides the basis for test planning and execution
• Provides a framework for risk management and mitigation
• Provides the basis of clear and timely client communication with regard to schedule, risk, and financial impacts
• Used to validate functional and non-functional requirements
• We map Solution components in functional and non-functional environments.
• Review helps us to know that everything we build is tested and validated
• Validation is not done after implementation. It is addressed throughout the project.
• The testing V model and system engineering baseline reviews are a good starting point for planning validation and verification activities.
• The V model ensures that all tests relate to requirements, and all requirements have an associated test case.
• We perform following type of reviews
• System validation
• Maps, the business objectives/requirements to system, acceptance/validation.
• System verification
• Maps, the business requirements/design to system integration that is functional and non-functional requirements.
• Component verification
• Maps, the system requirements/design to be test cases and reviews
• CVM(Client Value Method) Model
• Understand the clients, business and needs
• Explore options and approach
• Develop and agree to client, Solution
• Implement client, Solution
• Confirm client value and experience
• Validate that the integrated end-to-end proposed solution will fulfill client requirements.
• Validate that the integrated project estimates and schedules being proposed are complete and reasonable
• Identify and assess the technical risks, with containment plans in place to mitigate the technical risks
• Led by an Architect from the Solution Design Architect community
• We perform technical and delivery assessment(TDA), integrated technical review(ITR), proposal baseline assessment(PBA).
• TDA is also presented to the technical architect
• Did the Solution fulfilled client requirements?
• Project plan, estimation model, timelines, technical risk assessments, assumptions, mitigation plans are discussed with technical architect.
• We can use risk mitigation tools
• They help in analysing value of risk rating on rate template.
• These tools can check for the architecture on basis of team skills, requirements and technologies.
• Risk assessment is one of the key inputs to pricing considerations
• High risk attracts a higher price category.
• Assessments should also address assumptions, issues, risks and dependencies(RAID)
• Risk
• A possibility of something not aligned with perspectives happening within the duration of a project.
• Assumption
• Things that the Solution Architect has taken on faith or otherwise have no direct reason to be thought of as true.
• Assumptions have to be verified and then become requirements or constraints.
• Issue
• Something that is causing or will cause the solution to deviate from the requirements baseline
• Issues have to be addressed, and recommendations for their resolution have to be established, agreed, and acted upon.
• Dependency
• Something that a project expects to be in place or resolved before the project completes.
• Dependencies may be
• Business-centric
• IT-centric
• Solution-centric
• Modren Solution Process
• We should try to add agents to our solutions.
• Use Greenfield development 
• Building something completely from scratch.
• Try to use agenetic AI methods for application, migration and modernisation
• What stands out is the explicit division of labor between humans and AI agents at each step distinguished as agent-led, human-led, or jointly-led work
• Initiation stays largely human-led — aligning business objectives, defining MVPs, and establishing governance — but agent infrastructure and readiness assessments are already agent-driven from day one.
• Exploration is where agents start pulling real weight: scanning codebases, mapping dependencies, flagging technical debt and vulnerabilities, and analyzing usage patterns at a scale no team could match manually. Humans stay focused on stakeholder interviews and the nuanced UX judgment calls agents can't make.
• Conceptualization blends the two — agents help validate modernization paths (using a 6R-style framework: rehost, replatform, refactor, etc.) and prioritize by value and risk, while humans finalize architecture decisions and phased execution plans.
• Realization is the execution engine — agents automate migration tasks, generate and run tests, and orchestrate deployments, while critical cutover moments and code-level execution remain jointly supervised.
• Evolution closes the loop with continuous optimization — AIOps-led monitoring, automated runbooks, and agent-driven A/B testing that keeps improving the application post-launch based on live telemetry.