If Architectural Experimentation Is So Great, Why Aren't You Doing It?

The article discusses the challenges of implementing architectural experiments in software development, despite their clear benefits. Stakeholders often view such experiments as unnecessary and prefer not to allocate resources to them. However, the long-term savings from better decision-making and reduced rework justify these experiments. Moreover, it highlights the critical differences between architectural experiments and Proofs of Concept, emphasizing their unique roles in validating solutions. The article also addresses the potential need for real-world conditions in testing, along with strategies for mitigating risks when conducting these experiments.

Selling yourself and your stakeholders on doing architectural experiments is hard, despite the significant benefits of this approach; you like to think that your decisions are good but when it comes to architecture, you don't know what you don't know.

These better decisions also reduce the overall amount of work you need to do by reducing costly rework.

Architectural experiments and POCs have different purposes. A POC helps validate that a business opportunity is worth pursuing, while an architectural experiment tests some parts of the solution to validate that it will support business goals.

Sometimes, architectural experiments need to be run in the customer's environment because there is no way to simulate real-world conditions.

Read at InfoQ