InfoQ Homepage Continuous Architecture Content on InfoQ
Articles
RSS Feed-
/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/mva-distributed/en/smallimage/logo-1663312791288.jpg)
Location, Location, Location: MVA Considerations for Distributed Processing and Data
Even when designing a Minimum Viable Architecture (MVA), developers must consider resource location, especially when mobile apps are part of a distributed system. Distributing the data and processing can introduce new challenges if location is not part of the decision-making criteria.
-
/articles/continous-architecture-article-series/en/smallimage/continuous-architecture-article-series-logo-small-1655735648162.jpg)
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.
-
/articles/mvp-mva-legacy/en/smallimage/logo-1660735098327.jpg)
Chipping Away at the Monolith: Applying MVPs and MVAs to Legacy Applications
Legacy applications actually benefit the most from concepts like a Minimum Viable Product (MVP) and its related Minimum Viable Architecture (MVA). Once you realize that every release is an experiment in value in which the release either improves the value that customers experience or doesn’t, you realize that every release, even one of a legacy application, can be thought of in terms of an MVP.
-
/articles/frameworks-require-decisions/en/smallimage/logo-1658153002709.jpg)
Architectural Frameworks, Patterns, and Tactics Are No Substitute for Making Your Own Decisions
Software frameworks greatly amplify a team’s productivity, but also make implicit decisions. The benefits and limitations must be understood because of the impact on the resulting system architecture.
-
/articles/minimum-viable-architecture-sample/en/smallimage/minimum-viable-architecture-in-practice-small-image-1656333586692.jpg)
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.
-
/articles/minimum-viable-architecture/en/smallimage/logo-1654507242099.jpg)
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.
-
/articles/care-about-architecture/en/smallimage/why-you-should-care-about-software-architecture-small-image-1656333219109.jpg)
Why You Should Care about Software Architecture
Software development teams have resisted "big upfront designs" in favor of architectural designs emerging from self-organizing teams, which can lead to a mindset that software architecture is not really that important. Greater awareness of the implicit decisions they are making, and forcing these decisions to be made explicitly, can help development teams make better, more informed decisions.
-
/articles/what-software-architecture/en/smallimage/logo-1649414695292.jpg)
Software Architecture: It Might Not Be What You Think It Is
Software architecture is often a misunderstood idea. Unlike traditional architecture, where the design is separated from construction, in software how something is built influences what is built, and vice versa. Software architecture is about decisions, not structure. Architecting is a skill, and architect should not be a role.