Note that the information on this page is the BETA 1 of a guide that is now released. See for the latest PDF and HTML content.

Fast Track - A Guide for Getting Started and Applying the Guidance

- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat


This “fast track” chapter highlights the basic approach taken by this guide to help you design and architect layered applications across a variety of application types and architecture styles. Use this chapter to understand the basic approach, application types, architecture styles, the quality attributes that impact application design, and the key engineering decisions to consider when designing application architecture.


  • Understand the key components of this guide.
  • Learn about the exemplar layered application style.
  • Learn the steps you should follow when beginning your design.
  • Learn about the main application types and architectural styles.
  • Learn the quality attributes and understand the engineering hot-spots that are important when designing an application.

Architecture Meta Frame

The following schematic shows the main elements of this guide.


Use the architecture meta-frame to help you stay on track throughout this guide. The meta-frame contains the following key components:
  • Scenarios. Application scenarios tie architecture solutions to the real world scenarios that impact your application design. For example, your application may map to an Internet Web application scenario, which has unique architecture solutions compared to a mobile client application.
  • Quality Attributes. Quality attributes represent cross-cutting concerns that apply across application types, and should be considered regardless of architecture style. Security, performance, maintainability, and reusability are examples of quality attributes.
  • Requirements and Constraints. Requirements and constraints narrow the range of possible solutions for your application architecture problems.
  • Application Types. Application types categorize the major application technology stacks on the Microsoft platform. Examples of application types include Mobile, Rich Internet Application (RIA), Services Application, and Web Application.
  • Architecture Styles. An architectural style is a collection of principles that shapes the design of your application. Many of these styles overlap and can be used in combination. Architectural styles tend to be tied both to the application type as well as to the point in time in which the application was developed. Many applications are Component Based, while SOA is a more recent architectural style.
  • Architecture Frame. The architecture frame is a set of key concepts you can use to think about your application architecture. This helps you turn core features such as caching, data access, validation, and workflow into actions.

Reference Application Architecture

The following schematic shows the overall architecture of a typical application that uses the layered style to separate functional areas into separate layers.


Presentation Layer Components

  • User interface (UI) components. User interface components provide a way for users to interact with the application. They render and format data for users and acquire and validate data coming in from them.
  • User process components. To help synchronize and orchestrate these user interactions, it can be useful to drive the process using separate user process components. This means that the process flow and state management logic is not hard-coded in the user interface elements themselves, and the same basic user interaction patterns can be reused by multiple user interfaces.

Services Layer Components

  • Service Interfaces. Services expose a service interface to which all inbound messages are sent. The definition of the set of messages that must be exchanged with a service, in order for the service to perform a specific business task, constitutes a contract. You can think of a service interface as a façade that exposes the business logic implemented in the service to potential consumers.
  • Message Types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. For example, you might have a Command message, a Document message, or another type of message. These message types are the “message contracts” for communication between service consumers and providers.

Business Layer Components

  • Application Facade. (Optional). Use a façade to combine multiple business operations into a single messaged-based operation. You might access the application façade from the presentation layer using different communication technologies.
  • Business components. Business components implement the business logic of the application. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application will probably require components that implement business rules and perform business tasks.
  • Business workflows. After the required data is collected by a user process, the data can be used to perform a business process. Many business processes involve multiple steps that must be performed in the correct order and orchestrated. Business workflows define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools.
  • Business entity components: Business entities are used to pass data between components. The data represents real-world business entities, such as products and orders. The business entities used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order.

Data Layer Components

  • Data access logic components. Data access components abstract the logic necessary to access your underlying data stores. They centralize data access functionality, and make the process easier to configure and maintain.
  • Data helpers / utility components. Helper and utility components contain logic and functions that are used in several data layer components. This provides faster development, eases maintenance and promotes code reuse.
  • Service agents. When a business component must use functionality exposed by an external service, you may need to provide some code to manage the semantics of communicating with that service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services such as basic mapping between the format of the data exposed by the service and the format your application requires.

Approach for Application Architecture

The approach to architectural design can be divided into the following steps:
  1. Choose your application type. The application type you are designing will have a major impact on all of the other decisions you make. Deployment considerations for a Web application are different to those for a mobile application. Authentication techniques are different for a service and a rich client. Start by understanding your application type, and how that choice impacts your overall architecture.
  2. Choose your deployment topology. How you will deploy your application will shape your overall design. Will you be deploying a Web application on multiple tiers? Will you be deploying a RIA implementation over the Internet? Understand your logical and physical deployment in order to better understand your constraints and architectural requirements.
  3. Choose your architectural styles. The type of application you are designing, together with architectural goals and constraints, determine which architectural styles are a best fit. Will your design be based on SOA principles? Will you use an Enterprise Service Bus? Are you building an S+S or Peer-to-Peer application? The architectural styles described in this guide provide a set of principles that will make architectural decisions more cohesive and directed.
  4. Choose appropriate technologies. Choose technologies based on capabilities and patterns suited to your scenario.
  5. Determine how to address quality attributes. Consider how your design will address the common problems associated with each quality attribute. How will you design for availability, security, maintainability and reusability? Use the quality attributes guide to create a robust design that will stand the test of time.
  6. Determine how to address cross-cutting concerns. Walk the architecture frame and understand how each cross-cutting concern impacts your design. Consider architectural requirements for tasks such as caching, communication, data access, layering, and validation.

This approach will allow you to design a candidate architecture that can be reviewed, tested, and compared to your requirements and constraints. Do not get lost in the details; focus on the big steps and build a framework that you can use to develop the rest of your architecture and design.

Application Types

Your choice of application type will be related both to the technology constraints and the type of user experience you plan to deliver. Use scenarios to help you choose an application type. For example, if you want to support rich media and graphics delivered over the Internet, then a Rich Internet Application (RIA) is probably the best choice. However, if you want to support data entry with forms in an occasionally-connected scenario, then a Rich Client is probably the best choice. Use the table below to review and understand each application type.

Application Type Description
Mobile Application Can be developed as a Web application or a rich client application.
Can support occasionally-connected scenarios.
Runs on devices with limited hardware resources.
Rich Client Application Usually developed as a stand-alone application.
Can support disconnected or occasionally-connected scenarios.
Uses the processing and storage resources of the local machine.
Rich Internet Application Can support multiple platforms and browsers.
Can be deployed over the Internet.
Designed for rich media and graphical content.
Runs in the browser sandbox for maximum security.
Can use the processing and storage resources of the local machine.
Service Application Designed to support loose coupling between distributed components.
Service operations are called using XML-based messages.
Can be accessed from the local machine or remotely, depending on the transport protocol.
Web Application Can support multiple platforms and browsers.
Supports only connected scenarios.
Uses the processing and storage resources of the server.

Architectural Styles

Your choice of architectural styles will depend upon your application type, the requirements and constraints of your application, the scenarios you want to support, and - to some extent - the styles you are most familiar and comfortable with. Your choice of architectural styles represents a set of principles that your design will follow; an organizing set of ideas that you can use to keep your design cohesive and focused on your key objectives and scenarios. Use the table below to review and understand the key set of architectural styles.

Style Description
Client/Server Separates presentation processing on the client from data access and storage on the server. Business logic may be on the client, on the server, or in both places.
Composite Application An application created by composing multiple complementary building blocks. The building blocks might be existing components or services.
Enterprise Service Bus (ESB) ESB helps you to coordinate communication and translate messages sent between multiple Web services in an enterprise messaging system.
Grid A Web page structure based on CSS grids instead of columns and tables. This improves both the flexibility of your UI design and the visual appeal of your Web pages.
N-Tier Separates your logical layers onto separate physical tiers to improve modularity and scalability.
Peer-To-Peer Takes advantage of ad-hoc networking between multiple client computers to expand processing, storage or communication capacity.
Saas/S+S Software as a service is an application that runs in the cloud, relies on other services in the cloud, and may provide a service that other applications can consume. Software plus Services is an application that runs on the client but comes to life when connected to the cloud, offering capabilities that are not available when it is disconnected.
SOA Service-oriented architecture is a message based system composed of one or more applications that consume or expose Web services.

Quality Attributes

Use the quality attributes to focus your thinking around critical problems that your design should solve. Addressing quality attributes in your design rather than during development will improve the likelihood that your application will be successful in the long term. Use the table below to review and understand each quality attribute.

Category Description
Availability The application should be available and operating at all times specified in an SLA, and when users will expect to be able to access it. Availability includes both software and infrastructure concerns.
Conceptual Integrity The application should avoid concrete dependencies on other systems and applications where possible, and provide features that allow it and any data it holds to be upgraded, migrated, and refactored.
Flexibility The application should be configurable to allow use in varying environments and situations, and to cope with changes to business policies and rules.
Interoperability The application should interoperate with other associated applications, including sending and receiving data and using services. It should also continue to interoperate when other applications are refactored or upgraded.
Maintainability The application should be designed and constructed in such a way as to allow changes to components, services, features, and interfaces as may be required when adding or changing the functionality, fixing bugs, and meeting new business requirements.
Manageability The application should be easy to manage, by exposing sufficient and useful instrumentation for use in monitoring systems, and for debugging and performance tuning.
Performance The application should perform to requirements and expectations, making efficient use of resources and infrastructure.
Reliability The application should continue to work correctly, and work without interruption where possible, when encountering issues such as invalid input data, survivable infrastructure faults, varying network bandwidth and availability, and other external factors.
Reusability The components and services in the application should be designed in such a way as to be suitable for use in other applications and scenarios whenever possible, and to minimize duplication of components in the application.
Scalability The application should support increasing usage and load by working correctly when scaled up to more powerful hardware, and when scaled out in a Web or application farm.
Security The application must prevent access by unauthorized users, and protect data and resources from unauthorized users and all types of malicious activity.
Supportability The application must be easy for help desk staff and developers to provide support when it fails to work correctly, and be as intuitive as possible to minimize support requirements.
Testability The application must be designed in such a way that all individual components and entire subsystems can be testing using automated methods, test frameworks, and user-level testing.
Usability The application interfaces must be designed with the user and consumer in mind so that they are intuitive; can be localized and globalized; provide access to disabled users; and provide a good overall user experience.

Architecture Frame

The architecture frame is a collection of hot-spots that represent key engineering decisions. Each represents an opportunity to improve your design and build a technically more effective architecture. This architecture frame is part of the larger architecture meta-frame, and is used throughout the guide to organize key patterns, principles and practices. These categories help you to focus on the most important areas, and obtain the most meaningful and actionable guidance.


Use the table below to review and understand each category in the architecture frame.

Category Description
Authentication and Authorization Authentication and authorization allow you to identify the users of your application with confidence, and determine the resources and operations to which they should have access.
Caching and State Caching improves performance, reduces server roundtrips, and can be used to maintain the state of your application.
Communication Communication strategies determine how you will communicate between layers and tiers; including protocol, security and communication style decisions.
Composition Composition strategies determine how you manage component dependencies, and the interactions between components.
Concurrency and Transactions Concurrency is concerned with the way that your application handles conflicts caused by multiple users creating, reading, updating and deleting data at the same time. Transactions are used for important multi-step operations to treat them as though they were atomic, and recover in the case of a failure or error.
Configuration Management Configuration management defines how you configure your application after deployment, where you store configuration data, and how you protect configuration data.
Coupling and Cohesion Coupling and cohesion are strategies concerned with layering, separating application components and layers, and organizing your application trust and functionality boundaries.
Data Access Data access strategies describe techniques for abstracting and accessing data in your data store. This includes data entity design, error management, and managing database connections.
Exception Management Exception management strategies describe techniques for handling errors, logging errors for auditing purposes, and notifying users of error conditions.
Logging and Instrumentation Logging and instrumentation represents the strategies for logging key business events, security actions, and provision of an audit trail in the case of an attack or failure.
User Experience User experience is the interaction between your users and your application. A good user experience can improve the efficiency and effectiveness of the application, while a poor user experience may deter users from using an otherwise well-designed application.
Validation Validation is the means by which your application checks and verifies input from all sources before trusting and processing it. A good input and data validation strategy takes into account not only the source of the data, but also how the data will be used, when determining how to validate it.
Workflow Workflow is a system-assisted process that is divided into a series of execution steps, events, and conditions. The workflow may be an orchestration between a set of components and systems, or it may include human collaboration.

Key Engineering Decisions

Use the architecture frame as a way to organize and think about key engineering decisions. The following table shows key engineering decisions for each category in the architecture frame.

Category Key Problems
Authentication and Authorization How to store user identities.
How to authenticate callers.
How to authorize callers.
How to flow identity across layers and tiers
Caching and State How to choose effective caching strategies.
How to improve performance by using caching.
How to improve security by using caching.
How to improve availability by using caching.
How to keep cached data up to date.
How to determine when to use a custom cache.
How to determine the data to cache.
How to determine where to cache the data.
How to determine an expiration policy and scavenging mechanism.
How to load the cache data.
How to monitor a cache.
How to synchronize caches across a Web or application farm.
How to determine the caching technique that provides the best performance and scalability for a specific scenario and configuration
How to determine the caching technology that complies with the application's requirements for security, monitoring, and management.
Communication How to communicate between layers and tiers.
How to perform asynchronous communication.
How to communicate sensitive data.
Composition How to design for composition.
How to design loose coupling between modules.
How to handle dependencies in a loosely-coupled way.
Concurrency and Transactions How to handle concurrency between threads.
How to choose between optimistic and pessimistic concurrency.
How to handle distributed transactions.
How to handle long running transactions.
How to determine appropriate transaction isolation levels.
How to determine whether compensating transactions are required.
Configuration Management How to determine the information that must be configurable.
How to determine location and techniques for storing configuration information.
How to handle sensitive configuration information.
How to handle configuration information in a farm or cluster.
Coupling and Cohesion How to separate concerns.
How to structure the application.
How to choose an appropriate layering strategy.
How to establish boundaries.
Data Access How to manage database connections.
How to handle exceptions.
How to improve performance.
How to improve manageability.
How to handle binary large objects (BLOBs).
How to page records.
How to perform transactions.
Exception Management How to handle exceptions.
How to log exceptions.
Logging and Instrumentation How to determine the information to log.
How to make logging configurable.
User Experience How to improve task efficiency and effectiveness.
How to improve responsiveness.
How to improve user empowerment.
Validation How to determine location and techniques for validation.
How to validate for length, range, format, and type.
How to constrain and reject input.
How to sanitize output.
Workflow How to handle concurrency issues within a workflow.
How to handle task failure within a workflow.
How to orchestrate processes within a workflow.

Last edited Dec 16, 2008 at 8:11 AM by rboucher, version 4


No comments yet.