Pushing back, red flags

As a Solution Architect, there are certain topics to be considered while looking at requirements and defining the right implementation for the provided requirements

All the below are to be taken into consideration, and while

Some of those topics are:

• Performance and sizing: see Performance Practices

• Integration: Are there any expectations in regards to e.g. Real Time API Calls? How many, or how long should they take?

• MVP vs Nice to Have Requirements:

  • MVP (Minimum Viable Product): MVP stands for Minimum Viable Product and it refers to the simplest version of a product that can be launched with minimal features necessary to meet the needs of early adopters and gather feedback. The primary objective is to test the product's core functionalities in the market, validate assumptions, and learn about user preferences with the least amount of effort and development time. This iterative process helps in identifying improvements and making data-driven decisions for further development, reducing the risk of building a product that doesn't meet market needs and ensuring more efficient use of resource

  • Nice to Have Requirements: While MVP usually contains critical requirements, there should be a clear distinction with the “Nice to Have Requirements”, which by definition, should not be part of the MVP and should be left for a later stage

• Customer’s recommended design possibly causing more problems than they solve: While looking at the requirements and the design options, it should be clear that the SA is the most knowledgeable person in regards to how to implement the desired functionality in PFX, meaning that the Customer Architects or Product Owners can provide guidance and suggestions, but it is the SA the person responsible for the final design, and should defend his/her design and not let external influences decide on the best approach