Continuing the key concerns on the application architecture,
Cost of product development plays a big role
If the proposed architecture results in a lot of labour it is usually shot down no matter how good it is. This can also happen due to lack of skill thereby requiring more time to realize the architecture by the team. Budget is always constrained in organizations, especially for new ventures. Architecture will be even more constrained when developers decide to code something quick and be able to handle the short term need. If the product becomes a hit, demand picks up and all the issues come to the fore.
If it is a web application, this model works perfectly fine as the initial budget is invariably small and nothing in the sense of a scalable, reliable architecture can be done. The broad outlines can be specified in terms of the components, interfaces, functions and then the plane takes off. If the product is a hit, more funds are available and scaling can be addressed at that time. Most of the time the users are also individuals and the fee collected per them is not significant to be precise in terms of delivering a fool-proof architectural answer.
However, if it is a enterprise application paid in millions by the customer and used by millions of people of the customer such as a telco application, then short-term solutions turn into nightmares later driving the project into a death spiral and ending up having a irated customer. Architecture in such a case should be given a serious thought. In this case, the cost of having a architectural underpinning is usually insignificant compared to the size of development. Or in other words the cost of architecture should not exceed 10% of the product development cost to give a rough idea. This I believe if executed correctly should give the benefit of reduced labour resulting in lesser cost of incremental development of the product and a quicker turnaround time in releasing new features.
It would be suicidal to go with a non-architecture approach for a large enterprise application. As the number of users increase, the size of data goes up, the rate of failures due to bugs, the predictability of performance and scaling comes to the fore without a sound architecture. Bad architecture always comes to haunt a product team at a later stage when the number of users increase. Citing cost or schedule pressures in avoiding architecture is not a sensible thing in this scenario as cost due to adhering to a architecture is always lesser when compared to the cost of an adhoc development and resulting rework.
A well thought out architecture results in the simplest and best way to address a problem. However, this means the problem should be correctly stated as much as possible. If this involves a cost, it is money well spent. The hassles of spending money on a imaginary problem is far worse. Often cost overruns happen due to incorrect perception of the problem and a improper answer. For example, a requirement that says the requests will hit the application at 10 TPS (transactions per second) if in reality is at 100 TPS, not having a Cache or a light weight framework in the architecture may cost the day for you.
There is no idealistic architecture. It evolves over time. Thus, it is important to spend money to refine the architectural thinking with prototyping. If multiple options can be tried quickly and the best technology or approach is identified, then it saves a lot of money.
Cost of product development plays a big role
If the proposed architecture results in a lot of labour it is usually shot down no matter how good it is. This can also happen due to lack of skill thereby requiring more time to realize the architecture by the team. Budget is always constrained in organizations, especially for new ventures. Architecture will be even more constrained when developers decide to code something quick and be able to handle the short term need. If the product becomes a hit, demand picks up and all the issues come to the fore.
If it is a web application, this model works perfectly fine as the initial budget is invariably small and nothing in the sense of a scalable, reliable architecture can be done. The broad outlines can be specified in terms of the components, interfaces, functions and then the plane takes off. If the product is a hit, more funds are available and scaling can be addressed at that time. Most of the time the users are also individuals and the fee collected per them is not significant to be precise in terms of delivering a fool-proof architectural answer.
However, if it is a enterprise application paid in millions by the customer and used by millions of people of the customer such as a telco application, then short-term solutions turn into nightmares later driving the project into a death spiral and ending up having a irated customer. Architecture in such a case should be given a serious thought. In this case, the cost of having a architectural underpinning is usually insignificant compared to the size of development. Or in other words the cost of architecture should not exceed 10% of the product development cost to give a rough idea. This I believe if executed correctly should give the benefit of reduced labour resulting in lesser cost of incremental development of the product and a quicker turnaround time in releasing new features.
It would be suicidal to go with a non-architecture approach for a large enterprise application. As the number of users increase, the size of data goes up, the rate of failures due to bugs, the predictability of performance and scaling comes to the fore without a sound architecture. Bad architecture always comes to haunt a product team at a later stage when the number of users increase. Citing cost or schedule pressures in avoiding architecture is not a sensible thing in this scenario as cost due to adhering to a architecture is always lesser when compared to the cost of an adhoc development and resulting rework.
A well thought out architecture results in the simplest and best way to address a problem. However, this means the problem should be correctly stated as much as possible. If this involves a cost, it is money well spent. The hassles of spending money on a imaginary problem is far worse. Often cost overruns happen due to incorrect perception of the problem and a improper answer. For example, a requirement that says the requests will hit the application at 10 TPS (transactions per second) if in reality is at 100 TPS, not having a Cache or a light weight framework in the architecture may cost the day for you.
There is no idealistic architecture. It evolves over time. Thus, it is important to spend money to refine the architectural thinking with prototyping. If multiple options can be tried quickly and the best technology or approach is identified, then it saves a lot of money.
No comments:
Post a Comment