A Technique for Architecture and Design

The steps, described in more detail in the following sections, are:  

1. Identify Architecture Objectives.
   Clear objectives help you to focus on your architecture and on solving the right problems in your design. Precise objectives help you to determine when you have completed the current phase, and when you are ready to move to the next phase.
2. Key Scenarios.
   Use key scenarios to focus your design on what matters most, and to evaluate your candidate architectures when they are ready.
3. Application Overview.
   Identify your application type, deployment architecture, architecture styles, and technologies in order to connect your design to the real world in which the application will operate.
4. Key Issues.
   Identify key issues based on quality attributes and crosscutting concerns. These are the areas where mistakes are most often made when designing an application.
   
   
5. Candidate Solutions.
   Create an architecture spike or prototype that evolves and improves the solution and evaluate it against your key scenarios, issues, and deployment constraints before beginning the next iteration of your architecture. This architectural process is meant to be an iterative and incremental approach

When taking an iterative approach to architecture, it is often tempting to iterate on horizontal slices (layers) of the application rather than vertical slices that require you to think about functionality across layers that comprise a complete feature (use case) for users. If you fail to iterate vertically, you run the risk of implementing a great deal of functionality before your users can validate it.

You should not try to build your architecture in a single iteration. Each iteration should add more detail. Do not get lost in the details, but instead focus on the major steps and build a framework on which you can base your architecture and design.

Identify Architecture Objectives
Architecture objectives are the goals and constraints that shape your architecture and design process, scope the exercise, and help you determine when you are finished. Consider the following key points as you identify your architecture objectives:

• Identify your architecture goals at the start.   
  The amount of time you spend in each phase of architecture and design will depend on these goals. For example, are you building a prototype, testing potential paths, or embarking on a long-running architectural process for a new application?
• Identify who will consume your architecture.
  Determine if your design will be used by other architects, or made available to developers and testers, operations staff, and management. Consider the needs and experience of your audience to make your resulting design more accessible to them.
• Identify your constraints.
  Understand your technology options and constraints, usage constraints, and deployment constraints. Understand your constraints  at the start so that you do not waste time or encounter surprises later in your application development process. 

Based on the high-level goals for your architecture, you can scope the amount of time
to spend on each of your design activities

• Creating a complete application design.
• Building a prototype.
• Identifying key technical risks.
• Testing potential options.
• Building shared models to gain an understanding of the system.

Application Overview

Create an overview of what your application will look like when it is complete. This overview serves to make your architecture more tangible, connecting it to real-world constraints and decisions. An application overview consists of the following activities:

1. Determine your application type.
   First, determine what type of application you are building. Is it a mobile application, a rich client, a rich Internet application, a service, a Web application, or some combination of these types?
2.  Identify your deployment constraints.When you design your application architecture, you must take into account corporate policies and procedures, together with the infrastructure on which you plan to deploy your application. If the target environment is fixed or inflexible, your application design must reflect restrictions that exist in that environment. Your application design must also take into account Quality-of-Service (QoS) attributes such as security and reliability. Sometimes you must make design tradeoffs due to protocol restrictions and network topologies. By identifying the requirements and constraints that exist between the application architecture and infrastructure architecture early in the design process, you can choose an appropriate deployment topology and resolve conflicts between the application and the target infrastructure.
3. Identify important architecture design styles.
   Determine which architecture styles you will be using in your design. An architecture style is a set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. Each style defines a set of rules that specify the kinds of components you can use to assemble a system, the kinds of relationships used in their assembly, constraints on the way they are assembled, and assumptions about the meaning of how you put them together. An architecture style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. Common architectural styles are Service Oriented Architecture (SOA), client/server, layered, message-bus, and domain-driven design. Applications will often use a combination of styles.
4.  Determine relevant technologies.
   Finally, identify the relevant technology choices based on your application type and other constraints, and determine which technologies you will use in your design. Key factors to consider are the type of application you are developing, and your preferred options for application deployment topology and architectural styles. The choice of technologies will also be governed by organization policies, infrastructure limitations, resource skills, and so on. The following section describes some of the common Microsoft technologies for each type of application.

• Whiteboard Your Architecture
  It is important that you are able to whiteboard your architecture. Whether you share your whiteboard on paper, slides, or through another format, the key is to show the major constraints and decisions in order to frame and start conversations. The value is actually twofold. If you cannot whiteboard the architecture then it suggests that it is not well understood. If you can provide a clear and concise whiteboard diagram, others will understand it and you can communicate details to them more easily.

Key Issues

Identify the issues in your application architecture to understand the areas where mistakes are most likely to be made


Quality Attributes
Quality attributes are the overall features of your architecture that affect run-time behavior, system design, and user experience. The extent to which the application possesses a desired combination of quality attributes such as usability, performance, reliability, and security indicates the success of the design and the overall quality of the software application

Quality attributes represent areas of concern that have the potential for applicationwide impact across layers and tiers. Some attributes are related to the overall system design, while others are specific to run-time, design-time, or user-centric issues

• System qualities.
  The overall qualities of the system when considered as a whole; such as supportability and testability.
• Run-time qualities.   
  The qualities of the system directly expressed at run-time; such as availability, interoperability, manageability, performance, reliability, scalability, and security.
   
• Design qualities.   
  The qualities reflecting the design of the system; such as conceptual integrity, flexibility, maintainability, and reusability.
• User qualities.
  The usability of the system.

Crosscutting Concerns 

Crosscutting concerns are the features of your design that may apply across all layers, components, and tiers. These are also the areas in which high-impact design mistakes are most often made. Examples of crosscutting concerns are:

• Authentication and Authorization.   
  How you choose appropriate authentication and authorization strategies, flow identity across layers and tiers, and store user identities.
   
• Caching.   
  How you choose an appropriate caching technology, determine what data to cache, where to cache the data, and a suitable expiration policy.
   
• Communication.    How you choose appropriate protocols for communication across layers and tiers, design loose coupling across layers, perform asynchronous communication, and pass sensitive data.
   
• Configuration Management.
  How you determine what information must be configurable, where and how to store configuration information, how to protect sensitive configuration information, and how to handle configuration information in a farm or cluster.
   
• Exception Management.
  How you handle and log exceptions, and provide notification when required.
   
• Logging and Instrumentation.
  How you determine which information to log, how to make the logging configurable, and determine what level of instrumentation is required.
   
• Validation.
  How you determine where and how to perform validation; the techniques you choose for validating on length, range, format, and type; how you constrain and reject input invalid values; how you sanitize potentially malicious or dangerous input; and how you can define and reuse validation logic across your application’s layers and tiers.

Designing for Issue Mitigation

By analyzing quality attributes and crosscutting concerns in relation to your design requirements, you can focus on specific areas of concern. For example, the quality attribute Security is obviously a vital factor in your design, and applies at many levels and areas of the architecture. The relevant crosscutting concerns for security provide guidance on specific areas where you should focus your attention. You can use the individual crosscutting categories to divide your application architecture for further analysis, and to help you identify application vulnerabilities. This approach leads to a design that optimizes security aspects. Questions you might consider when examining the crosscutting concerns for security are:

• Auditing and Logging. Who did what and when? Is the application operating normally? Auditing refers to how your application records security-related events. Logging refers to how your application publishes information about its operation.

• Authentication. Who are you? Authentication is the process where one entity definitively establishes the identity of another entity, typically with credentials such as a username and password.
  
• Authorization. What can you do? Authorization refers to how your application controls access to resources and operations.

• Configuration Management. What context does your application run under? Which databases does it connect to? How is your application administered? How are these settings protected? Configuration management refers to how your application handles these operations and issues.
• Cryptography. How are you handling secrets (confidentiality)? How are you tamper-proofing your data or libraries (integrity)? How are seeding random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.
• Exception Management. When a method call in your application fails, what does your application do? How much information does it reveal? Does it return friendly error messages to end users? Does it pass valuable exception information back to the calling code? Does it fail gracefully? Does it help administrators to perform root cause analysis of the fault? Exception management refers to how you handle exceptions within your application.
   
• Input and Data Validation. How do you know that the input your application receives is valid and safe? Does it constrain input through entry points and encode output through exit points. Can it trust data sources such as databases and file shares? Input validation refers to how your application filters, scrubs, or rejects input before additional processing.
   
• Sensitive data. How does your application handle sensitive data? Does it protect confidential user and application data? Sensitive data refers to how your application handles any data that must be protected either in memory, over the network, or in persistent stores.
  
• Session Management. How does your application handle and protect user sessions? A session refers to a set of related interactions between a user and your application. 

You can use these questions and answers to make key security design decisions
for your application, and document these are part of your architecture. i.e

Candidate Solutions

After you define the key issues, you can create your initial baseline architecture
and then start to fill in the details to produce a candidate architecture. Along the
way, you may use architectural spikes to explore specific areas of the design or to
validate new concepts. You then validate your new candidate architecture against
the key scenarios and requirements you have defined, before iteratively following the
cycle and improving the design.

Architectural Spikes

An architectural spike is a test implementation of a small part of the application’s
overall design or architecture. The purpose is to analyze a technical aspect of a
specific piece of the solution in order to validate technical assumptions, choose
between potential designs and implementation strategies, or sometimes to estimate
implementation timescales.