InfoQ Homepage Minimum Viable Architecture Content on InfoQ
Articles
RSS Feed-
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.
-
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.
-
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.
-
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.
-
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.
-
How Much Architecture Is “Enough?”: Balancing the MVP and MVA Helps You Make Better Decisions
The Minimum Viable Architecture (MVA) is the architectural complement to a Minimum Viable Product (MVP). The MVA and MVP must evolve together for a product to be successful. As new features are delivered to customers, corresponding incremental improvements need to be made in the architecture. Also, the architecture should not get too far ahead of what is needed for the product.
-
Enhancing Your "Definition of Done" Can Improve Your Minimum Viable Architecture
A Definition of Done describes the criteria that determines whether a software product is releasable. While normally focused on functional aspects of quality, teams can strengthen the quality and sustainability of their products if they expand their DoD to include architectural considerations.
-
Article Series: Continuous Architecture
In this series of articles, the authors reframe software architecture in terms of decisions that teams make about how their system will handle its quality attribute requirements (QARs). In their view, software architecture, reframed in terms of decisions, completes the picture of how the system works by making clear the choices that the team has made, and why.
-
Minimum Viable Architecture in Practice: Creating a Home Insurance Chatbot
Even a simple application, like the one described in this article, needs a minimum viable product (MVP) and a minimum viable architecture (MVA). This is the second article in a series on MVA.
-
A Minimum Viable Product Needs a Minimum Viable Architecture
Creating a Minimum Viable Architecture as part of an MVP helps teams to evaluate the technical viability and to provide a stable foundation for the product that can be adapted as the product evolves.