This project is read-only.
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.

Chapter 8 - Designing Your Architecture

- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, 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 chapter 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.
<< TBD>>


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, reliability)
  • Technological requirements
  • Constraints


There are several different types of outputs that should come out of a design:
  • Candidate architectures
  • Architectural spikes
  • Test cases


The six major steps for designing your architecture are shown in Figure 1:


Figure 1: Core Architecture Design Activities

The approach to architectural design is summarized in the following steps:
  • Step 1. Choose 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 is different for a service compared to a rich client. Start by understanding your application type, and how that choice impacts your overall architecture.
  • Step 2. Choose deployment topology. How you deploy your application will shape your overall design. Will you be deploying a Web application on multiple tiers? Will you be deploying a Rich Internet Application over the Internet? Understand your logical and physical deployment scenario in order to better understand the constraints and architectural requirements.
  • Step 3. Choose architectural styles. Consider the application type you are designing, along with architectural goals and constraints, to determine which architectural styles are a best fit. Will your design be based on SOA principles? Will you use a layered architecture? Will you use an object-oriented approach? Your choice of architectural styles will provide a set of principles that make architectural decisions more cohesive and directed.
  • Step 4. Choose technologies. Choose technologies based on capabilities and patterns appropriate for your scenarios.
  • Step 5. 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 to create a robust design.
  • Step 6. Address cross cutting concerns. Walk the architecture frame and understand how each cross-cutting concern impacts your design. Consider architectural requirements for caching, communication, data access, layering, validation, and so on.

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

Step 1 – Choose 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.

For more details of the common application types, see Chapter 3 Application Archetypes.

Step 2 – Choose Deployment Topology

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 nondistributed architecture, presentation, business, and data access code are logically separated but are physically located in a single Web server process on the Web server.


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

  • With nondistributed architecture, it is difficult to share business logic with other applications.
  • With nondistributed 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 following figure.


  • 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 layer as shown in the following figure:


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 collocate 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.

For more details of deployment options and considerations, see Chapter 4 Deployment Patterns.

Step 3 – Choose Architectural Styles

<< summarize the architectural 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.
  • Component-based architecture.
  • Layered architecture.
  • Message-bus architecture.
  • Object-oriented architecture.
  • Service-oriented architecture (SOA).

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.

For more details of the common architectural styles, see Chapter 5 Architectural Styles.

Step 4 – Choose 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. You must compare the capabilities of the technologies you choose against your application requirements, taking into account all of these factors before making decisions.

<< TBD>>

Step 5 –Address quality attributes

Quality attributes are the features and scenarios for an application that are not directly linked to a specific section or component of the application. They cover the general aspects of the application and often impact many separate areas of the design. Quality attributes are important for the overall usability, performance, reliability, and security of your application. As part of the task of architecting your applications, it is important to identify the key quality attributes that you must consider, as well as understanding the key issues, decisions, and techniques associated with each one. Always keep in mind the possibility of individual quality attributes may conflict. For example, adding more security to the application may affect the performance. Hence, you should analyze the trade-offs between one or more conflicting quality attributes.

Key Quality Attributes

<< summarize capabilities / goals / considerations for each attribute >>
The following list describes the key quality attributes that you should consider:

Category Considerations
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 re-factored.
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, using services, and cope with refactoring and upgrades to other applications.
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 use.
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 as well as 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.

For more details of the common application types, see Chapter 6 - Quality Attributes.

Step 6 – Address Cross-Cutting Concerns

Typical enterprise level applications have sets of cross-cutting concerns that you can centralize and separate from your layers and make available across the application.

Architecture Frame

You can use the following architecture frame to identify potential hot spots in your design. You can then identify potential end-to-end test cases to help reduce design risk:

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.
How to synchronize caches across a farm.
How to choose between reactive and proactive cache loading.
How to identify state data versus cache data.
How to determine scope requirements for state data, which also determines where state data is persisted.
Communication How to choose appropriate protocols for communication across layers and tiers.
How to design loose coupling across layers.
How to design an interface for communication across processes and physical boundaries.
How to pass data across processes and physical boundaries.
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.
How to determine appropriate transaction isolation levels.
How to determine when compensating transactions are required.
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).
How to page records.
How to perform transactions.
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.
How to handle the un-deterministic nature of human workflow.

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 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 notice 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.
  • If you have high priority architectural threats and you have no corresponding vulnerabilities, you need to make a decision.
  • 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

You should begin the architecture modeling exercise early in your project so that the threat model influences the design of your application. To create and update the model, develop system stories and user stories. A system store describes the application scenarios from the system’s perspective. 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 a story in 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.
  • Create your first threat model for this candidate architecture. This will change, but it is a good starting point.
  • 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 need to be addressed in subsequent stories and iterations.
  • After you make enough 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.
  • If you need to work with outside security groups, you need to schedule a time to complete the threat model to provide to the external group. These groups tend to provide better input when they understand the entire application.

Scenario-Based Evaluations

<< TBD >>

Communicating Your Architecture

<< TBD>>

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


No comments yet.