Overcoming constraints

Earlier, in Chapter 2, Solution Architect in an Organization, you learned about the various constraints that a solution architecture needs to handle and balance. The major limitations are cost, time, budget, scope, schedule, and resources. Overcoming with these constraints is one of the significant factors that needs to be considered while designing a solution. You should look at the limitations as challenges that can be overcome rather than obstacles, as challenges always push you to the limit for innovation in a positive way.

For a successful solution, always put the customer first, while also taking care of architectural constraints. Think backward from the customers' needs, determine what is critical for them, and plan to put your solution delivery in an agile way. One popular method of prioritized requirement is MoSCoW, where you divide customer requirements into the following categories:

• Mo (Must have): Requirements that are very critical for your customers, without which the product cannot launch.
• S (Should have): Requirements that are the most desirable to the customer, once they start utilizing the application.
• Co (Could have): Requirements that are nice to have, but their absence will not impact upon the desired functionality of the application.
• W (Won't have): Requirements that customers may not notice if it is not there.

You need to plan a minimum viable product (MVP) for your customer with must-have (Mo) requirements and go for the next iteration of delivery with should-have (S) requirements. With this phased delivery approach, you can thoroughly utilize your resources and overcome the challenges of time, budget, scope, and resources. The MVP approach helps you to determine customer needs. You are not trying to build everything without knowing if the features you've built have added value for the customer. This customer-focused approach helps to utilize resources wisely and reduces the waste of resources.

In the following diagram, you can see the evaluation for a truck manufacturing delivery, where the customer wants a delivery truck that gets delivered initially, and you evolve the process based on the customer's requirements:

Here, once a customer gets a first delivery truck, which is a full functioning, they can determine if they need a more significant load to handle, and based on that, the manufacturer can build a six-wheel, a 10-wheel, and finally an 18-wheel truck trailer. This stepwise approach provides working products with essential features that the customers can use, and the team can build upon it, as per the customer requirement.

Technology constraints become evident in a large organization, as bringing changes across hundreds of systems will be challenging. When designing applications, you need to use the most common technique that is used across the organization, which will help to remove the everyday challenges. You also need to make sure that the application is upgradable in order to adopt new technology, and able to plug in components that are built in a different platform.

A RESTful service model is pretty popular when teams are free to use any technology for their development, the only thing they need to provide is a URL with which their services can be accessed. Even legacy systems such as mainframes can be integrated into the new system using an API wrapper around it and overcome technology challenges.

You can see how the MVP approach helps to utilize limited resources in an efficient way, which helps to buy more time and clarify the scope. In terms of the other factors, when you put the working product in the customer's hands early, it gives you an idea of where to invest. As your application has already started generating revenue, you can present use cases to ask for more resources, as required.

Taking an agile approach helps you to overcome various constraints and build a customer-centric product. In design principles, take everything as a challenge and not an obstacle. Consider any constraint as a challenge and find a solution to solve it.