InfoQ Homepage Minimum Viable Architecture Content on InfoQ
-
/articles/three-questions-better-architecture/en/smallimage/Three-Questions-That-Help-You-Build-a-Better-Software-Architecture-thumb-image-1760608737355.jpg)
Three Questions That Help You Build a Better Software Architecture
To architect effectively for an MVP, teams must answer three questions in order: Is the business idea worth pursuing? What performance and scalability are needed? How much maintainability and supportability are required? These guide Minimum Viable Architecture decisions. Empirical testing helps reject costly assumptions early and adapt architecture as the MVP evolves.
-
/articles/architecting-mvp-AI/en/smallimage/architecting-mvp-AI-thumbnail-1752567203613.jpg)
Architecting the MVP in the Age of AI
AI enhances software architecture by informing decisions, suggesting alternatives, and streamlining documentation. While it can’t replace human judgment, it accelerates MVP development and supports experimentation, trade-off analysis, and technical debt management when provided with sufficient context.
-
/articles/mvp-dilemma/en/smallimage/mvp-dilemma-thumbnail-1748330492438.jpg)
The MVP Dilemma: Scale Now or Scale Later?
Scaling a system is a hard problem to solve. Underinvesting in scalability leads to a shortened lifespan for the system, but overinvesting can kill the MVP business case because of cost.
-
/articles/architectural-experimentation-faq/en/smallimage/architectural-experimentation-faq-thumbnail-1743578735799.jpg)
Architectural Experimentation in Practice: Frequently Asked Questions
This third article in a series answers some frequently asked questions about architectural experiments. Architectural experiments test critical decisions to reduce risks and costs, using well-defined hypotheses and results for clarity. They are structured, not unfocused, exploratory learning.
-
/articles/architectural-experimentation-insurance/en/smallimage/architectural-experimentation-thumbnail-1740472356165.jpg)
If Architectural Experimentation Is So Great, Why Aren’t You Doing It?
Architectural experimentation sounds like a great idea, yet it does not seem to be used very frequently. In this article, we will explore some of the reasons why teams don’t use this powerful tool more often, and what they can do about leveraging that tool for successful outcomes.
-
/articles/architecture-experimentation/en/smallimage/software-architecture-logo-small-1734346008461.jpg)
Software Architecture and the Art of Experimentation
Run experiments using a Minimum Viable Architecture approach to determine if your architecture decisions are on the right track. MVAs also test the viability of an MVP, allowing stakeholders to validate the business value.
-
/articles/mva-dilemma-experiments/en/smallimage/to-dare-or-not-logo-small-1730966342573.jpg)
To Dare or Not to Dare: the MVA Dilemma
Teams developing new products must decide between relying on tried-and-true technologies that may not be suitable for new situations or exploring new and unfamiliar technologies that may be a better fit but introduce unforeseen challenges.
-
/articles/technical-debt-your-friend/en/smallimage/how-to-make-tehnical-debt-small-logo-1725015085842.jpg)
How to Make Technical Debt Your Friend
Technical debt is a popular metaphor for communicating the long-term implications of architectural decisions and trade-offs to stakeholders. By exploiting the feedback mechanism of the Minimum Viable Architecture (MVA) approach, we have concluded that the technical debt metaphor is misleading because much of the so-called debt never needs to be, and in fact isn’t, repaid.
-
/articles/architectural-retrospectives/en/smallimage/architectural-retrospectives-the-key-to-getting-better-at-architecting-logo-small-1722352645680.jpg)
Architectural Retrospectives: the Key to Getting Better at Architecting
The purpose of an architectural retrospective is to use experience to help the development team improve their architecting skills and their way of working as they make architectural decisions. This is different than traditional architecture reviews which are focused on improving the architecture.
-
/articles/trade-offs-minimizing-unhappiness/en/smallimage/GettyImages-1307309102-small-1717160046764.jpg)
Architectural Trade-Offs: the Art of Minimizing Unhappiness
To architect is to be a frustrated perfectionist; a good architecture minimizes this unhappiness by making trade-offs that can be lived with. The main skill in architecting is making trade-offs. These trade-offs reflect the most important and difficult decisions a team will make about its architecture.
-
/articles/nine-steps-agile-architecture/en/smallimage/9-steps-toward-an-agile-architecture-small-1714483551165.jpg)
9 Steps towards an Agile Architecture
Just as a Minimum-Viable Architecture (MVA) approach does not create a system’s architecture in a single step, adopting an MVA approach takes a series of incremental steps as well. These organizational changes start with a single development team and use feedback to evolve the process as more teams are brought in.
-
/articles/agile-lean-architecture/en/smallimage/agile-architecture-lean-architecture-or-both-small-1709730369663.jpg)
Agile Architecture, Lean Architecture, or Both?
When it comes to software architecture, should you adopt an agile or a lean approach? The answer, of course, is "it depends." Agile is better suited for situations where you know what you need, but not how to build it. Lean is more appropriate when requirements are certain and you want to optimize a well-known process.