Agile Architecture Method Explained - Chapter 4 - Step 3: Application Overview

From Guidance Share

Jump to: navigation, search

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


Key Outcomes

  • Application Type
  • Deployment Scenario
  • Architecture Styles
  • Technologies

Summary of Steps

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:

  • Step 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?
  • Step 2. Understand your deployment constraints. Next, understand your targeted deployment environment and determine what impact this will have on your architecture.
  • Step 3. Identify important architectural styles. Determine which architectural styles you will be using in your design. Will you build service oriented architecture, client/server, layered, message bus, or a combination of styles?
  • Step 4. 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.

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

Key Application Types

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

Choosing Application Types

Choose the appropriate application type by considering the requirements and the infrastructure limitations. Use the Application Type Considerations table below to make an informed choice based on the benefits and considerations for each application type.

Application Types Considerations

Application Type Benefits Considerations
Mobile Application
  • Can support handheld devices
  • Availability and ease of use for out-of-office users
  • Can support offline and occasionally-connected scenarios
  • Input and navigation limitations
  • Limited screen display area
Rich Client Application
  • Can leverage client resources
  • Provide better responsiveness, rich UI functionality, and improved user experience
  • Highly dynamic and responsive interaction
  • Can support offline and occasionally-connected applications
  • Deployment complexity, however a range of installation options such as ClickOnce, Windows Installer and XCOPY are available
  • Can be challenging to version over time
  • Platform-Specific
Rich Internet Application (RIA)
  • Provide the same rich user interface capability as Rich Clients
  • Provide support for rich media and graphic display
  • Simple deployment and the distribution capabilities (reach) of Web clients
  • Larger application footprint on the client machine compared to a Web application
  • Restrictions on leveraging client resources compared to a Rich Client application
  • Requires the deployment of the .NET or Silverlight runtime on the client
  • Provide loosely coupled interactions between client and server
  • Can be consumed by different and unrelated applications
  • Supports interoperability
  • No UI support
  • Client is dependent on network connectivity
Web Application
  • Broad reach, and a standards-based UI across multiple platforms
  • Ease of deployment and change management
  • Application is dependent on network connectivity (must be connected all of the time)
  • Providing a rich user interface is difficult

Step 2. Deployment Scenario

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; or 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 server process. Figure 2 illustrates the non-distributed 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, another layer may be starved of resources.

Distributed Deployment

Distributed deployment allows you to separate the layers of an application on different physical tiers. Figure 3 illustrates the distributed scenario.


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.

Step 3. Architecture Styles

An architectural 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 architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems.

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.

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.

Architecture Style Frame

Architectural styles can be organized by their key focus area. The following table lists the major areas of focus and the corresponding architectural styles.

Category Architecture Styles
Deployment Client/server, 3-Tier, N-Tier
Structure Component-Based, Object-Oriented, Layered Architecture
Domain Domain Model, Gateway
Communication Service-Oriented Architecture (SOA), Message Bus, Pipes and Filters

These styles are not exclusive and you will often choose multiple overlapping styles to suit your architectural needs. For example, you may design with object-oriented code principles, organize as a layered architecture, use the Domain model for data access, communicate communicating with services using a service oriented architecture, and the deploy using an N-tier style.

Key Architecture Styles and Patterns

The following table lists the common architectural styles and patterns described in this chapter. It also contains a brief description of each style or pattern. Later sections of this chapter contain more details of each style, and guidance to help you choose the appropriate ones for your application.

Architecture Style Description
Client-Server Segregates the system into two computer programs where one program, the client, makes a service request to another program, the server.
Component-Based Architecture Decomposes application design into re-usable functional or logical components that are location transparent and expose well-defined communication interfaces.
Layered Architecture Partitions the concerns of the application into stacked groups (layers).
Message-Bus A software system that can receive and send messages that are based on a set of known formats, so that systems can communicate with each other without needing to know the actual recipient.
Model-View-Controller (MVC) Separates the logic for managing user interaction from the user interface view and from the data that the user works with.
N-tier / 3-tier Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer.
Object Oriented A programming style based on division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.
Service-Oriented Architecture (SOA) Applications that expose and consume 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 SOA styles. Consider the following points 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 (UI) 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 the 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, Software as a Service (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.

Step 4. 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?


The following presentation layer technologies are available for creating mobile applications:

  • Compact Framework. You can use Windows Compact Framework to create a rich client mobile application that supports connected or occasionally connected scenarios.
  • ASP.NET Mobile. You can use ASP.NET Mobile Controls to create a thin client mobile application. ASP.NET Mobile Controls is a set of server-side controls and special page classes that render output specific to the type of device accessing the application.
  • Silverlight. You can use Silverlight for Mobile Devices to provide rich media support and an improved user experience.

Rich Client

The following presentation layer technologies are available for creating Rich Client applications:

  • Windows Forms. You can use Windows Forms to create applications that provide rich functionality and user experience by utilizing the resources of the client PC.
  • Windows Forms with WPF User Controls. You can use WPF user controls in Windows Forms applications to provide enhanced rich graphical support within the user interface.
  • WPF. You can use WPF to create a rich client application with user interface support for 2-D and 3-D graphics, and animations and media (both video and audio). WPF also includes a two-way data-binding engine.
  • XAML Browser Application (XBAP) using WPF. You can create an XBAP that provides all the features of the standalone WPF application, but is hosted in a browser.

Rich Internet Client (RIA) The following presentation layer technologies are available for creating Rich Internet Applications:

  • Silverlight. You can use Silverlight to create applications that provide a rich user experience that includes graphics, audio, and video.
  • Silverlight with AJAX. You can combine Silverlight with AJAX to create a Rich Internet Application that performs asynchronous communication between the client and the server.

Web Applications

  • ASP.NET Web Forms. You can use ASP.NET Web Forms with a wide range of server controls that render HTML in Web browsers.
  • ASP.NET Web Forms with AJAX. You can use AJAX in your ASP.NET Web Forms application to improve the user experience by reducing the number of post backs required.
  • ASP.NET Web Forms with Silverlight Controls. You can use Silverlight controls in your ASP.NET Web application to provide a rich user experience and support media streaming.
  • ASP.NET MVC. You can use ASP.NET MVC to create Web applications with built-in support for the Model-View-Controller design pattern. MVC simplifies developing, modifying, and testing the individual components within the application.
  • ASP.NET Dynamic Data. You can use ASP.NET Dynamic Data to create functional data-driven Web applications based on a LINQ to SQL or Entity Framework data model.

Service Applications

The following technologies are available for creating service applications:

  • Windows Communication Foundation (WCF). When possible, use WCF to create services n order to benefit from maximum feature availability and interoperability.
  • ASP.NET Web services (ASMX). Use ASMX for simplicity, and only when a suitable Web server will be available.

Data Access

Following data access technologies are available with .NET platform

  • ADO.NET Core – provides general retrieval, update, and management of data. ADO.NET includes providers for SQL Server, OLE-DB, ODBC, SQL Server Mobile, and Oracle databases.
  • ADO.NET Data Services Framework – exposes data using the Entity Data Model, through RESTful Web services accessed over HTTP. The data can be addressed directly via a URI. The Web service can be configured to return the data as plain Atom and JSON formats.
  • ADO.NET Entity Framework – gives you a strongly typed data access experience over relational databases. It moves the data model from the physical structure of relational tables to a conceptual model that accurately reflects common business objects. The Entity Framework introduces a common Entity Data Model (EDM) within the ADO.NET environment, allowing developers to define a flexible mapping to relational data. This mapping helps to isolate applications from changes in the underlying storage schema. The Entity Framework also contains support for LINQ to Entities, which provides LINQ support for business objects exposed through the Entity Framework. Current plans for the Entity Framework will build in functionality so it can be used to provide a common data model across high-level functions such as data query and retrieval services, reporting, synchronization, caching, replication, visualization, and BI. When used as an Object/Relational Mapping (O/RM) product developers use LINQ to Entities against business objects, which Entity Framework will convert to Entity SQL that is mapped against an Entity Data Model managed by Entity Framework. Developers also have the option of working directly with the Entity Data Model and using Entity SQL in their applications.
  • ADO.NET Sync Services – is a provider included in the Microsoft Sync Framework synchronization for ADO.NET enabled databases. It enables data synchronization to be built in occasionally connected applications. It periodically gathers information from the client database and synchronizes it with the server database.
  • Language-Integrated Query (LINQ) – provides class libraries that extend C# and Visual Basic with a native language syntax for queries. Queries can be performed against a variety of data formats, which include: DataSet (LINQ to DataSet), XML (LINQ to XML), In Memory Objects (LINQ to Objects), ADO.NET Data Services (LINQ to Data Services), and Relational data (LINQ to Entities). The main thing to understand is that LINQ is a query technology supported by different assemblies throughout the .NET Framework. For example, LINQ to Entities is included with the ADO.NET Entity Framework assemblies, LINQ to XML is included with the System.Xml assemblies, and LINQ to Objects is included with the .NET core System assemblies.
  • LINQ to SQL – provides a lightweight strongly typed query solution against SQL Server. LINQ to SQL is designed for easy, fast object persistence scenarios where the classes in the mid-tier map very closely to database table structures. Starting with .NET 4.0, LINQ to SQL scenarios will be integrated and supported by ADO.NET Entity Framework, however LINQ to SQL will continue to be a supported technology. For more information see this post on ADO.NET team blog.

Whiteboard Your Architecture

Be able to whiteboard your architecture. Whether or not you share it on paper, slides, or other visuals, the key is to show the big constraints and decisions to frame and start the conversations.


Personal tools