IdentityServer/AppPortal Arch Roadmap
- 1 Executive Summary
- 2 Current Architecture
- 2.1 IdentityServer technology stack
- 2.2 IdentityServer deployment architecture
- 2.3 Admin technology stack
- 2.4 Admin deployment architecture
- 2.5 App Portal technology stack
- 2.6 App Portal deployment
- 2.7 API technology stack
- 2.8 API deployment architecture
- 2.9 Assessment of system scalability, performance, and reliability
- 2.10 Identification of architectural bottlenecks and pain points
- 2.11 Evaluation of security posture
- 2.12 Review of development and deployment processes
- 3 Vision and Goals
- 4 Architectural Principles
- 5 Key Initiatives and Timelines
- 5.1 Initiative 1: Update Catalis IdentityServer in Production
- 5.2 Initiative 2: Update IdentityServer to replace all instances of AutoMon branding with Catalis
- 5.3 Initiative 3: Update App Portal Front-end Framework and remove hardcoded icons
- 5.4 Initiative 4: Update API .NET Version
- 5.5 Initiative 5: Update Admin Front-end Framework
- 5.6 Initiative 6: Update Catalis IdentityServer to Duende IdentityServer v7.0.1
- 5.7 Initiative 7: Implement Passkeys/Passwordless Authentication
- 6 Dependencies and Risks
- 7 Resource Allocation
- 8 Governance and Oversight
- 9 Architecture Vision
- 9.1 Strategic Goals
- 9.2 Key Principles
- 10 Development Process
- 11 Architecture Governance
- 12 Communication Plan
- 13 Metrics and KPIs
- 14 Review and Update Process
- 15 Conclusion
Executive Summary
Catalis IdentityServer is a cloud-based authentication server based on the OpenID Connect and OAuth 2.0 framework. At its core is Duende IdentityServer which is officially certified by the OpenID foundation (OIDF) the standards body that develops identity and security specifications. Catalis has taken full advantage of the flexibility and extensibility of the IdentityServer product to not only customize the UI of IdentityServer, but also build upon it three modern web-based applications. The first application provides a user interface to the system management functionality of IdentityServer and is referred to as IdentityServer Admin (Admin). The second application provides product management, tenant management, and user management and is called the App Portal. The third application IdentityServer API (API) is the shared back-end that is used by both Admin and App Portal. These four applications: IdentityServer, Admin, App Portal, and API, have been in production use by AutoMon since early 2018.
The Catalis IdentityServer application was originally based on the IdentityServer open-source project started by Dominick Baier and Brock Allen. The two eventually made a fork of their open-source project and started the company Duende. Catalis has since purchased a licensed version of IdentityServer from Duende and we are in the process of upgrading to the latest version. The product proved to be so stable in production that AutoMon had been neglecting version updates over the years. The AutoMon IdentityServer production environment was last updated on 4/4/2023, but this update was only through v3.1.2, which was released on 7/5/2020. Duende, however, has continued releasing regular updates, the last of which was v7.0.1 released on 2/9/2024.
This document outlines the architectural work necessary to bring IdentityServer current and also to enhance the Admin, App Portal, and API applications to bring the most value to all products in the vertical.
Current Architecture
The Catalis IdentityServer information below details the technologies used in IdentityServer, Admin, and App Portal and also describes the environment in which they are deployed.
IdentityServer technology stack
Front-end
Microsoft .NET v7 with C# v11
http://ASP.NET MVC Razor Pages
Authentication:
OpenID Connect (OIDC): industry standard authentication protocol
JSON Web Tokens (JWT): industry standard security token format
Microsoft http://ASP.NET Core authentication libraries – latest encryption/decryption/verification libraries provided by Microsoft
Back-end
Microsoft .NET v7 with C# v11
Microsoft Entity Framework
Authentication:
OpenID Connect (OIDC)
JSON Web Tokens (JWT)
Microsoft http://ASP.NET Core authentication libraries
Database: Microsoft SQL Server
IdentityServer deployment architecture
1 Azure App Service
1 Azure SQL Server
1 Azure Blob Storage Account
Admin technology stack
Front-end
Angular v14: UI framework developed by Google
Angular Material v14: Prebuilt UI Components developed for use in Angular
Sass CSS v1.58: Library used to style HTML elements
Authentication:
OpenID Connect (OIDC)
JSON Web Tokens (JWT)
oidc-client.js library
Admin deployment architecture
1 Azure App Service
App Portal technology stack
Front-end
Angular v14: UI framework developed by Google
Angular Material v14: Prebuilt UI Components developed for use in Angular
Sass CSS v1.58: Library used to style HTML elements
Authentication:
OpenID Connect (OIDC)
JSON Web Tokens (JWT)
oidc-client.js library
App Portal deployment
1 Azure App Service
API technology stack
Back-end
Microsoft .NET v6 with C# v10
Command Query Responsibility Segregation (CQRS): Separates the concerns of the Command (create, update, and delete) operations from the Query(read) operations
Dapper: An object relational mapping (ORM) library which simplifies the create, read, update, and delete (CRUD) operations on the database by automatically mapping database parameters and data results to C# objects
Fluent Validation: A library which allows developers to easily implement complex validation rules on all data sent to the API
MediatR: an in-memory bus which implements a publisher/subscriber (Pub/Sub) used to loosely couple the API layer to the Application Layer and handle intra-domain events
Azure Service Bus: Robust message bus functionality used to communicate with external systems such as Ce Sync
Authentication:
OpenID Connect (OIDC)
JSON Web Tokens (JWT)
Microsoft ASP.NET Core authentication libraries – latest encryption/decryption/verification libraries provided by Microsoft
API deployment architecture
1 Azure App Service
1 Azure Service Bus
Assessment of system scalability, performance, and reliability
Scalability: All Azure App Services can be scaled in real time to handle increased workloads.
Application / Database Performance: The Production environment handles over 1.3 million requests per day with an average response time of 4 milliseconds.
Application Reliability: IdentityServer App Service could be deployed to a different Azure Government Region in case of an outage; however, this is currently a manual process.
Database Reliability: IdentityServer database is not part of a failover group.
Identification of architectural bottlenecks and pain points
Hardcoded product names / icons: Because the application was initially designed to host AutoMon products, some of the product names and icons are hardcoded into the application instead of being derived from a database.
Modularity / learning curve: The application could technically be viewed as 5 separate projects IdentityServer front-end, IdentityServer back-end, Admin web app, App portal, API. Thus, there is a longer learning curve when bringing new developers on board.
Evaluation of security posture
Authentication / Authorization: The Admin and App Portal apps store JWT Access Tokens client side in the browser. This method of storing tokens is now considered obsolete and the industry recommends switching to using a back-end for front-end (BFF) security architecture.
Back-End security: Each request to an API Endpoint must contain a User Access Token which is validated by the API layer before being processed by the Server. In addition to a valid User Access Token, the user’s account must have the proper permissions assigned withing the AIMS system before being processed by the Server.
Sensitive Information: IdentityServer stores all sensitive information in an Azure Key Vault and accesses this information in an encrypted manner at runtime as necessary.
Automatic Key Management: IdentityServer has introduced the ability to automatically manage signing keys. This feature will be deployed in stages throughout the later part of 2024.
Review of development and deployment processes
Development
Each development task is performed on a fork of the development branch
When a developer completes a feature, the feature is deployed to the test environment for testing and UI/UX approval
Only after successful testing and UI/UX approval is a PR created for the changes
A PR is created by the developer for review by senior team members
Only after approval of the PR is the feature merged back into the development branch
Testing is performed on the development branch
After testing has passed on the development branch, this branch is merged into the master branch for the next release
Deployment
A releasable version (frozen code) is created each time code is checked into the master branch. Releases can also be manually created and manually labeled with a version at any time.
IdentityServer, Admin, and API are deployed as a group into the test environment, preview environment, and the production environment with 1 click.
App Portal can be deployed into the test environment, preview environment, and the production environment with 1 click.
Production releases can be deployed multiple times to the preview environment to ensure compatibility before the production environment is updated.
Vision and Goals
This section covers some issues in the IdentityServer, Admin, App Portal system. The following items describe those issues and include steps to resolve the issues.
Easier Product Management
Currently the process for adding new products to IdentityServer requires manual database scripting. Work should be done to allow this process to be completed in the UI.
Passkey/Passwordless Authentication
Implement authentication methods outlined by the FIDO Alliance for passkey/passwordless access to systems. Some examples of tools currently being utilized to enable passkey solutions include Apple Passkey, Windows Hello, Microsoft Authenticator, Google Authenticator, etc. Research implementing passkey/passwordless authentication to IdentityServer.
Security
As mentioned previously the User Access Tokens are stored in plain text client side. Admin and App Portal should be enhanced to implement the Duende Identity Server BFF Framework.
Automated Testing
Admin: contains automated Jasmine tests that run in the build pipeline
App Portal: contains automated Jasmine tests that run in the build pipeline
API: contains automated nUnit tests that run in the build pipeline
Outdated packages
IdentityServer: Production is currently several versions behind the latest released version from Duende.
App Portal: Angular framework is out of date
Admin: Angular framework is out of date
API: .NET version is out of date (should be moved to .NET 8)
Architectural Principles
Following are industry established architectural principles to be followed when designing new functionality for the application:
Modularity: Compose discrete, interchangeable modules with well-defined interfaces, promoting reusability, maintainability, and ease of understanding.
Scalability: Architect features to scale horizontally and vertically to accommodate growing user bases and increased workloads, leveraging distributed systems and efficient resource utilization.
Loose Coupling: Minimize dependencies between components to reduce the impact of changes and facilitate independent development, testing, and deployment of modules.
High Cohesion: Ensure that each module or component has a clear, focused purpose and functionality, promoting better maintainability, testability, and understanding of the codebase.
Separation of Concerns: Divide the application into distinct layers or components, each responsible for a specific aspect of functionality (e.g., presentation, business logic, data access), to improve modifiability and clarity of design.
Security by Design: Integrate security measures and best practices into the architecture from the outset, including authentication, authorization, encryption, and secure communication protocols, to protect against potential threats and vulnerabilities.
Performance Optimization: Architect the application to be performant by employing efficient algorithms, data structures, caching mechanisms, and optimization techniques to minimize latency, maximize throughput, and optimize resource utilization.
Flexibility and Extensibility: Design the application to accommodate future changes and enhancements by adopting flexible, extensible architectures and design patterns that allow for easy integration of new features, modules, and technologies.
Resilience and Fault Tolerance: Build the application to withstand and recover gracefully from failures, errors, and unexpected events by implementing fault-tolerant mechanisms, redundancy, graceful degradation, and automated recovery processes.
Testability: Ensure that the application is designed for ease of testing, with clear separation of concerns, modular architecture, and support for automated testing frameworks and tools to facilitate comprehensive testing and validation of functionality.
Simplicity and Minimalism: Strive for simplicity in design and implementation, favoring straightforward solutions over overly complex ones, to reduce cognitive overhead, minimize technical debt, and improve maintainability.
Adaptability to Change: Architect the application to be adaptable and responsive to changing business requirements, technological advancements, and user feedback, enabling iterative development, continuous integration, and delivery practices.
Key Initiatives and Timelines
This section describes major architectural initiatives planned to minimize technical debt and address the shortcomings defined in the vision and goals section of the document.
Initiative 1: Update Catalis IdentityServer in Production
Description: Currently the IdentityServer version in production v3.1.2 and should be updated with the version that is currently in the Test and Preview environments which is v6.3.8.
Objective: Complete testing in the Preview environment and ready a version update for Production.
Timeline: Q1 2024 - Q2 2024
Key Milestones:
February Q1 2024: Test environment was successfully update with v6.3.8
February Q1 2024: Preview environment was successfully update with v6.3.8
March Q1 2024: Build a new WSFED Identity Provider in the Preview environment to ensure WSFED authentication works properly
March Q1 2024: Complete successful login with Pierce County, WA (WSFED Tenant) user
March Q1 2024: Complete successful login with Washington County, NY (OIDC Tenant) user
April Q2 2024: Update Production Environment to v6.3.8. Update includes Stage 1 of 3 for migrating to Automatic Key Management (AKM)
May Q2 2024: After 2 weeks deliver Stage 2 of 3 for migrating to AKM
May Q2 2024: After 2 weeks deliver Stage 3 of 3 for migrating to AKM
Initiative 2: Update IdentityServer to replace all instances of AutoMon branding with Catalis
Description: As IdentityServer was initially designed solely for use by AutoMon, some emails generated by IdentityServer (Account Created Email, Update Password Email, etc.) and some UI screens still reference AutoMon instead of Catalis. NOTE: This must be done before a Jury or Coral Go-Live
Objective: Update the application from AutoMon to Catalis
Timeline: Q2 2024 – Q3 2024
Key Milestones:
April Q2 2024: Work with product owners from other products to develop new email language
May Q2 2024: Implement changes and deploy to test environment for initial testing
June Q2 2024: Integrate issues found into ongoing Sprints
June Q2 2024: Update preview environments for acceptance testing
July Q3 2024: Push changes to Production
Initiative 3: Update App Portal Front-end Framework and remove hardcoded icons
Description: App Portal is currently running Angular v14 in Production which has been out of Active Support since 11/18/2022 and out of Security Support since 11/18/2023. The App Portal also has a hardcoded list used for displaying icons instead of pulling the icons from the database. This application also has hardcoded instances of “AutoMon” branding
Objective: Update to Angular v16, remove flex-layout library, remove products from code
Timeline: Q2 2024 – Q3 2024
Key Milestones:
May Q2 2024: Update application to Angular v16
May Q2 2024: Deploy to Test Environment for initial testing
May Q2 2024: Integrate issues found into ongoing Sprints
June Q2 2024: Deploy to Preview Environment for acceptance testing
July Q3 2024: Deploy to Production environment
Initiative 4: Update API .NET Version
Description: API should be updated to .NET 8 and tested with the latest libraries from Duende. NOTE: This is not required for a Jury or ORMS Go-Live
Objective: Update the API to .NET 8.
Timeline: Q2 2024 – Q3 2024
Key Milestones:
April Q2 2024: Update to .NET 8
April Q2 2024: Deploy to Test Environment
April Q2 2024: Integrate issues found into ongoing Sprints
May Q2 2024: Deploy to Preview Environment
July Q3 2024: Deploy to Production environment
Initiative 5: Update Admin Front-end Framework
Description: Admin is currently running Angular v14 in Production which has been out of Active Support since 11/18/2022 and out of Security Support since 11/18/2023.
Objective: Update to Angular v16 and remove flex-layout library. NOTE: This front-end is not accessed by customers so updating is not a high priority.
Timeline: Q3 2024 – Q4 2024
Key Milestones:
August Q3 2024: Update application to Angular v16
September Q3 2024: Deploy to Test Environment for initial testing
September Q3 2024: Integrate issues found into ongoing Sprints
October Q3 2024: Deploy to Preview Environment for acceptance testing
November Q3 2024: Deploy to Production environment
Initiative 6: Update Catalis IdentityServer to Duende IdentityServer v7.0.1
Description: IdentityServer back-end should be updated with the latest libraries from Duende. This requires an update to .NET 8.
Objective: Update the Duende IdentityServer packages to v7.0.1 with .NET 8.
Timeline: Q4 2024 – Q1 2025
Key Milestones:
October Q4 2024: Update to IdentityServer v7.0.1
November Q4 2024: Deploy to Test Environment for initial testing
November Q4 2024: Integrate issues found into ongoing Sprints
December Q4 2024: Deploy to Preview Environment for acceptance testing
January Q1 2025: Deploy to Production environment
Initiative 7: Implement Passkeys/Passwordless Authentication
Description: The industry is quickly adopting passkey/passwordless authentication using tools such as Apple Passkey, Windows Hello, Microsoft Authenticator, and Google Authenticator. Research and implement a solution using these technologies into Identity Server.
Objective: Update the API to .NET 8.
Timeline: Q4 2024 – Q1 2025
Key Milestones:
November Q4 2024: Research existing implementations of Passkeys with IdentityServer
November Q4 2024: Implement Passkeys for internal users with a sample product
December Q4 2024: Deploy to Test for initial acceptance testing
December Q4 2024: Integrate issues found into ongoing sprints
January Q1 2025: Deploy to preview environment for acceptance testing
January Q1 2025: Deploy to production environment
Dependencies and Risks
Identification of dependencies between architectural initiatives and potential risks (e.g., resource constraints, technology adoption challenges) that could impact successful implementation.
Major Production update from IdentityServer v3 to v6 requires significant testing in Preview environment to prevent outages. This includes setting up a new domain in Azure with WSFED authentication for testing.
Updating all 4 products (IdentityServer, Admin, App Portal, and API) and testing them together will require significant effort
Angular Flex-Layout library usage will affect a large percentage of the HTML files in Admin and App Portal applications
Timelines were created assuming Bradey Stephens and Daniel Gerard are both working near full-time on all initiatives
Resource Allocation
Update Catalis IdentityServer in Production
Resource Allocation: Bradey, Daniel
Training Needs: Review all changes made to source for IdentityServer v6.3.8
Update IdentityServer to replace all instances of AutoMon branding with Catalis
Resource Allocation: Bradey, Daniel
Training Needs: None
Update App Portal Front-end Framework and remove hardcoded icons
Resource Allocation: Bradey, Daniel
Training Needs: Review resources for removing Angular Flex-Layout
Update API .NET Version
Resource Allocation: Bradey, Daniel
Training Needs: Review .NET 8 documentation / C# 12 language enhancements
Update Admin Front-end Framework
Resource Allocation: Bradey, Daniel
Training Needs: None
Update Catalis IdentityServer to Duende IdentityServer v7.0.1
Resource Allocation: Bradey, Daniel
Training Needs: Review documentation for Blazor
Implement Passkeys/Passwordless Authentication
Resource Allocation: Bradey, Daniel
Training Needs: Review specifications for Passkeys
Governance and Oversight
Purpose
This plan establishes a clear framework for software development and architecture governance within the Jury V2 project. This framework will guide the design, development, and maintenance of our systems, ensuring consistency, quality, and alignment with our business objectives.
Scope
This plan covers all aspects of software development and architecture for the Jury V2 product, including design principles, development processes, architectural standards, and governance mechanisms.
Architecture Vision
Strategic Goals
Enhance user experience and accessibility.
Ensure scalability and performance.
Maintain security and compliance standards.
Facilitate integration with external systems.
Key Principles
Modularity: Design systems as a collection of independent, interchangeable modules.
Interoperability: Ensure systems can exchange and use information seamlessly.
Scalability: Design systems to handle increasing loads gracefully.
Security: Embed security considerations into every aspect of the architecture.
Development Process
Agile Methodology
Sprints: Develop features in short, iterative cycles (sprints). Sprints will last 2 weeks.
Backlog Management: Maintain a prioritized list of user stories and tasks.
Continuous Integration/Continuous Deployment (CI/CD): Automate testing and deployment processes.
Quality Assurance
Code Reviews: Conduct regular code reviews to ensure code quality and adherence to standards.
Automated Testing: Implement a comprehensive suite of automated tests (unit, integration, and end-to-end).
Performance Monitoring: Continuously monitor system performance and address any issues proactively.
Architecture Governance
Architecture Review Board (ARB)
Establish an ARB comprising key stakeholders to oversee architectural decisions. The ARB will:
Review and approve architectural designs and changes.
Ensure alignment with strategic goals and compliance with standards.
Resolve architectural conflicts and issues.
Standards and Guidelines
Develop and maintain a set of architectural standards and guidelines, covering:
Coding standards
Security protocols
Data management practices
Integration patterns
Compliance and Auditing
Implement mechanisms to ensure compliance with architectural standards and guidelines, including:
Regular audits of code and architecture
Automated tools to enforce standards
Reporting and addressing non-compliance issues
Communication Plan
Meetings
Architecture Project Kick-off Meeting:
Frequency: At the project initiation phase.
Attendees: All stakeholders.
Purpose: Introduce the project, its goals, roles, and expectations.
Bi-Weekly Status Meetings:
Frequency: Every other [Specify Day] at [Specify Time].
Attendees: Software Development.
Purpose: Discuss progress, address issues, and plan for the upcoming sprint. Decide if changes are needed to architectural plan.
Sprint Planning Meetings:
Frequency: At the beginning of each sprint.
Attendees: Software Development, Product Management, and Project Management teams.
Purpose: Define sprint goals, prioritize tasks, and align on the scope.
Sprint Review/Demo Meetings:
Frequency: Every other [Specify Day] at [Specify Time].
Attendees: Software Development, Implementation, Product Management, and Project Management teams.
Purpose: Demonstrate work that has been completed, discuss sprint goals and what was completed. Architecture work will be part of normal sprint demo time.
Communication Tools
Email: Use for formal announcements, reports, and documentation sharing.
Project Management Tool (JIRA): Use for task tracking, updates, and collaboration. This is also the Dev tool for tracking work.
Instant Messaging (Microsoft Teams): Use for quick updates, queries, and informal discussions.
Video Conferencing (Microsoft Teams): Use for remote meetings, workshops, and brainstorming sessions.
Roles and Responsibilities
Team Architect: Chosen member(s) from the team that will act as the architect for the software product and drive architecture work forward. They will assume responsibility for architecture plan movement in lieu of a project manager.
Team Leads (Development and Implementation): Responsible for team-specific communication and reporting.
Product Manager: Responsible for product-related communication, prioritizing features, and gathering feedback. In lieu of a Product Manager, the team will reach out to Project Managers for Product-specific guidance.
Escalation Process
In case of unresolved issues or conflicts, the following escalation process will be followed:
Level 1: Team Leads will attempt to resolve issues within their teams.
Level 2: If the issue remains unresolved, it will be escalated to the Project Manager.
Level 3: If necessary, the issue will be further escalated to the respective department heads or higher management.
Reporting
Regular status reports will be shared with all stakeholders, summarizing progress, issues, and action items. These reports will be distributed after each bi-weekly status meeting.
Metrics and KPIs
Scalability: Measure the system's ability to handle increased workload or growth in data volume, users, or transactions.
KPIs: Response time under load; resource utilization.
Reliability: Evaluate the system's ability to perform consistently and predictably under varying conditions.
KPIs: Mean time between failures; mean time to recover; error rate.
Maintainability: Assess how easily the system can be maintained, updated, and enhanced over time.
KPIs: Code complexity (measured by SQ); time to develop and deploy new features.
Interoperability: Evaluate the system's ability to work seamlessly with other systems or components.
KPIs: Time to successful integration acceptance; failure/success rate of integration tests.
Compliance: Ensure that the system meets regulatory, legal, and contractual requirements. Also ensure the security ticket backlog is regularly mitigated.
KPIs: SOC2 audit compliance results; customer acceptance of regulatory changes; number of reported incidents; security backlog and scanning through SonarQube and Qualys.
Review and Update Process
To ensure that the architectural roadmap of the Jury V2 product is regularly reviewed and updated to align with evolving business needs, incorporate emerging technologies, and address feedback from stakeholders.
Initiation: The review and update process is initiated quarterly, triggered by the end of each quarter.
Stakeholder Identification: Identify key stakeholders who will contribute to the review and update process, including product managers, implementation personnel, developers, QA, architects, and any other relevant parties.
Feedback Collection:
Stakeholders provide feedback on the current architectural roadmap, highlighting areas for improvement, emerging trends, and business needs.
Feedback can be collected through surveys, interviews, and workshops.
Review Meeting:
A review meeting is scheduled with key stakeholders to discuss the feedback and assess the current architectural roadmap.
The meeting agenda includes a review of the feedback, identification of key areas for update, and prioritization of changes.
Update Proposal:
Based on the review meeting, a proposal is drafted to update the architectural roadmap.
The proposal includes a summary of feedback, proposed changes to the roadmap, rationale for the changes, and estimated impact on the product.
Approval Process:
The update proposal is presented to the ARB and development management for approval.
The ARB and development management team evaluates the proposal based on alignment with business goals, feasibility, and resource availability.
Implementation Planning:
Once approved, an implementation plan is developed detailing the steps, timeline, and resources required to implement the updates.
The plan includes the previous communication plan to inform stakeholders about the upcoming changes.
Implementation:
The updates to the architectural roadmap are implemented according to the plan.
Developers and architects collaborate to ensure that the updates are integrated smoothly into the development process.
Monitoring and Feedback:
Post-implementation, the updated roadmap is monitored closely to assess its impact on the product.
Feedback is collected from stakeholders to evaluate the effectiveness of the updates and identify any further improvements needed.
Documentation:
All updates to the architectural roadmap, including feedback, proposals, and implementation plans, are documented for future reference.
Documentation is made accessible to stakeholders for transparency and accountability.
Continuous Improvement:
The review and update process is iterative, with regular reviews scheduled to ensure that the architectural roadmap remains aligned with business needs and technology trends.
Lessons learned from each review cycle are used to improve the process for future updates.
Conclusion
The review and update process outlined above ensures that the architectural roadmap of the product is regularly reviewed and updated to meet the evolving needs of the business, incorporate new technologies, and address feedback from stakeholders. This process helps to ensure that the product remains competitive, innovative, and aligned with the strategic goals of the organization.