My Architecture Journal article is live, A Language for Architecture.   I wrote the article to share the map of application architecture we created during our patterns & practices Application Architecture Guide 2.0 project.  It's a simple language for helping you get in the ballpark when you're traversing the very large space of software architecture.   By framing and naming the space, we can more effectively share our principles, patterns, and practices for application architecture.   This also helps consolidate all the great information spread over time and space and threads and heads.   More importantly, if we simplify how we talk about architecture, we can move up the stack as well as pave paths for others and help mentor others in our field.  Instead of asking basic questions like what is architecture, we can ask things like how do we define archetypes for the cloud or how do improve product line engineering for common systems and application types? In our case, we're using the language to help rationalize our portfolio of assets in our patterns & practices product line.

Why the Map
There's an explosion of concepts in the architecture space.  While working on the Application Architecture 2.0 Guide, we needed a simple, but effective bird's-eye view of the space.  By framing and naming the space, we created a shared vocabulary, helped avoid information overload, and made it easier to find, organize, and share principles, patterns, and practices with customers, field, and product teams.  It's good for the ecosystem.

Usage Scenarios
Here's some usage scenarios:

• Heat Map.  If you do product planning or competitive analysis you can use the map and language to create heat maps and create a "consumer reports" for the space you are in.  You can identify key hot spots and quickly drill in or evaluate the level of maturity in that domain.  You can use the map to find the most important areas to invest.  That's key, especially in today's economic landscape.
• Hot Spots.   By mapping out hot spots you build a catalog of your key engineering decisions.  These become your focus points.  By focusing efforts you improve your results.  For example, if cloud computing is a hot spot, you might identify manageability within that and then you might invest your energy in reducing friction or creating opportunity in that hot spot.
• Solution Engineering.   If you build applications you can use the map and language for quickly traversing key engineering decisions.  You can use it to quickly identify your key risks as well as explore potential solution options.  It helps you identify what you know, don't know and need to know next.  It also helps you quickly rip through technology decisions.
• Architectural Exploration.   You can use the map as a way to explore existing systems.  By chunking up architectures into things like archetypes, qualities, hot spots ... etc. you can drill into them more effectively.  For example, you might go on an architectural expedition to build a catalog of common application patterns for your group.
• Whiteboarding.   Effective whiteboarding is an art.  That said, whiteboarding is one of the most important tools in our industry when it comes to sharing knowledge and getting people on the same page.   You can use the language, maps, and frames to improve your whiteboarding skills by using common elements from the map.
• Product-line engineering.  If you build software, you can use the map to get more precision over your product line by defining the scenarios, the requirements, the archetypes and hot spots.  You can also use these to differentiate.
• Slideware.  If you have to build slides, you can use the map, the language, and the visuals to more effectively share what's important.
• Prescriptive Guidance.   If you're in the decision improvement business, then using a common map and frames will help you organize and share patterns and practices more effectively.  What if we could easily traverse the common data access patterns for RIA applications from a security, performance or manageability perspective?  We get closer to the capability when we share common maps.

Key Concepts
Here's some key concepts behind the map and language:

• Hot Spot driven.  Rather than exhaustive, the maps, language, and frames are hot spot driven.  If you can see the forest from the trees, you have a better vantage point and can more selectively drill down or elaborate as needed.   Hot spots are also where the action is.  See Security Hot Spots and Performance Hot Spots.
• Expandable by design.  The maps are expandable by design.   You can unfold, elaborate or expand each area as needed.   You can tailor it for your context.  The maps gives you a baseline of hot spots to start from so you don't have to start from scratch.
• Overlays.   The maps, language, and frames are backdrops.  This means we can overlay principles, patterns, and practices.  This also means we can overlay products or technologies or solution assets, such as reusable code.
• Whiteboard oriented.    The maps, language and frames are oriented towards whiteboard usage, simply because it's one of the most universal tools in our field.  By optimizing around whiteboard usage and humans over tools, we reduce friction around sharing basic information.
• Plays well with others.   No matter what your favorite framework or mental models are, you can leverage the maps, language and frames.  We didn't set out to build an exclusive set.  Instead, we set out to map out an inclusive set of concepts that can easily stretch to fit.  It's platform agnostic and if anything, it's most tightly bound to the knowledge areas of software architecture.  In the words of Bruce Lee, "absorb what is useful."
• Real-world over academic.   We chose to optimize around the language, maps, and frames we see in practice.  We needed it to be simple to explain whether we're in a team full of developers or a doing a presentation for business decision makers.  It's a simple way to look at the legos and  organize them in a meaningful way.

The Map
The key components of the language include:

• User, Business, and System Perspective.   Architecture is a constant balance of user, business, and technical concerns.  For example, the user wants a response time of x, but the cost and impact on the system side have to make business sense.  When you group by user, business, and system stories you get more precision around the drivers and goals and you can include the right people for the right decisions, as well as keep checks and balances.  See What are the User, Business, and System Goals.
• Architecture Frame.  This is the main map that includes the context, the app types, the architectural styles, and the application feature frame.  The context is expressed with scenarios, requirements / constraints, and quality attributes.
• Application Archetypes (App Types).  Application Types are simply blueprints for classes of applications.  In our Application Architecture Guide 2.0, we called out mobile, RIA, Web, Rich Client, and Services.  Those are technical types.  You could also call out a set of business types. or a set of core system archetypes.  The key is to identify a set of types for your business so you can think in terms of a product-line.  See Application Types.
• Quality Attributes.   This includes system, run-time, design, and user qualities.  For example, a run-time quality would be availability, while a design quality would be conceptual integrity.  See Quality Attribute List.
• Scenarios.  You can't design or evaluate an architecture in a vacuum.  Scenarios give you the context.  The scenarios are a really important element.  In terms of architecture, the architecturally significant use cases are vital to making the right trade-offs.  You can find architecturally significant scenarios by looking at the intersections of quality attributes or hot spots with application features.  See App Types, Verticals, and Scenarios and What's a Scenario?.
• Architectural Styles.  Architectural styles are simply sets of principles that shape the software.  We grouped styles by  big decision areas: communication, deployment, domain, interaction and structure.The beauty of architectural styles is we can talk about higher-level goals before getting into specific technologies.  For example, if you choose SOA as your architectural style for your communication, you can then evaluate whether WCF or ASMX helps you implement those principles.  Every app is a mash up of styles. 
• Requirements and Constraints.   Requirements and constraints are simply what's required of the system.  Again, this is where user, business, and system perspectives matter.  We called out functional, non-functional, technological, and constraints.  Non-functional would include quality attributes and constraints would include organizational and industry compliance.  See Requirements Types and  User Requirements vs. System Requirements.
• Application Feature Frame.   This is a set of hot spots focused on a common set of key engineering decisions.  We called out Caching, Communication, Concurrency and Transactions, Configuration Management, Coupling and Cohesion
  Data Access, Exception Management, Layering, Logging and Instrumentation, State Management, Structure, Validation, and Workflow.  These are  the types of decisions you don't want to make up on the fly and you want to avoid do-overs.  You'll also notice our industry is rich with principles, patterns, and practices in these categories, as well as reusable components.  For example, you can overlay Enterprise Library on several of these areas.   See Application Infrastructure Frame.
• Application Frames.   These are hot spots based on a given application type.  For example, for Web applications, we defined Authentication, Authorization, Caching, Exception Management, Logging and Instrumentation, Navigation, Page Layout (UI), Page Rendering, Presentation Entity, Request Processing, Service Interface, Session Management, Validation.  Notice that the map has a lot of similar categories to the core application infrastructure frame.  The key is context.  Now we are talking about validation within Web applications.  Also notice that some hot spots are more Web centric such as page layout and page navigation.  Also notice that we can overlay key Web patterns on these hot spots.  Instead of a laundry list of patterns, we can find, organize, and share key patterns for these hot spots.
• Layers, Components, and Tiers.  We called out layers, components, and tiers so that we could have a common backdrop with the various existing bodies of work.   We kept layers logical and tiers physical (a precedent set back in 2001 to help untangle confusion.)  We called out the presentation, business, data, and service layers.  You can extend that for things like productivity layers or manageability layers.  Keep in mind that layers are fractal, in other words you might have a service that has a presentation, business, and data layer within it.  Effectively you can think in terms of macro and micro levels.  For components we called out presentation components (user interface, user process), business components (application facade, business, business entity, business workflows), data layer components (data access logic, data helpers/utilities, service agents), and service layer components (service interfaces, message types).  For tiers, we called out 2-tier, 3-tier, and N-tier.
• Pattern Maps.  We created pattern maps based on the frames.  For example, for each application type (Web, RIA, Mobile ... etc.) we used the hot spots to overlay relevant patterns.  This helped us surface up the most important patterns for a given topic and avoid information overload.
• Product and Technology Maps.   We created product and technology maps organized by scenarios, application types, and hot spots.  The key here was making it easy to traverse the problem space and overlay the solution space.