This project is read-only.

How To - Design Using Agile Architecture

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


  • Learn the steps to designing a suitable architecture for your application.
  • Learn about the ways you can view your design and check that it is on track.


This how to will help you start the process of designing your application. It discusses the six main steps you should follow, and then discusses the issues involved in making logical choices. It also provides checklists to help you ensure that the proposed design will meet your requirements.


The following input is useful for designing your architecture:
  • Use cases and usage scenarios
  • Functional requirements
  • Non-functional requirements (quality attributes such as performance, security, and reliability)
  • Technological requirements
  • Target deployment environment
  • Constraints


The design should produce the following types of output:
  • Architecturally significant use cases
  • Architecture hot spots
  • Candidate architectures
  • Architectural spikes


Figure 1 shows the five major steps for designing your architecture.


Figure 1: Core Architecture Design Activities

These steps are:
  • Step 1. Identify Architecture Objectives. Clear objectives help you to focus your architecture, and will help you focus on solving the right problems in your design. Good objectives help you to determine when you are finished, and when you are ready to move to the next phase.
  • Step 2. Key Scenarios. Use key scenarios to focus your design on what matters most, and to evaluate your candidate architectures when they are ready.
  • Step 3. Application Overview. Understand your application type, deployment architecture, architectural styles, and technologies in order to connect your design to the real world in which the application will have to operate.
  • Step 4. Key Hot Spots. Identify key hotspots based on quality attributes and the architecture frame. These are the areas where mistakes are most often made when designing an application.
  • Step 5. Candidate Solutions. Create a candidate architecture or architectural spike and evaluate it against your key scenarios, hot spots, and deployment constraints.

You can iteratively flesh out your architecture as you work through your design and discover more details that impact your architecture. Do not try to build your architecture in a single iteration. Do not get lost in the details; focus on the big steps and build a framework on which you can base your architecture and design.

Step 1 – Identify Architecture Objectives

Architecture objectives are the goals and constraints that shape your architecture and design process, scope the exercise, and help you to determine when you are finished. Consider the following key points as you identify your architecture objectives:
  • Understand 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?
  • Understand who will consume your architecture. Determine if your architecture will be used by other architects, by developers and testers, by operations staff, or by management. Consider the needs of your audience to make your architecture more successful and impactful.
  • Understand your constraints. Determine your technology 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.

Step 2 – Key Scenarios

Key scenarios consist of the most important scenarios for the success of your application, as well as the architecturally significant use cases.

Important scenarios are those that meet the following criteria:
  1. They are business-critical, have a high usage level compared to other features, or imply high technical or technological risk.
  2. They intersect with both functionality and quality attributes, or are cross cutting concerns. An example may be a CRUD operation that is security sensitive.
  3. They are the scenarios that matter the most, cut across the layers and tiers of the application, or have an end-to-end impact on the application.

Architecturally significant use cases are those that meet the following criteria:
  1. They are important for the success and acceptance of the deployed application.
  2. They exercise enough of the design to be useful in evaluating the architecture.

It is important to recognize the difference between system scenarios and user scenarios:
  • System scenarios are those that have an impact mainly on the internal operations of the application and infrastructure. Examples are message communication between layers, connecting to data stores, and performing validation.
  • User scenarios are those initiated by or controlled by the user. Examples are (depending on the type of application)_tasks such as creating an order, viewing a product, or updating a customer record.

Examples of architecturally significant use cases are:
  • Placing an order in an online store application and receiving a response that indicates the order was accepted.
  • Updating a product record in a stock management application, which automatically updates all linked records and information such as price lists.
  • Searching for and displaying details of a specific customer in a CRM application.

Step 3 – Application Overview

Build an overview of what your application will look like when it is complete. The application overview serves to make your architecture more real, connecting it to real-world constraints and decisions. An application overview consists of the following steps:
  • 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?
  • Understand your deployment constraints. Next, understand your targeted deployment environment and determine what impact this will have on your architecture.
  • Identify important architectural styles. Determine which architectural styles you will be using in your design. Will you build a service oriented architecture, client/server, layered, a message bus, or some combination?
  • Determine relevant technologies. Finally, identify the relevant technology choices based on your application type and other constraints, and determine which technologies you will leverage in your architecture.

Determine your application type

As part of the process of designing and architecting an application, choosing the right application type is the key. The appropriate application type is governed by the requirements and infrastructure limitations. The following considerations will help you to choose the appropriate application type.
  • Mobile Applications can be developed as thin client or rich client applications. Rich client mobile application can support disconnected or occasionally-connected scenarios. Web or thin client applications support only connected scenarios. The device resources may prove to be a constraint when designing mobile applications.
  • Rich Client Applications are usually developed as stand-alone applications with a graphical user interface that displays data using a range of controls. Rich client applications can be designed to support disconnected and occasionally-connected scenarios because the application runs on the client machine.
  • Rich Internet Applications can be developed to support multiple platforms and multiple browsers, displaying rich media or graphical content. Rich internet applications run in a browser sandbox that restricts access to devices on the client.
  • Services Applications aim to achieve loose coupling between the client and the server. Services expose complex functionality and allow clients to access it from a local or remote machine. Service operations are called using XML-based message schemas passed over a transport mechanism.
  • Web Applications typically support connected scenarios, and are developed to support multiple browsers and multiple operating system platforms.

Understand 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 maintainability. Sometimes you must make design tradeoffs due to protocol restrictions and network topologies.

Identify the requirements and constraints that exist between the application architecture and infrastructure architecture early in the design process. This helps you to choose an appropriate deployment topology, and helps you resolve conflicts between the application and infrastructure architecture early in the process.
Distributed and Non-Distributed Architectures
Applications are typically deployed in one of two ways:
  • Non-distributed deployment, where all of the functionality and layers reside on a single server except for data storage functionality.
  • Distributed deployment, where the layers of the application reside on separate physical tiers.
In most cases, the recommendation is to use non-distributed deployment. Whenever a process must cross physical boundaries, performance is affected because the data must be serialized. However, there are some cases where you need to split functionality across servers. In addition, depending on where servers are located, you can often choose communication protocols that are optimized for performance.
Non-Distributed Deployment
With the non-distributed architecture, presentation, business, and data access code are logically separated but are physically located in a single Web server process on the Web server. Figure 2 illustrates this scenario.

Figure 2 - Non-distributed deployment.

  • Non-distributed architecture is less complex than distributed architecture.
  • Non-distributed architecture has performance advantages gained through local calls.

  • With non-distributed architecture, it is difficult to share business logic with other applications.
  • With non-distributed architecture, server resources are shared across layers. This can be good or bad — layers may work well together and result in optimized usage because one of them is always busy. However, if one layer requires disproportionately more resources, you starve resources from another layer.
Distributed Deployment
Distributed deployment allows you to separate the layers of an application on different physical tiers as shown in the Figure 3.

Figure 3 - Distributed deployment.

  • Distributed architecture has the ability to scale out and load balance business logic independently.
  • Distributed architecture has separate server resources that are available for separate layers.
  • Distributed architecture is flexible.

  • Distributed architecture has additional serialization and network latency overheads due to remote calls.
  • Distributed architecture is potentially more complex and more expensive in terms of total cost of ownership.
Stay in the Same Process
Avoid remote method calls and round trips where possible. Remote calls across physical boundaries (process and machine) are costly due to serialization and network latency. You can add more hardware to the existing servers or add more servers to the Web application tier as shown in Figure 4.

Figure 4 - Adding servers to the Web application tier.

You can host your application's business logic on your Web server along with the presentation layer or on a physically separate application server. You achieve optimum performance by locating your business logic on the Web server in your Web application process. If you avoid or exploit server affinity in your application design, this approach supports scaling up and scaling out.
Do Not Remote Application Logic Unless You Need To
Do not physically separate your business logic layer unless you need to and you have evaluated the tradeoffs. Remote logic can increase performance overhead. Performance overhead results from an increased number of round trips over the network with associated network latency and serialization costs.

However, you might need to physically separate your business layer, as in the following scenarios:
  • You might want to co-locate business gateway servers with key partners.
  • You might need to add a Web front end to an existing set of business logic.
  • You might want to share your business logic among multiple client applications.
  • The security policy of your organization might prohibit you from installing business logic on your front-end Web servers.
  • You might want to offload the processing to a separate server because your business logic might be computationally intensive.

Identify important architecture styles

There are many factors that influence the architectural styles that you follow. These include the capacity of your organization for design and implementation; the capabilities and experience of developers; and the infrastructure constraints and deployment scenarios available.
Key Architectural Styles
Typically, you will choose from the following common architectural styles:
  • Client/server. Segregates the system so that the client makes requests from the server.
  • Component-based. Decomposes application design into re-usable components that expose well-defined interfaces.
  • Layered. Segregates the system into groups of similar functionality as separate layers.
  • Message-bus. Defines a set of known formats used by all connected systems so that they do not have to know about the differences between the actual recipients.
  • Object-oriented. A programming style based on the division of tasks into reusable objects that contain both the data and the behavior relevant to the object.
  • Service-oriented (SOA). An application that exposes and consumes functionality as a service using contracts and messages.

You will typically combine multiple styles to define a complete architecture. For example, a layered architecture can be used with component-based, object-oriented, or service-oriented architectural styles. The following are some points to consider when choosing architectural styles.

Consider the client/server architectural style if:
  • Your application is server-based and will support many clients.
  • You are creating Web-based applications exposed through a Web browser.
  • You are implementing business processes that will be used by people throughout the organization.
  • You are creating services for other applications to consume.
  • You want to centralize data storage, backup, and management functions.
  • Your application must support different client types and different devices.

Consider the component-based architectural style if:
  • You already have suitable components, or can obtain suitable components from third-party suppliers.
  • Your application will predominantly execute procedural style functions, perhaps with little or no data input.
  • Your application is relatively simple, and does not warrant a full layered architecture.
  • Your application has specific requirements that do not include a user interface or business processes.
  • You want to be able to combine components written in different code languages.
  • You want to create a pluggable architecture that allows you to easily replace and update individual components.

Consider the layered architectural style if:
  • Your application is complex, and you want to mitigate that complexity by grouping functionality into different areas of concern.
  • You want to improve maintainability and extensibility of the application, by minimizing dependencies.
  • You already have applications that expose suitable business processes through service interfaces.
  • Your application must support different client types and different devices.
  • You want to implement complex and/or configurable business rules and processes.

Consider the message-bus architectural style if:
  • You have existing applications that interoperate with each other to perform tasks.
  • You are implementing a task that requires interaction with external applications.
  • You are implementing a task that requires interaction with applications hosted in a different environment.
  • You have existing applications that perform specific tasks and you want to combine those tasks into a single operation.

Consider the object-oriented architectural style if:
  • You want to model the application based on real-world objects and actions.
  • You already have suitable objects and classes that match the design and operational requirements.
  • You need to encapsulate logic and data together in reusable components.

Consider the service-oriented architectural style if:
  • You have access to suitable services, or can purchase suitable services exposed by a hosting company.
  • You want to build applications that compose a variety of services into a single user interface.
  • You are creating S+S, SaaS, or cloud-based applications.
  • You need to support message-based communication between segments of the application.
  • You need to expose functionality in a platform-independent way.
  • You want to take advantage of federated services, such as authentication.
  • You want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces.

Determine relevant technologies

When choosing technologies for your application, the 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. For example, if you are building a SOA style application then WCF is a good choice. If you are building a web application that will make calls into a WCF service, then ASP.NET is a good choice. Your technology choice is directly tied to your application type.

Consider the following questions:
  • Which technologies help you support your chosen architectural styles?
  • Which technologies help you support your application type?
  • Which technologies help you support key quality attributes for your application?

Step 4 – Key Hot Spots

Identify the hot spots in your application architecture to understand the areas where mistakes are most likely to be made. Key hotspots can be organized around quality attributes and cross cutting concerns.

Quality Attributes

Understand the quality attributes that are important for your application and scenarios. For instance, most applications need to address security and performance and will be traded against usability, flexibility and other attributes that may be more or less important to you depending on your scenarios and requirements.

The following list describes the key quality attributes to consider:
Category Considerations
Availability How to design for failover support
How to design a redundant site
How to plan for backup and recovery
How to design for runtime upgrades
Conceptual Integrity How to isolate from external dependencies
How to create a migration path from legacy technologies
How evolve the system without breaking clients
Flexibility How to handle dynamic business rules
How to handle dynamic UI
How to handle changes in data and logic processing
How to handle changes in business requirements
Interoperability How to allow applications to interoperate while still evolving separately
How to isolate systems through the use of service interfaces
How to isolate systems through the use of mapping layers
Maintainability How to reduce dependencies between layers and components
How to implement a pluggable architecture
How to choose an appropriate communication model
Manageability How to understand the key types of failure
How to monitor system operation and health
How to modify system behavior based on load
Performance How to determine a caching strategy
How to design high performance communication between layers
How to design high performance data access
How to manage resources effectively
Reliability How to handle unreliable external systems
How to audit requests and jobs
How to redirect load
How to handle failed communication
How to handle failed transactions
How to handle exceptions
Reusability How to reduce duplication between components and layers
How to share functionality across systems
How to share functionality across components and layers
Scalability How to design layers and tiers for scalability
How to scale-up or scale-out
How to handle spikes in traffic and load
Security How to address authentication and authorization.
How to protect against malicious input.
How to protect sensitive data
Supportability How to design auditing and logging
How to design usable error messages
Testability How to design for testability
How to design unit tests
How to design for UI automation
Usability How to design for user empowerment
How to improve responsiveness
How to avoid common user experience pitfalls

Architecture Frame

The architecture frame represents cross cutting concerns that will impact your design across layers and tiers. These are also the areas in which high impact design mistakes are most often made. Use the architecture frame to identify hot spots in your design that require additional attention to get right.

You can use the following architecture frame to identify cross cutting concerns in your design:
Area Description
Authentication and Authorization How to choose an authentication strategy.
How to choose an authorization strategy.
How to flow identity across layers and tiers.
How to store user identities when not using Active Directory.
Caching and State How to choose an appropriate caching technology.
How to determine what data to cache.
How to determine where to cache the data.
How to determine the expiration policy.
Communication How to choose appropriate protocols for communication across layers and tiers.
How to design loose coupling across layers.
How to perform asynchronous communication.
How to pass sensitive data.
Composition How to choose a composition pattern for the user interface (UI).
How to avoid dependencies between modules in the UI.
How to handle communication between modules in the UI.
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.
Configuration Management How to determine what information needs to be configurable.
How to determine where and how to store configuration information.
How to protect sensitive configuration information.
How to handle configuration information in a farm/cluster.
Coupling and Cohesion How to choose an appropriate layering strategy for separation of concerns.
How to design highly cohesive components and group them within layers.
How to determine when loose coupling is appropriate between components within a layer.
Data Access How to manage database connections.
How to handle exceptions.
How to improve performance.
How to handle binary large objects (blobs).
Exception Management How to handle exceptions.
How to log exceptions.
How to provide notification when required.
Logging and Instrumentation How to determine which information to log.
How to make the logging configurable.
How to determine what level of instrumentation is required.
User Experience How to improve task efficiency and effectiveness.
How to improve responsiveness.
How to improve user empowerment.
How to improve look and feel.
Validation How to determine where and how to perform validation.
How to validate for length, range, format, and type.
How to constrain and reject input.
How to sanitize output.
Workflow How to choose the appropriate workflow technology.
How to handle concurrency issues within a workflow.
How to handle task failure within a workflow.
How to orchestrate processes within a workflow.

Step 5 – Candidate Solutions

After you define the key hotspots, you can create your first high-level design and then start to fill in the details to produce candidate architecture. You then move back to step 2 of the process to validate the candidate solution design again the key scenarios and requirements you defined, before iteratively following the cycle and improving the design.

Architectural spikes are a design prototype you use to determine the feasibility of a specific design path. Use architectural spikes to reduce your risk and quickly determine the viability of different approaches. Test architectural spikes against key scenarios and hotspots.

Iterative and Incremental Architecture

This architectural process is meant to be an iterative and incremental approach. Your first candidate architecture will be a high-level design that you can test against key scenarios, requirements, known constraints, quality attributes and the architecture frame. As you create your candidate architecture, and any architecture spikes, you will learn more details about the design and will be able to further flesh out key scenarios, your application overview, and your approach to hotspots. Each iteration should add more details to your design.

What to Do Next

After you complete the architecture modeling activity, do the following:
  • If you capture your candidate architectures and architectural test cases in a document, keep the document lightweight and avoid over-formatting so that you can easily update it. Key content should include your objectives, application type, deployment topology, key scenarios, requirements, technologies, quality attributes, and tests.
  • Use the quality attributes to help shape your design and implementation. For example, developers should be aware of anti-patterns related to the identified architectural risks, and use patterns to help address the issues.
  • Use the architectural frame to plan and scope your architectural tests.
  • Communicate the information you capture to relevant team members. This may include your application development team, your test team, and your network and system administrators.

Agile Considerations

Use system stories and user stories to pin your requirements against specific instances of use cases that can be tested against. A good story will intersect the user view, the system view and the business view of the architecture. Use stories to test your design and determine where the breaking points may be. A system story describes the application scenarios from the system’s perspective as seen through the lens of quality attributes. A user story describes what the application should do from the point of view of the customer. In this case, you would create stories around usage, and evaluate against your quality attributes. You should be able to complete development of the features to implement a story within a single iteration. You may need to develop new stories as you create and update your architecture model.

Consider the following when you plan your stories:
  • Early in the project, reduce risk by creating a candidate architecture that supports architecturally significant end-to-end scenarios that exercise all layers of the architecture.
  • Using your architecture model to guide you, make changes to your architecture, design, and code to meet your scenarios, functional requirements, technological requirements, quality attributes, and constraints.
  • Create an architecture model based on what you know at the time, and define a list of questions that must be addressed in subsequent stories and iterations.
  • After you make sufficient significant changes to the architecture and design, consider creating a story that reflects these changes. Batch together the small changes in the architecture and design and address them together.

When creating your architectural spikes, consider the following:
  • Understand your key risks and adapt your design to reduce these risks.
  • Sharing information is critical in an agile approach; optimize your deliverables for effective and efficient communication of design information.
  • Build your architecture with flexibility and refactoring in mind. You may need to modify you architecture a number of times so optimize around this possibility.

Reviewing Your Architecture

Reviewing the architecture for your application is a critically important Task to reduce the cost of mistakes, and find and fix architectural problems as early as possible. Architecture review is a proven, cost effective way of reducing project costs and reducing the chances of an architectural failure. Create your architecture to make it as easy as possible to communicate and review your architecture. Build you architecture with common review questions in mind, both to improve your architecture and to reduce the time required for each review.

The main goal of an architecture review is to verify that the architecture correctly links the functional requirements and the quality attributes with the proposed technical solution. Additionally, it helps to identify issues and areas of improvement.

Scenario-Based Evaluations

Scenario-based evaluations are a powerful method for reviewing an architecture design. In a scenario-based evaluation, the focus is on the scenarios that are most important from the business perspective, and which have largest impact on the architecture. Consider one of the following common review methodologies:
  • Software Architecture Analysis Method (SAAM). SAAM was originally designed for assessing modifiability, but later was extended for reviewing architecture with respect to quality attributes such as modifiability, portability, extensibility, integratibility, and functional coverage. SAAM is also used to review the performance and reliability aspect of the architecture.
  • Architecture Tradeoff Analysis Method (ATAM). ATAM is a refined and improved version of SAAM that helps review architectural decisions with respect to the quality attributes requirements, and how well they satisfy particular quality goals.
  • Active Design Review (ADR). This architecture review technique is best suited for incomplete or in-progress architectures. The main difference is that the review is more focused on set of issues or individual sections of the architecture at a time, rather than performing a general review.
  • Active Reviews of Intermediate Designs (ARID). This architecture review technique combines the ARD aspect of reviewing in-progress architecture with focus on set of issues, and ATAM and SAAM’s approach of scenario-based review focused on quality attributes.
  • Cost Benefit Analysis Method (CBAM). This architecture review technique focuses on analyzing the costs, benefits, and schedule implications of architectural decisions.
  • Architecture Level Modifiability Analysis (ALMA). Evaluates the modifiability of an architecture for Business Information Systems (BIS).
  • Family-Architecture Assessment Method (FAAM). This architecture review technique evaluates information-system family architectures for interoperability and extensibility.

Communicating Your Architecture

After your architecture design is complete, you must communicate the design to the other stakeholders. These stakeholders will include the development team, system administrators and operators, business owners, and other interested parties. There are several well-known methods for describing architecture to others, including the following:
  • 4+1. This approach uses five views of the complete architecture. Four of the views describe the architecture from different approaches: the logical view (such as the object model), the process view (such as concurrency and synchronization aspects), and the physical view (the map of the software layers and functions onto the distributed hardware infrastructure), and the development view. A fifth view shows the scenarios and use cases for the software. This allows stakeholders to see the specific aspects of the architecture that specifically interest them.

Last edited Nov 5, 2008 at 7:35 PM by prashantbansode, version 3


No comments yet.