In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden mention periodic design refactoring:
A variant of the Incremental model appears to be the ‘Extreme Programing (XP)’ approach put forward in Beck (2000) in which integrity of the system architecture across all increments is maintained by periodic design ‘refactoring.’

While I’m not a fan of Big Design Up Front, I am a fan leveraging the following techniques up front to help reduce risk:

System stories up front (where system stories include the ‘ilities and quality attributes, such …

One of my favorite phrases is “incrementally render the solution.”   While building our end-to-end application solutions, I find it helpful to first create a skeleton and then hang the solution off of it.  Below is an example of solving an Intranet security scenario for an ASP.NET Web application.  Pictures are worth a 1000 words.
Scenario

On the patterns & practices team, to catalog app solutions, I use a simple “scenario and solution” approach.  My manager calls these “cartoons.”  The key is to create  a visual representation of what’s important — similar to a whiteboard sketch.  In fact, there was a point where we called these “whiteboard solutions.”  Below is an example of the skeleton of a solution for a common ASP.NET intranet scenario where users are in AD and the role store is in SQL Server.  Notice how lean the solution is (which makes it …

When I met with Gartner, I needed to illustrate how we were thinking about end-to-end application scenarios in patterns & practices.   In addition to explaining the idea of App Types and the App Infrastructure Frame, I illustrated how it was possible to quickly decompose an application scenario if you know how to break it down.  Below are some figures I used to help illustrate the ideas.
Scenario
This is how I analyze an end-to-end application scenario:

A former patterns & practices team member, Wojtek Kozaczynski, created some figures I liked.   He analyzed our Enterprise Library and Software Factories and created figures to show the usage scenarios that the solution assets are based on.
patterns & practices App Architecture
The following shows end-to-end architectures for a Web client and a Smart client:

As part of my preparation for writing a new application architecture guide, I’m analyzing our original patterns & practices Application Architecture Guide.  Below I show what I think is the most important blueprints from the original guide.
Application Architecture (Canonical)
This is the original patterns & practices application architecture:
 

If you build LOB (line-of-business) applications, you’re familiar with Web, Smart Clients, Mobile and Web Services applications.  In patterns & practices, we’ve organized programs around these application types to build more relevant, prescriptive guidance.  Here’s examples of the end-to-end application types. 
Web Application

Smart Client / Mobile

Web Service / Service

Note the following codes: UIC=User Interface Components, UPC=User Process Components, SA=Service Agent, SI=Service Interface, BE=Business Entity, BC=Business Component, DAC=Data Access Component.
My Related Posts

App Infrastructure Frame
App Types, Verticals, and Scenarios
Architecture Styles

When you build LOB (line-of-business) applications, there’s a recurring set of technical challenges  To organize this set of challenges, I created the Application Infrastructure Frame. 
App Infrastructure Frame

Key Categories
The App Infra Frame includes the following categories:

Authentication
Authorization
Caching
Data Access
Exception Management
Logging
Validation

As simple as it looks, I’ve found it helpful for analyzing applications.  If you’re familiar with patterns & practices Enterprise Library, you’ll notice that the application blocks in Enterprise Library map to the Application Infrastructure Frame.

I’ve been looking for examples of how to organize software architecture styles.    One book that looks promising so far is Software Architecture Design - Methodology and Styles.  In this book, the authors identify the following architecture styles:

Component-Based Software Architecture
Data Centered Software Architecture
Data Flow Architecture
Distributed Architecture
Hierarchy Architecture
Implicit Asynchronous Communication Software Architecture
Interaction Oriented Software Architecture
Object Oriented Architecture

I found an organizing frame for quality attributes (security, performance, … etc.) on SoftwareArchitectures.com and I think it’s helpful.  They organize quality attributes by the following:

Runtime system qualities
Non-runtime system qualities
Business qualities
Architecture qualities
Domain specific qualities.

Quality Attribute Frame
This table shows an example of some quality attributes organized by the Quality Attribute Frame

My Related Posts

Quality Attribute List

When thinking about quality, I tend to draw from the following quality attributes:

Availability
Buildability
Conceptual Integrity
Evolvability
Extensibility
Functionality
Implementation Transparency
Integrability
Interoperability
Maintainability
Performance
Portability
Reliability
Reusability
Scalability
Security
Serviceability
Subsetability
Supportability
Testability
Usability

I think application  types, verticals, and scenarios are a helpful backdrop for product-line engineering.  You can use it to organize policies and requirements.  It’s a way to increase precision.  For example, it’s one thing to build a Web application.  It’s another to build a Web application for a financial institution.  How you implement security, performance, and other quality attributes has a lot to do with the application type and the scenario or context you are in.
App Types, Veriticals and Scenarios Conceptual Framework
Here’s a simple model I use when I think …

I find it’s always helpful to think in terms of user, business and tech.  For example, whenever I see a product design or requirements, I walk through the user perspective, the business perspective and the technical perspective.  A lot of times, the business or technical perspective ends up winning because the customer didn’t have a voice.  Mistakes like that give software a bad rap.  After all, the software is for the user, isn’t it.   If your software doesn’t make the user more effective and more efficient, or worse, makes them …

In any significant software project, complexity happens.  The question is what are you going to do about it?    In Software Architect Bootcamp (2nd Edition), Ralphael Malveau and Thomas J. Mowbray, Ph.D. write about five ways of dealing with software complexity.
Why Complexity Happens
Malveau and Mowbray write the following:
Many software projects fail to manage complexity because they do not consider control of complexity to be part of architecture.  System-level design details are often delegated to multiple developers, who readily produce unique, uncoordinated designs.  Other projects inherit excess complexity from the architecture of  …

When you zoom in or zoom out of a software system, what do you call the different levels of the software?  Design levels are a key issue for architecture because they define the problems and forces that the architecture needs to solve.    In Software Architect Bootcamp (2nd Edition), Ralphael Malveau and Thomas J. Mowbray, Ph.D. write about different models for software design levels.
Machine, Code and Architecture
Shaw and Garlan [Shaw 1996] proposed a three-level model for software design levels:

Machine
Code
Architecture

Malveau and Mowbray write the following:
The machine level comprises unmodifiable binary software, …

Why do we need software architects?  In the book Software Architect Bootcamp (2nd Edition), Raphael Malveau and Thomas J. Mowbray, Ph.D. write about three key reasons why we need software architects.
Separate Complex Concerns
Malvaeau and Mowbray write the following:
First, architects need the ability to separate complex concerns, in particular to separate concerns about business-application functionality, from concerns about distributed-system complexity. … By separating concerns, developers can focus on the business functionality that is the true purpose of the information system.

Future-Proof the Information Systems
Malvaeau and Mowbray write the following:
Software architects also need …